En entornos de administración de sistemas y desarrollo, el problema con MCP no es que esté “muerto”, sino que ha dejado de ser una novedad sencilla para convertirse en una pieza de infraestructura que hay que diseñar, gobernar y auditar. El propio proyecto mantiene una hoja de ruta activa para 2026 centrada en cuatro frentes muy concretos: escalabilidad del transporte, comunicación entre agentes, madurez de la gobernanza y preparación para entornos enterprise. Además, sus mantenedores subrayan que MCP ya se usa en producción en empresas grandes y pequeñas y que ha evolucionado mucho más allá de conectar herramientas locales.
Eso cambia por completo la conversación. Para un sysadmin o un desarrollador, MCP no debe evaluarse como una moda, sino como una capa adicional de transporte, descubrimiento, permisos y operación. Y ahí está el punto incómodo: una capa más puede aportar orden cuando hay muchas herramientas y muchos clientes, pero también puede introducir latencia, complejidad operativa y riesgos de seguridad si se despliega sin una necesidad clara. OpenAI reconoce, por ejemplo, que exponer demasiadas herramientas desde un servidor MCP puede elevar costes y latencia, y recomienda filtrar herramientas permitidas cuando no se necesite todo el catálogo.
El estándar sigue creciendo, pero ya no vale para todo
La documentación oficial define MCP como un estándar abierto para conectar aplicaciones de IA con sistemas externos, desde bases de datos y ficheros locales hasta motores de búsqueda, calculadoras o flujos de trabajo completos. También deja claro que el ecosistema no es pequeño: el protocolo declara soporte en asistentes como Claude y ChatGPT, además de herramientas de desarrollo como Visual Studio Code o Cursor. Eso, sobre el papel, lo hace atractivo para equipos que quieren construir una vez e integrar en varios clientes.
El problema es que esa ventaja de interoperabilidad no sale gratis. La hoja de ruta 2026 del protocolo admite que el transporte remoto con Streamable HTTP ha desbloqueado una nueva ola de despliegues en producción, pero también ha destapado limitaciones concretas: sesiones con estado que chocan con balanceadores de carga, dificultades para escalar horizontalmente y ausencia de un mecanismo estándar para descubrir capacidades del servidor sin conectarse a él. Cuando el propio roadmap prioriza precisamente esos puntos, el mensaje es claro: el estándar avanza, sí, pero aún está madurando en los frentes que más importan en operaciones reales.
Para Claude Code, MCP ya es parte del flujo, pero con advertencias serias
Anthropic no se está alejando de MCP; al contrario, lo integra de forma explícita en Claude Code. Su documentación indica que los servidores MCP pueden configurarse de varias maneras y que, para servidores remotos, HTTP es la opción recomendada y la más ampliamente soportada para servicios cloud. También permite configuraciones compartidas a nivel de proyecto mediante un archivo .mcp.json en la raíz del repositorio, pensado para entrar en control de versiones y para que todo el equipo trabaje con la misma definición de herramientas.
Eso tiene mucho sentido para equipos de desarrollo, pero también introduce responsabilidades nuevas. Anthropic avisa de forma explícita de que los servidores MCP de terceros se usan bajo tu propio riesgo, que no ha verificado la seguridad de todos ellos y que hay que ser especialmente prudente con los que pueden recuperar contenido no confiable, porque pueden exponer al usuario a prompt injection. Además, Claude Code contempla rutas específicas para despliegue administrado por TI mediante managed-mcp.json en rutas de sistema que requieren privilegios de administrador, lo que confirma que MCP ya se está tratando como una pieza gobernable por IT, no solo como un juguete para desarrolladores.
OpenAI también lo abraza, pero empuja controles y aprobaciones
OpenAI está haciendo algo parecido desde otro ángulo. Su Responses API soporta herramientas MCP con servidores remotos compatibles con Streamable HTTP o HTTP/SSE, y la compañía explica que el modelo puede listar herramientas, invocarlas y recibir su salida dentro del contexto de la conversación. También precisa que solo se cobra por los tokens usados al importar definiciones o realizar llamadas, sin una tarifa extra por tool call.
Ahora bien, OpenAI introduce una señal muy reveladora para equipos de plataforma y seguridad: por defecto, la API pide aprobación previa antes de compartir datos con un conector o con un servidor MCP remoto. Además, recomienda revisar con cuidado qué información se envía a esos servidores, registrar esos datos y, cuando sea posible, elegir servidores oficiales operados por el propio proveedor del servicio en lugar de proxies de terceros. La documentación también recuerda que, aunque el uso de MCP sea compatible con Zero Data Retention y Data Residency en la plataforma de OpenAI, los servidores MCP siguen siendo servicios de terceros y sus propias políticas de retención y residencia de datos siguen aplicando. Para cualquier administrador de sistemas, esa frase basta para entender que aquí el perímetro no termina en el proveedor del modelo.
La decisión correcta no es “MCP sí o no”, sino “dónde y para qué”
Para un sitio de sysadmins y desarrolladores, la conclusión útil no es que MCP esté muerto, sino que ya no debería ser la elección por defecto. Cuando el caso de uso es estrecho, la integración es estable y el objetivo está muy acotado, una API directa seguirá siendo más simple de desplegar, monitorizar y asegurar. Cuando el objetivo sea empaquetar una experiencia de app dentro de ChatGPT, OpenAI dice además que el Apps SDK es la vía recomendada para publicar experiencias, incluidas las que usan herramientas respaldadas por MCP. Es una pista importante: incluso OpenAI diferencia entre usar MCP como backend de herramientas y usar un SDK específico cuando lo que se quiere es construir una experiencia de aplicación distribuible.
MCP empieza a justificar de verdad su complejidad cuando una organización necesita una capa compartida para múltiples clientes, múltiples herramientas y múltiples equipos, con versionado de configuración, políticas de acceso y reutilización transversal. Ahí sí puede actuar como un bus común para herramientas de IA. Pero si se implanta para resolver un problema que ya estaba resuelto con una API interna, lo más probable es que el equipo termine añadiendo otra superficie de fallo, otra fuente de latencia y otra pieza que auditar. Esa es una inferencia razonable a partir de cómo Anthropic y OpenAI documentan hoy el uso de MCP: ambas compañías lo soportan y lo promueven, pero también llenan sus guías de advertencias sobre aprobaciones, allowlists, filtros de herramientas, logging y seguridad del servidor.
Qué deberían mirar primero los equipos de sistemas y desarrollo
Antes de desplegar MCP en serio, un equipo técnico debería responder al menos cuatro preguntas. La primera: si realmente necesita interoperabilidad entre varios clientes o solo una integración puntual. La segunda: qué datos saldrán del perímetro y hacia qué servidores concretos. La tercera: cómo va a gobernar la configuración compartida, ya sea en .mcp.json para equipos de desarrollo o mediante archivos administrados por TI para despliegues corporativos. Y la cuarta: qué controles aplicará sobre allowlists, aprobaciones, filtrado de herramientas y registros de actividad. Todo eso no es teoría: aparece ya de forma explícita en la documentación operativa de Claude Code y OpenAI.
La realidad, por tanto, es bastante menos dramática que el titular de “MCP is Dead” y bastante más técnica. MCP no ha muerto. Lo que ha muerto es la fantasía de que bastaba con enchufarlo y olvidarse. En 2026, MCP empieza a parecerse a lo que de verdad es: una capa de integración potente, útil en el sitio correcto y peligrosa cuando se despliega sin disciplina de plataforma.
Preguntas frecuentes
¿MCP sigue siendo relevante para sysadmins y desarrolladores en 2026?
Sí. El protocolo mantiene hoja de ruta activa, uso en producción y soporte en clientes y APIs relevantes. Lo que cambia es que ahora exige más diseño de plataforma, más gobierno y más controles operativos.
¿Claude Code recomienda algún transporte concreto para servidores remotos?
Sí. Anthropic indica que HTTP es la opción recomendada para conectar servidores MCP remotos y que es el transporte más ampliamente soportado para servicios cloud.
¿Qué riesgos de seguridad destacan los proveedores?
Anthropic advierte del riesgo de usar servidores MCP de terceros no verificados y menciona expresamente la exposición a prompt injection. OpenAI, por su parte, recomienda aprobaciones previas, uso de servidores oficiales, logging y revisión cuidadosa de los datos enviados a servidores remotos.
¿Qué alternativa propone OpenAI cuando lo que se quiere es publicar una app en ChatGPT?
OpenAI indica que, para construir y publicar experiencias de app, el Apps SDK es la vía recomendada, incluso cuando la aplicación use herramientas respaldadas por MCP.
