WTF? MCP, A2A?

Versión no técnica

Imagina que una empresa de autos anuncia que, para usar su nuevo modelo, necesitas construir un garaje especial con quince requisitos diferentes. Suena absurdo, ¿verdad?

Bueno, eso acaba de pasar en el mundo de la IA. Y todos Google, OpenAI, Microsoft dijeron: ¡qué gran idea!

La historia que no te están contando

En noviembre de 2024, Anthropic (creadores de Claude) lanzó algo llamado MCP (Model Context Protocol). Prometía hacer que las IA pudieran conectarse mejor con tus herramientas de trabajo.

Lo sorprendente: en marzo de 2025, OpenAI su mayor competidor lo adoptó. Luego Google. Luego Microsoft (aunque están por “mejorarlo”).

¿Por qué sorprende? Porque es como si Coca-Cola adoptara la receta de Pepsi. No pasa. Excepto que sí pasó.

El problema que nadie quiere admitir

MCP está confundiendo abiertamente a muchos desarrolladores, alentándolos a implementarlo en aplicaciones con LLM (propietarias) para incorporar funcionalidades externas: bases de datos, APIs, búsquedas, etc.

Y esto provoca un mercado ignorante, lo que equivale a crear soluciones complejas, caras y difíciles de mantener. La realidad es que MCP fue desarrollado para usarse en aplicaciones de escritorio, donde tuviera acceso a recursos locales y a herramientas que se “instalan”.

¿Por qué todas las empresas lo adoptaron?

No por ser mejor. Por tres razones muy humanas:

• FOMO corporativo: “si OpenAI lo adoptó, debe ser importante”.
• Seguro político: “nadie fue despedido por seguir el estándar”.
• Ilusión de sofisticación: “complejo debe significar avanzado”.

Pero si tu negocio se basa en entregar valor a través de ecosistemas (vendes una herramienta, consultorías, fuerza de trabajo, etc.), MCP claramente es válido aunque sugiero ver más allá.

Una visión de ecosistema se dará cuando las herramientas se coordinen, proponiendo formas de trabajo en conjunto para distintos fines. MCP y A2A son el primer borrador, casi una declaración de intención.

Versión técnica

Últimamente veo posts explicando las “profundas diferencias” entre Model Context Protocol (MCP), Agent-to-Agent Protocol (A2A) y Function Calling. Como alguien que ha implementado estos sistemas, les ahorro tiempo: es todo function calling con distintos niveles de marketing.

La verdad simple

Function Calling es el concepto base: un LLM analiza tu pregunta y decide qué función ejecutar. Pero ni siquiera necesitas function calling. Lo más primitivo (si no quieres lidiar con parsing) es structured output: defines un JSON schema con los valores posibles y luego, en tu función, haces lo que necesites.

Entonces, MCP es solo un framework que envuelve function calling con:

• Un formato JSON específico (JSON-RPC 2.0).
• Un servidor que corre en un proceso separado.
• Comunicación por stdio.
• Un archivo de configuración.

A2A es... bueno, más marketing para describir cuándo las funciones se llaman entre sí, aislando LLMs.

¿Por qué importa esta distinción?

Porque el 90% de los developers no necesita la complejidad de MCP. Si estás construyendo un producto, probablemente solo necesitas esto:

tools = {
    "search_db": lambda q: db.query(q),
    "send_email": lambda to, msg: email.send(to, msg),
}

# El LLM elige la herramienta; tú la ejecutas.
result = tools[llm_choice](llm_args)

Cinco líneas. Sin servidores separados, sin configuración JSON, sin “protocolos”.

Pero OpenAI, Microsoft y Google tienen MCP...

Falso. Lo que adoptaron es incorporar nuevos métodos en sus SDKs para que puedas interactuar con los requests HTTP hacia sus APIs de LLMs, pero a través del “estándar” MCP. Es decir: los nuevos métodos siguen el patrón de argumentos que Anthropic publicó.

¿No se entiende? Simple: instalar un “MCP” de cualquiera de estas compañías es agregarle a tu proyecto una complejidad que, al final, traduce todo a function calling.

¿Cuándo SÍ tiene sentido MCP?

Para aplicaciones de escritorio o pseudo-”RPA” motorizado por LLMs que necesitan plugins de terceros:

• Claude Desktop
• Cursor
• IDEs con IA

Básicamente, cuando necesitas que los usuarios finales instalen o desinstalen capacidades sin tocar código. También hay otros puntos válidos: por ejemplo, cuando el esfuerzo de integración pasa de M×T a M+T (M = Model, T = Tool); es decir, dispones de un modelo con múltiples herramientas a bajo esfuerzo (aunque riesgoso). Y por supuesto, sin dejar fuera a los productos o servicios que evidentemente se benefician de estos ecosistemas y se transforman en esas “tools”.

El problema real

Estamos creando categorías artificiales y complejidad innecesaria. Es como decir que hay “profundas diferencias” entre:

• Una función de JavaScript.
• Una función envuelta en una clase.
• Una función expuesta por una API REST.

Son solo distintas formas de empaquetar lo mismo y, evidentemente, según el público tendrá sentido una u otra.

Mi propuesta: MCT (Model Context Tools)

En lugar de “protocolos” inflados, definamos solo lo importante:

• Un estándar de input/output JSON para las herramientas.
• Implementa como quieras: función directa, API REST, lo que sea.
• Sin ceremonias innecesarias.

Con el primer punto, todos hablamos y escuchamos en el mismo idioma. Adaptas a tus necesidades, entiendes lo que implementas, simplificas y mantienes mejor el código.

Para los builders

Si estás construyendo productos con IA:

• No necesitas MCP para tu backend.
• No necesitas “protocolos” para que tu LLM llame funciones.
• No necesitas procesos separados para cada herramienta.

Mantén la simplicidad. Tu producto y tu equipo te lo agradecerán.

Ideas finales

Como toda moda, va y viene. Ahora se llama MCP, A2A; se crearán conceptos A2XYZ, y así sucesivamente. Pero lo más relevante es que, al final del día, con conocimiento puro y duro (no necesita ser técnico) más capacidad crítica (fundamental en lo contemporáneo), te darás cuenta de que las decisiones a cualquier nivel siempre deberían fundamentarse en las necesidades reales, no en las que generan industrias que, lamentablemente, cada día vemos impulsadas de forma ficticia por tecnócratas.

Finalmente: si bien el concepto original de MCP y A2A son, en mi opinión, intentos de las áreas de ingeniería y marketing de estas empresas de LLMs propietarios para impulsar el uso de sus productos, el futuro que depara en este aspecto será más bien la gestación, por parte de Google, Apple, Microsoft, etc. de marketplaces de “agentes” (funciones y código ejecutado por decisión de un LLM), que por supuesto usarán sus propios LLMs, locales o en la nube.

Con esta última idea abro espacio al futuro que están y estoy desarrollando...