Un ensayo reciente sostiene que el Protocolo de Contexto de Modelos fue diseñado para una generación anterior de asistentes de IA y que ahora debería dejar paso a las API HTTP directas y a las herramientas de línea de comandos. Su observación técnica más sólida es que un agente con amplio acceso a la terminal puede consultar documentación, escribir un script, llamar a varias API y orquestar un flujo de trabajo sin necesidad de un servidor MCP dedicado. Esta es una capacidad significativa, pero por sí sola no demuestra que MCP haya dejado de ser necesario para todos los agentes o entornos de implementación.
El ensayo examinado sostiene que MCP siempre fue una mala idea; esta imagen capta esa postura inicial frente a la contraargumentación del artículo.
El desacuerdo gira en torno al alcance. Anthropic presentó MCP en noviembre de 2024 como un estándar abierto para conexiones bidireccionales entre aplicaciones de IA y fuentes de datos externas. Su propósito declarado era sustituir los conectores específicos por una arquitectura común: los servidores exponen capacidades, mientras que los clientes las descubren y las invocan. Esta descripción explica por qué MCP resulta útil como capa de integración y gobernanza; no demuestra que todas sus implementaciones sean eficientes ni que el protocolo sea la mejor interfaz para cada agente.
El argumento a favor del acceso directo es más sólido cuando el agente ya dispone de un entorno de ejecución fiable, contexto suficiente para comprender una API y permiso para acceder a ella. Un extremo REST documentado o una CLI madura pueden ofrecer entonces más flexibilidad que una colección fija de herramientas MCP. El agente puede construir solicitudes, combinar servicios y adaptarse cuando cambia un extremo. Sin embargo, esta comparación presupone capacidades de las que carecen deliberadamente muchos agentes de producción. El acceso a la terminal no es simplemente otra opción de transporte: puede exponer credenciales, archivos locales, recursos de red y acciones que van más allá del servicio previsto.
Esta distinción es importante para la seguridad y las operaciones. Un servidor MCP de alcance limitado puede presentar herramientas seleccionadas en lugar de ofrecer acceso irrestricto a la red o al intérprete de comandos. También puede centralizar la autenticación, la autorización, la revocación y el registro de auditoría en un límite controlado por un administrador. Estos son beneficios arquitectónicos potenciales de MCP, no garantías de que cada implementación de MCP los aplique de forma segura. La evidencia suministrada no incluye una auditoría comparativa de seguridad, un estudio de rendimiento ni datos de incidentes que demuestren que MCP sea más seguro, rápido o económico que un diseño de API mediado por proxy.
El ensayo también identifica un problema real de escalabilidad: una gran cantidad de servidores y esquemas de herramientas extensos pueden consumir el contexto del modelo y dificultar su selección. El descubrimiento de herramientas, la búsqueda y la llamada programática son respuestas a ese problema. Anthropic informó de más de 10.000 servidores MCP públicos activos en diciembre de 2025 y afirmó que su API había incorporado Tool Search y Programmatic Tool Calling para gestionar conjuntos amplios de herramientas y reducir la latencia en flujos de trabajo complejos. Estas son afirmaciones de Anthropic sobre su ecosistema y sus productos, no mediciones independientes, pero muestran que el ecosistema está tratando la inflación de contexto como un problema de ingeniería en lugar de simplemente aceptarla.
Las API directas resuelven otra parte del problema. Pueden ofrecer una funcionalidad amplia sin traducir cada operación a una herramienta declarada por separado, y la negociación de contenido estándar puede permitir que un agente solicite texto conciso o Markdown. Sin embargo, una especificación de API aún debe poder descubrirse, comprenderse, versionarse y ser compatible con el entorno de ejecución del agente. Una CLI puede proporcionar una interfaz estable, pero solo cuando existe, está documentada, ofrece resultados legibles por máquina y es segura de invocar de forma autónoma. Las fuentes suministradas no demuestran que estas condiciones se cumplan en todos los servicios a los que MCP se conecta actualmente.
La historia de la gobernanza complica la afirmación de que MCP es simplemente un experimento de Anthropic vinculado a modelos obsoletos. Anthropic anunció en diciembre de 2025 que donaría MCP a la Agentic AI Foundation, un fondo dirigido dependiente de Linux Foundation, al tiempo que afirmó que el modelo de gobernanza del proyecto permanecería sin cambios. Esta medida puede reforzar el argumento de una supervisión más amplia, pero no valida las cifras de adopción comunicadas ni resuelve las compensaciones técnicas. Sí significa que el futuro del protocolo no puede evaluarse únicamente como una característica del asistente de un proveedor.
Para quienes construyen sistemas, la elección práctica es, por tanto, condicional. Un agente de terminal con permisos cuidadosamente controlados puede necesitar menos adaptadores MCP y beneficiarse del acceso directo a API o CLI. Una aplicación multiusuario, un asistente de escritorio gestionado o un flujo de trabajo empresarial pueden necesitar, en cambio, un límite de capacidades restringido, credenciales delegadas, consentimiento uniforme del usuario y registros centralizados. MCP puede ofrecer una forma común de exponer ese límite, aunque una pasarela de API o un proxy de servicios bien diseñados podrían proporcionar algunos de los mismos controles sin utilizar el protocolo.
La evidencia respalda una conclusión más limitada que “MCP siempre fue una mala idea”. Respalda la observación de que las interfaces directas pueden ser más expresivas para agentes capaces y de que las implementaciones extensas de MCP generan problemas de descubrimiento y gestión del contexto. No establece que los agentes con capacidad de terminal representen el entorno de producción predeterminado, que el acceso directo elimine el riesgo de autenticación o que MCP carezca de valor cuando una ejecución irrestricta sería inadecuada. La cuestión de ingeniería útil no es si los agentes pueden llamar a API, sino qué interfaz proporciona la capacidad requerida con el menor acceso, complejidad operativa y exposición.