En la evolución constante de la tecnología y el desarrollo de interfaces de programación de aplicaciones (API), surge una pregunta relevante y muchas veces debatida: ¿Es necesario el uso de MCP (Machine Comprehension Protocol) para la integración y llamada de herramientas en modelos de lenguaje grande (LLM)? Esta interrogante cobra aún más fuerza cuando se analiza desde una perspectiva tanto tecnológica como sociológica. Tim Kellogg, un reconocido experto en inteligencia artificial y desarrollo de APIs, planteó recientemente en su blog una discusión que invita a reflexionar sobre la efectividad y la necesidad real de MCP en el entorno actual. Para entender mejor el debate, primero es fundamental definir qué es MCP y cuál es su rol en la interacción con LLMs. MCP es un protocolo diseñado para facilitar la llamada y publicidad de herramientas dentro de modelos de lenguaje, permitiendo una comunicación estructurada y eficiente entre el modelo y los servicios externos que pueden ampliar su funcionalidad. La idea central de MCP es proporcionar un estándar sencillo, práctico y enfocado exclusivamente en la integración eficiente con LLMs.
Sin embargo, existe una percepción errónea común sobre MCP: que no se puede incorporar directamente dentro de los prompts o peticiones enviadas a los modelos. Kellogg aclara que, en realidad, el JSON generado por las herramientas MCP puede ser insertado directamente en los prompts, algo que incluso supera ligeramente a la integración de OpenAPI en este sentido. Estas estructuras en JSON son altamente parseables y comprensibles para los modelos actuales, que ya están entrenados para funciones similares y para procesar formatos estructurados como XML o código Python. MCP realiza dos funciones principales dentro de su ecosistema: la publicidad de herramientas disponibles y la llamada o invocación de dichas herramientas. Adicionalmente, maneja aspectos secundarios como el registro de uso y muestreo de datos, aunque su foco y función más implementada y utilizada es el llamado de herramientas.
En este punto, es posible argumentar que OpenAPI puede también desempeñar estos roles con eficacia, ya que cuenta con un estándar muy claro para la documentación y publicación de APIs. No es raro que los archivos openapi.json estén disponibles públicamente para facilitar su consumo por distintas aplicaciones. Una crítica frecuente hacia OpenAPI es su excesiva granularidad en la definición de operaciones y funciones. Por ejemplo, un proceso asíncrono que requiere iniciar una tarea, consultar su estado y finalmente obtener el resultado puede dividirse en múltiples llamadas con diferentes endpoints y métodos.
MCP propone la agrupación de todas estas acciones en una sola operación que abarque el procedimiento completo, lo que reduce la posibilidad de errores en el manejo por parte de los LLMs. La pregunta que surge entonces es: si esta simplificación es valiosa, ¿por qué no puede OpenAPI ofrecer lo mismo? Desde un punto de vista técnico, no hay impedimentos para que OpenAPI adapte su modelo a este tipo de simplificaciones o mejoras en la documentación y el diseño de la API. Además, la incorporación de nuevas tecnologías como Server Sent Events (SSE) está plenamente soportada dentro del ámbito de OpenAPI, lo que facilita la representación de APIs asíncronas y la gestión de eventos en tiempo real. Sin embargo, la incompatibilidad o resistencia proviene principalmente de aspectos sociológicos dentro de los equipos de ingeniería. Históricamente, el desarrollo y mantenimiento de APIs ha estado regido por preocupaciones en torno a la latencia y el performance.
Los equipos iconoclastas miden meticulosamente el tiempo que toma cada operación, alertando y diagnosticando rápidamente cuando alguna excede lo esperado. En este escenario, una operación que implica un largo tiempo de respuesta suele ser vista con recelo y motivo para optimizaciones, cuando no para desmembrarla en partes más pequeñas y rápidas. Esto genera que los desarrolladores prefieran APIs síncronas o asíncronas convencionales, en lugar de aprovechar los avances tecnológicos para integrar sistemas más robustos y complejos, como los que permite MCP. La aceptación y la adopción de un estándar en la industria también depende de factores sociales y culturales más que de su superioridad técnica. MCP destaca dentro de la comunidad por ser pequeño, directo y enfocado únicamente en la integración y gestión de herramientas para LLMs, lo que lo hace más accesible y fácil de implementar en comparación con OpenAPI, que es más extenso y general.
Este carácter minimalista y especializado se traduce en una estandarización más clara y limitada, reduciendo las ambigüedades que comúnmente afectan la implementación de APIs REST, donde por ejemplo, se debate si un recurso debería ser modificado con PUT o con POST, o cómo utilizar correctamente los headers, query params y la estructura del cuerpo del mensaje. Standardizar a través de un único enfoque puede ahorrar días o semanas en el desarrollo al evitar discusiones innecesarias sobre cómo debería diseñarse o implementarse un API. MCP aporta esta ventaja a las organizaciones, fomentando un lenguaje común que mejora la comprensión y el intercambio entre equipos y servicios. A pesar de esto, Tim Kellogg señala que desde un punto de vista puramente tecnológico, MCP no introduce nada que OpenAPI no pueda replicar o superar. De hecho, existe una correspondencia casi isomórfica entre lo que ofrece MCP y lo que puede representar un servidor OpenAPI.
Esto implica que la elección entre uno u otro recae más en cuestiones prácticas y sociológicas que en diferencias técnicas tangibles. La estandarización como concepto es en sí misma un avance social. No solo regula la interoperabilidad entre tecnologías, sino que también establece reglas, normas y prácticas que influyen en cómo las personas y equipos trabajan entre sí. En este contexto, la popularidad de MCP se explica más por un consenso en la industria, una convergencia hacia una herramienta que satisface las demandas puntuales de los desarrolladores de LLMs actuales, que por sus méritos tecnológicos exclusivos. En el plano de la experiencia del usuario, esta estandarización puede traducirse en una integración más rápida, documentaciones más legibles y coherentes, así como una curva de aprendizaje menor para quienes implementan o consumen APIs en relación con modelos de lenguaje.
Otra ventaja de MCP es su alineación natural con las funciones llamadas por los LLMs, que suelen esperar operaciones claras, directamente relacionables con acciones concretas, en vez de un complejo entramado de recursos y métodos HTTP variados. Esto simplifica el proceso, mejorando la experiencia tanto para los desarrolladores como para los usuarios finales. Aun así, no debemos perder de vista que el futuro de las APIs y la integración con inteligencia artificial es dinámico y está en constante cambio. Los estándares actuales pueden evolucionar o dar lugar a nuevas propuestas que superen las limitaciones que hoy consideramos inamovibles. Por lo tanto, la discusión sobre la necesidad o no de MCP debe verse como un llamado a la crítica constructiva y a la innovación continua.
Concluyendo, aunque MCP puede parecer innecesario desde una visión estrictamente técnica, su verdadera fortaleza radica en eliminar la sobrecomplicación y brindar un camino más sencillo y uniforme para la integración con modelos de lenguaje. OpenAPI tiene el potencial para cubrir todas estas funciones, pero la falta de consenso en la comunidad y la complejidad inherente a su diseño hacen que MCP sea la opción preferida en muchos casos. Finalmente, comprender las diferencias entre ambas opciones y las razones sociales que influencian su adopción permite a los equipos tomar decisiones más informadas para implementar soluciones que sean eficientes, sostenibles y adaptadas a las necesidades reales de sus proyectos y del ecosistema IA en general.
