En el panorama actual de la IA, un concepto está generando un considerable revuelo: MCP, o Protocolo de Contexto del Modelo. Sorprendentemente, la atención que rodea a este sistema de protocolo ha eclipsado incluso los últimos lanzamientos de modelos de OpenAI, convirtiéndose en un punto focal de las discusiones de la industria.
El auge de la popularidad de la tecnología Agent, impulsado por el surgimiento de Manus, ha alimentado el entusiasmo de los desarrolladores globales. MCP, posicionado como un ‘protocolo unificado’ para la invocación de herramientas Agent, ha ganado rápidamente tracción, asegurando el apoyo de los principales actores de la IA como OpenAI y Google en solo dos meses. Este rápido ascenso ha transformado a MCP de una especificación técnica relativamente oscura en un estándar fundamental dentro del ecosistema de la IA, marcando un ‘evento fenomenal’ en el ámbito de la infraestructura de la IA.
Sin embargo, a medida que la emoción inicial disminuye, surgen preguntas críticas: ¿Es MCP realmente universalmente aplicable? ¿Se han inflado las expectativas sobre sus capacidades?
Esta exploración profundiza en los orígenes de MCP, diseccionando sus fortalezas y limitaciones centrales, aclarando conceptos erróneos prevalentes y examinando su trayectoria futura potencial. El objetivo no es descartar el valor inherente de MCP, sino más bien fomentar una comprensión más sólida de su papel y sus límites. Solo a través de tal claridad se puede realizar plenamente su potencial.
Desvelando MCP: Un Protocolo Unificado de Invocación de Herramientas
Definiendo MCP
MCP es un protocolo técnico abierto diseñado para estandarizar la forma en que los Modelos de Lenguaje Grande (LLM) interactúan con herramientas y servicios externos. Piense en él como un traductor universal dentro del mundo de la IA, que permite a los modelos de IA ‘conversar’ con una amplia gama de herramientas externas. Proporciona un lenguaje y una estructura comunes para que los LLM soliciten y utilicen las funcionalidades ofrecidas por diferentes aplicaciones y servicios.
La Necesidad de MCP
Antes de la llegada de MCP, la invocación de herramientas de IA estaba plagada de dos desafíos clave:
- Fragmentación de la Interfaz: Cada LLM empleaba distintos formatos de instrucción, mientras que cada API de herramienta tenía sus estructuras de datos únicas. Los desarrolladores se vieron obligados a escribir código de conexión personalizado para cada combinación, lo que condujo a un proceso de desarrollo complejo e ineficiente.
- Ineficiencia del Desarrollo: Este enfoque de ‘traducción uno a uno’ resultó costoso y difícil de escalar. Era como contratar a un traductor dedicado para cada cliente extranjero, lo que obstaculizaba la productividad y la agilidad.
MCP aborda estos puntos débiles al proporcionar un marco estandarizado para que los LLM interactúen con herramientas externas, simplificando el proceso de desarrollo y permitiendo una mayor escalabilidad.
Comprendiendo la Funcionalidad de MCP
La arquitectura técnica de MCP puede conceptualizarse como un sistema que comprende tres componentes centrales: MCP Host, MCP Client y MCP Server. Estos elementos trabajan sinérgicamente para facilitar una comunicación fluida entre los modelos de IA y el mundo externo.
Para comprender el papel de MCP, considere un entorno empresarial moderno. En esta analogía:
- Usuarios representan a los altos ejecutivos, responsables de comprender las necesidades de los usuarios y tomar decisiones finales.
- Modelos de Lenguaje Grande (LLM) (como Claude o GPT) entienden las instrucciones ejecutivas, planifican los pasos de las tareas, determinan cuándo utilizar servicios externos y consolidan la información para proporcionar respuestas.
- Sistemas Agent funcionan como asistentes personales o secretarios ejecutivos, realizando tareas según las instrucciones.
- MCP actúa como una plataforma de comunicación estandarizada o un sistema de acceso a servicios empresariales utilizado por los secretarios. No toma decisiones, sino que sigue las instrucciones, comunicándose con varios proveedores de servicios en un formato y protocolo unificados.
Antes de MCP, la interacción de la IA con herramientas externas era similar a una era de estándares de comunicación caóticos. Cada vez que un secretario (Agent) necesitaba contactar con un departamento diferente o un proveedor externo, tenía que utilizar un dispositivo o software de comunicación diferente. Esto requería familiaridad con diversos sistemas, lo que resultaba en ineficiencias. Los desarrolladores tenían que escribir códigos de conexión separados para cada herramienta, lo que conducía a una pérdida de tiempo y a una escalabilidad limitada.
MCP agiliza este proceso al proporcionar una plataforma de comunicación unificada, que permite a los secretarios contactar con cualquier departamento o proveedor de servicios utilizando el mismo sistema y protocolo de comunicación. Los desarrolladores solo necesitan implementar la interfaz MCP una vez, lo que permite a los sistemas de IA interactuar con todas las herramientas que admiten el protocolo.
MCP: Una Caja de Herramientas Construida sobre la Llamada de Función
Es crucial entender que MCP no es un reemplazo para la Llamada de Función tradicional; más bien, es un componente complementario que mejora sus capacidades.
La Llamada de Función es el mecanismo central por el cual los LLM interactúan con herramientas o APIs externas. Es una capacidad fundamental de los LLM, que les permite identificar cuándo se necesita una herramienta y qué tipo de herramienta se requiere.
MCP actúa como un sistema de clasificación de herramientas, proporcionando un marco estructurado para organizar y acceder a varias herramientas. Por lo tanto, MCP no reemplaza la Llamada de Función, sino que trabaja en conjunto con los Agents para realizar tareas complejas.
El proceso completo de invocación de herramientas implica una combinación de ‘Llamada de Función + Agent + Sistema MCP’.
En esencia, el LLM expresa la necesidad de llamar a una herramienta específica a través de la Llamada de Función. El Agent sigue las instrucciones para ejecutar la invocación de la herramienta, mientras que MCP proporciona una especificación de invocación de herramienta estandarizada.
Considere la siguiente analogía: un jefe (usuario) quiere café. En la oficina (MCP Host), el gerente de la oficina (LLM) instruye al secretario (Agent) para que compre un Americano (Llamada de Función). El secretario consulta la lista de proveedores y descubre que un proveedor de café Americano se ha integrado con Meituan o con el sistema de adquisición unificado de la empresa (MCP Server implementado). El secretario localiza entonces al proveedor en el sistema de adquisición (MCP Client) y realiza un pedido.
Anteriormente, sin MCP, cuando el LLM emitía una Llamada de Función, el Agent traducía y se conectaba directamente a la API para invocar la herramienta. Cada API requería un modo de invocación separado y una lista de herramientas y un modo de invocación definidos para que el Agent los interpretara. Con MCP, muchas APIs pueden pedirse directamente a través del MCP Client del proveedor, lo que ahorra tiempo y esfuerzo al Agent. Sin embargo, la Llamada de Función del LLM permanece sin cambios, todavía en el formato {tool: ‘buy coffee’, ‘type’: ‘Americano’}.
Al distinguir entre Llamada de Función y MCP, queda claro que MCP no determina qué herramienta utilizar, ni maneja la planificación de tareas o la intención del usuario. Estos aspectos entran dentro del ámbito de la capa Agent. MCP simplemente proporciona una interfaz de herramienta unificada, convirtiéndose en un protocolo estándar reconocido dentro de la industria.
Desafíos de Desarrollo y Panorama del Mercado de MCP
El Enigma del Desarrollo
Desde febrero, la comunidad de desarrollo de IA ha sido testigo de una ‘fiebre del oro de MCP’. En ausencia de una tienda de aplicaciones oficial, miles de herramientas se han integrado voluntariamente con el protocolo MCP en tres meses.
Este rápido crecimiento ha impulsado a MCP al centro de atención de la industria, pero también ha expuesto la brecha entre la aspiración y la realidad. Los desarrolladores inicialmente vieron a MCP como una ‘clave universal’, pero han descubierto que es más bien una ‘llave inglesa especializada’, que sobresale en ciertos escenarios pero que resulta menos eficaz en otros.
Los participantes de MCP pueden clasificarse como aplicaciones cliente locales, aplicaciones cliente en la nube y desarrolladores de servidores MCP. Las aplicaciones locales son similares a los asistentes de IA locales, mientras que las aplicaciones cliente en la nube se asemejan a las versiones basadas en la web de ChatGPT. Los desarrolladores de servidores MCP son los proveedores reales de herramientas, que necesitan volver a empaquetar sus APIs para que se ajusten a las reglas de MCP.
El surgimiento de MCP fue inicialmente bienvenido por las aplicaciones cliente locales, pero las aplicaciones cliente en la nube y los desarrolladores de servidores MCP se enfrentaron a desafíos.
MCP se originó en la aplicación Claude Desktop de Anthropic, inicialmente diseñada como un protocolo de interfaz para invocar archivos y funciones locales, profundamente arraigado en las necesidades del lado del cliente.
Para los usuarios de clientes locales, MCP representó una revolución, ofreciendo una caja de herramientas infinitamente expansible que permitía a los usuarios ampliar continuamente las capacidades de sus asistentes de IA.
Las aplicaciones cliente locales como Cursor y Claude Desktop han aprovechado MCP para permitir a los usuarios añadir dinámicamente herramientas basadas en las necesidades individuales, logrando una expansión ilimitada de las capacidades del asistente de IA.
MCP aborda un punto débil central en el desarrollo de clientes locales: cómo permitir que las aplicaciones de IA interactúen sin problemas con los entornos locales y las herramientas externas sin desarrollar interfaces separadas para cada herramienta. Este protocolo unificado reduce significativamente los costes de integración, proporcionando a las pequeñas empresas y a los desarrolladores individuales un atajo para construir aplicaciones de IA ricas en funciones con recursos limitados.
Sin embargo, el atractivo de MCP disminuye al considerar el desarrollo del lado del servidor (MCP Server) y los clientes en la nube. Las primeras versiones de MCP empleaban un mecanismo de doble enlace para los servidores en la nube (remotos), utilizando una conexión larga SSE para el envío unidireccional de mensajes del servidor al cliente y una conexión corta HTTP para el envío de mensajes.
Este enfoque funcionó bien para la retroalimentación e intervención oportuna del usuario, pero creó una serie de desafíos de ingeniería en entornos del lado del servidor.
En primer lugar, la implementación de la interfaz MCP representa una carga de trabajo adicional para los grandes proveedores de servicios empresariales, sin necesariamente generar los beneficios correspondientes. Estos servicios suelen tener sistemas API maduros, y proporcionar una capa de adaptación MCP adicional puede aumentar los costes de mantenimiento sin crear un valor sustancial. Muchas aplicaciones de nivel empresarial prefieren mecanismos de invocación de herramientas cerrados y controlables al ecosistema abierto de MCP.
Además, para manejar las invocaciones de alta concurrencia, los servicios MCP a menudo necesitan escalarse a arquitecturas de múltiples servidores. El modelo de doble conexión de MCP introduce la complejidad del direccionamiento entre máquinas. Cuando se establece una conexión larga en un servidor y una solicitud se enruta a otro servidor, se necesita un mecanismo de cola de difusión adicional para coordinar estas conexiones distribuidas, lo que aumenta significativamente la dificultad de implementación y los costes de mantenimiento.
En segundo lugar, MCP tiene limitaciones en el ámbito de las aplicaciones en la nube. Los Agents de IA en la nube (Agents del lado del servidor) normalmente se ejecutan en servicios sin estado, procesando tareas después de la aceptación y liberando recursos al finalizar. El uso de MCP Client en el lado del servidor requiere la creación temporal de un enlace SSE, el envío de una solicitud de invocación de herramienta, la recepción del resultado del SSE y luego el cierre del enlace SSE, lo que es un enfoque ineficiente que aumenta la complejidad y reduce el rendimiento. Una única solicitud RPC debería ser suficiente en este escenario.
En la práctica, las aplicaciones en la nube que utilizan MCP a menudo se basan en conjuntos de herramientas preestablecidos y no utilizan la capacidad de firma de MCP de descubrimiento dinámico de herramientas y carga flexible.
El modo de interacción de datos de los entornos en la nube limita la capacidad de utilizar libremente las herramientas como MCP pretendía. Requiere un proceso altamente estandarizado para invocar herramientas específicas y codificadas, sacrificando la flexibilidad.
El equipo de MCP ha demostrado capacidad de respuesta a los comentarios de los usuarios. Después de recibir comentarios de los desarrolladores del lado del servidor, MCP actualizó su protocolo el 26 de marzo, reemplazando el transporte SSE original con transporte HTTP transmitible. El nuevo protocolo soporta tanto escenarios de servicio sin estado que requieren solo solicitudes de invocación de herramienta única como requisitos de envío en tiempo real que anteriormente se cumplían a través de enlaces duales HTTP + SSE.
Estas mejoras sugieren que los problemas actuales de MCP provienen de las limitaciones iniciales del diseño, pero no son insuperables.
El Desorden del Mercado
Otro desafío al que se enfrenta MCP es la baja usabilidad de muchas implementaciones en el mercado.
El mercado actual de MCP está experimentando un ciclo típico de exageración tecnológica. Similar al caos de la primera App Store, menos del 20% de las miles de herramientas MCP actualmente disponibles tienen valor práctico. Muchas implementaciones tienen serios problemas, que van desde simples errores de configuración hasta la inutilidad completa. Algunas se lanzan apresuradamente al mercado sin pruebas adecuadas, mientras que otras son productos experimentales que nunca fueron pensados para un uso práctico.
Un problema más fundamental es que muchas implementaciones MCP pueden no ser necesarias para el mercado. Muchasherramientas ofrecidas a través de MCP son simplemente APIs re-empaquetadas que ya estaban disponibles y se utilizaban antes del surgimiento de MCP, añadiendo poco valor único.
Por ejemplo, se ofrecen docenas de servicios de búsqueda a través de MCP, pero su calidad varía significativamente. Algunos servicios pueden ser inexactos o lentos, haciéndolos menos deseables que las soluciones existentes.
Además, MCP carece de un sistema de evaluación robusto, lo que dificulta que los Agents seleccionen la herramienta más adecuada basándose en métricas fiables. Este proceso de selección ineficiente desperdicia recursos informáticos, extiende los tiempos de finalización de las tareas y degrada la experiencia del usuario.
La falta de un sistema de evaluación dificulta que los agents seleccionen la herramienta más adecuada. Si varios servicios MCP ofrecen herramientas con nombres y descripciones similares, el agent puede tener dificultades para elegir la mejor opción, lo que lleva a un desperdicio de tokens y a una reducción de la eficiencia.
Las aplicaciones de IA más exitosas a menudo adoptan el enfoque opuesto, proporcionando herramientas más precisas en lugar de una mayor cantidad de herramientas. Manus, por ejemplo, eligió construir aplicaciones internas en lugar de adoptar el protocolo MCP, a pesar de su existencia. Manus priorizó la precisión y la estabilidad de las llamadas sobre la integración con el ecosistema MCP.
Los editores de código como Cursor tienen funciones de desarrollo incorporadas, lo que hace que la mayoría de las herramientas MCP externas sean redundantes.
El estado caótico actual del mercado MCP no es necesariamente un signo de fracaso, sino más bien una etapa necesaria de crecimiento para cualquier ecosistema tecnológico emergente. Los precedentes históricos sugieren que esta sobreexpansión inicial convergerá gradualmente a través de mecanismos de selección del mercado, dejando atrás los elementos más valiosos.
Este proceso permitirá a la industria aprender de los desafíos actuales y crear un marco MCP más fuerte y fiable. Similar a cómo la burbuja de las puntocom condujo a innovaciones revolucionarias en el comercio electrónico y las redes sociales, la tendencia MCP puede conducir a un ecosistema de herramientas más ágil y valioso.
La actitud abierta del equipo de MCP hacia los comentarios de los usuarios es alentadora, y la industria necesita mejores herramientas para evaluar y asegurar la calidad de los servicios MCP, lo que ayudará a que el ecosistema sea más utilizable.
MCP Es Bueno, No una Panacea
Los problemas mencionados anteriormente provienen de las limitaciones y deficiencias de MCP, destacando lo que puede lograr de manera realista. Sin embargo, otras críticas provienen de expectativas poco realistas.
Una crítica reciente etiqueta a MCP como un protocolo defectuoso porque no dicta los patrones de interacción entre los LLM y MCP.
Algunos esperan que MCP mejore automáticamente la toma de decisiones del sistema de IA o aumente la eficiencia de la planificación de tareas. Esta expectativa confunde las herramientas con los artesanos.
El problema proviene de una falta de coincidencia cognitiva: esperar que un protocolo de comunicación realice tareas de un sistema inteligente. Esto es como culpar a USB por no editar fotos o culpar a los estándares 5G por no escribir código. MCP es principalmente un ‘socket de herramienta’ estandarizado, que garantiza la compatibilidad del enchufe en lugar de dictar qué electrodoméstico usar o cómo.
La eficacia de la invocación Agent-herramienta depende de factores como la competencia en la selección de herramientas, las habilidades de planificación de tareas y la comprensión del contexto, ninguno de los cuales entra dentro del ámbito de MCP. MCP solo garantiza una interfaz de herramienta estandarizada, no cómo se elegirán y combinarán esas herramientas.
A menudo buscamos balas de plata en la tecnología, soluciones universalmente aplicables. Al igual que el axioma de la ingeniería de software ‘no hay bala de plata’, el uso de herramientas de IA no tiene una solución mágica. Un sistema de IA fuerte necesita componentes diseñados: LLM para comprender y generar, marcos Agent para planificar y ejecutar, y MCP enfocado en interfaces de herramienta unificadas.
MCP muestra un buen diseño de protocolo: enfocándose en un problema y resolviéndolo bien, en lugar de todos. Su moderación le ayuda a progresar en la integración de herramientas del lado del cliente.
Entidades como Qwen de Alibaba, ‘Xinxiang’ de Baidu y Kouzi Space de ByteDance abrazan el protocolo MCP, intentando establecer ecosistemas MCP internos más eficientes.
Sin embargo, existen diferencias clave en la implementación: Baidu y ByteDance son más agresivos. Baidu intenta un enfoque C-end, integrando varios modelos de IA y herramientas externas a través del ‘Xinxiang’ (Kokone) aprovechando el protocolo MCP, principalmente para dispositivos móviles, para integrarse en la vida diaria del usuario y fomentar la adopción.
Kouzi Space de ByteDance tiene más de 60 plugins de extensión MCP. Accedido a través de una página web, también lanzó un IDE nativo de IA, Trae, que soporta MCP, principalmente dirigido a escenarios de productividad.
Alibaba integró el protocolo MCP en productos como Alipay, permitiendo la invocación de herramientas de IA con un solo clic, y de código abierto el modelo Qwen3, que soporta el protocolo MCP, mejorando sus capacidades Agent.
Los desarrolladores de Tencent Cloud lanzaron una suite de desarrollo de IA que soporta servicios de alojamiento de plugins MCP. El gran motor de conocimiento del modelo de Tencent Cloud permite a los usuarios llamar a plugins MCP. El agente inteligente de desarrollo de software Craft lanzado por CodeBuddy de Tencent Cloud es compatible con el ecosistema abierto MCP. Además, Tencent Maps y Tencent Cloud Storage han lanzado su propio MCP SERVER.
El uso de herramientas de IA puede evolucionar de una operación directa de herramienta única a una colaboración Agent profesional, al igual que los estilos de programación evolucionaron del lenguaje ensamblador a la orientación a objetos.
En este paradigma, MCP puede simplemente convertirse en parte de la infraestructura subyacente, en lugar de una interfaz orientada al usuario o al desarrollador. Un plan más completo puede requerir arquitecturas como Agent to Agents (A2A) para mejorar la planificación de tareas y la eficiencia de la selección de herramientas aumentando los niveles de abstracción.
Al devolver a MCP su rol de ‘protocolo’, podemos reconocer su verdadero poder para impulsar la estandarización de la industria; este puede ser el momento de ‘desmitificación’ más preciado en la evolución de la tecnología.