--- title: "Caso de estudio: un equipo de plataforma reúne 20 servidores MCP tras un endpoint — onemcp" description: "Cómo un equipo de ingeniería de plataforma ilustrativo sustituyó una veintena de configuraciones MCP dispersas por los repositorios por un único portal de onemcp — un endpoint, credenciales del lado del host, alrededor de un 90 % menos de sobrecarga de herramientas por solicitud." ogTitle: "Caso de estudio: 20 servidores MCP, un endpoint" ogDescription: "Un equipo de plataforma sustituye 20 configuraciones MCP dispersas por un solo portal de onemcp — autenticación del lado del host, ventana de contexto más ligera." url: "https://onemcp.dev/es/case-studies/platform-team-mcp-gateway" eyebrow: "Caso de estudio · Ingeniería de plataforma" headline: "Un endpoint para cada agente, en lugar de 20 configuraciones MCP por repositorio." summary: "Un equipo de plataforma mantenía a mano listas de servidores MCP en cada repositorio. Hacerlas pasar todas por un único portal de onemcp eliminó la dispersión de configuraciones, trasladó las credenciales al lado del host y devolvió a sus agentes de código el margen para razonar." industry: "Plataforma de desarrollo interna" teamSize: "~60 ingenieros, 1 equipo de plataforma" stack: "Claude Code · Cursor · GitHub · Postgres · Linear · Sentry" illustrative: "Escenario ilustrativo inspirado en implementaciones habituales de onemcp. El equipo descrito es una composición y no un cliente nombrado; las cifras son representativas y no medidas." results: - "Más de 20 servidores MCP accesibles a través de 1 endpoint" - "Sobrecarga de herramientas por solicitud reducida alrededor de un 90 %" - "Ninguna credencial ascendente almacenada en las configuraciones de cliente" quote: "Dejamos de enviar la configuración MCP en las pull requests. Ahora un repositorio apunta a un endpoint y lo obtiene todo, y es el equipo de seguridad quien custodia los tokens, no nosotros." quoteAttribution: "Ingeniero de plataforma sénior (ilustrativo)" --- ## Contexto El equipo de plataforma daba soporte a una sesentena de ingenieros repartidos en una docena de escuadras de producto. En un año de adopción de MCP, cada escuadra había cableado su propio conjunto de servidores — GitHub, Postgres, Linear, Sentry, una herramienta interna de despliegue — directamente en las configuraciones de Claude Code y Cursor. Cada repositorio llevaba su propio `mcp.json`, e incorporar una herramienta nueva suponía una pull request contra todos los proyectos que la quisieran. El montaje funcionaba, pero no escalaba. Una veintena de servidores estaba ahora duplicada en decenas de archivos de configuración, cada uno con versiones ligeramente distintas y credenciales pegadas por quien lo hubiera configurado primero. ## El reto Tres problemas reaparecían en cada retrospectiva. - **Dispersión de la configuración.** Añadir o actualizar un servidor obligaba a tocar cada repositorio. Las configuraciones derivaban, y nadie podía decir con certeza qué escuadra disponía de qué herramientas. - **Credenciales en el lugar equivocado.** Los tokens de acceso personal y las claves de API vivían en las máquinas de los desarrolladores y, en ocasiones, en configuración versionada. Rotar un token comprometido era una búsqueda del tesoro. - **Una ventana de contexto abarrotada.** Cada servidor MCP inyectaba su esquema de herramientas completo en cada prompt. Con veinte servidores conectados, el agente dedicaba buena parte de su contexto a las definiciones de herramientas antes siquiera de ver la primera línea de la tarea. ## El enfoque El equipo levantó un único **portal** de onemcp, añadió sus servidores una sola vez y autenticó cada servicio ascendente allí mismo. En lugar de que cada cliente hable con cada servidor, los clientes hablan con el portal, y el portal reparte hacia los servicios ascendentes. Dos cosas cambiaron la forma del problema: - **Un endpoint sustituye a muchos.** Un repositorio ya no enumera servidores; apunta Claude Code o Cursor a la URL del portal y hereda todo el conjunto de herramientas seleccionado. Cambiar o actualizar un servidor ocurre una vez, en el portal. - **El Code Mode sustituye el muro de definiciones.** En lugar de inyectar por adelantado cada esquema de herramienta, el portal expone tres meta-herramientas — `search`, `describe` y `execute`. El agente descubre a demanda el puñado de herramientas que exige una tarea y las llama desde un único script, en una sola ida y vuelta. ## El despliegue La migración se realizó escuadra por escuadra a lo largo de dos semanas. Para cada repositorio, el equipo eliminó la lista local de servidores e introdujo una única entrada de portal. Como el portal custodia las credenciales, los desarrolladores retiraron de paso los tokens de sus máquinas. El equipo de plataforma conservó el portal como único punto de control: los servidores nuevos se examinaban y añadían de forma centralizada, y los accesos se gestionaban en un solo lugar en vez de a través de decenas de archivos `mcp.json`. ## Los resultados - **Más de 20 servidores tras un endpoint.** Los repositorios referencian una sola URL de portal. Añadir una herramienta es un cambio en el portal, no una pull request en toda la flota. - **Sobrecarga de herramientas por solicitud reducida alrededor de un 90 %.** Sustituir cientos de definiciones precargadas por tres meta-herramientas bajó la sobrecarga por solicitud de unos 15 000 tokens hacia ~500 — contexto que los agentes dedican ahora a la tarea. - **Credenciales del lado del host.** El OAuth ascendente y los tokens permanecen en el portal, nunca en las configuraciones de cliente ni en archivos versionados. La rotación es una sola actualización en un solo lugar. > Dejamos de enviar la configuración MCP en las pull requests. Ahora un repositorio apunta a un endpoint y lo obtiene todo, y es el equipo de seguridad quien custodia los tokens, no nosotros. ## Casos de estudio relacionados - [Un agente de soporte con IA a dieta de tokens](/es/case-studies/support-agent-token-diet) - [Agentes de datos de autoservicio sin filtrar credenciales](/es/case-studies/data-team-secure-agents)