Especificación de MCP: cambios en la versión 2025-06-18

• La nueva actualización de la especificación de MCP pone el foco en metadatos estructurados y gestión de contexto. Su objetivo es mejorar la extensibilidad y reforzar la interoperabilidad entre distintos sistemas
• Se agregan nuevos campos de datos y los campos obligatorios existentes se definen con mayor precisión. La jerarquización de la estructura de metadatos permite admitir métodos de extensión separados para cada sistema
• Se presentan reglas claras para el seguimiento de contexto y la actualización de atributos, con énfasis en una gestión más consistente de la información de estado frente a versiones anteriores
• Los procedimientos de gestión de permisos y validación de datos quedan especificados en el protocolo. Algunos de los campos recién añadidos están pensados considerando la compatibilidad con futuras versiones del protocolo
• Soporte para integración multiplataforma: proporciona una base para intercambiar datos de contexto de forma consistente incluso entre varias plataformas de IA y entornos de servicios en la nube

---

• MCP(Model Context Protocol) es un protocolo para el intercambio de metadatos de contexto entre diversos sistemas de IA, como modelos de aprendizaje automático o modelos de lenguaje de gran tamaño

Major changes

1. Se eliminó el soporte para JSON-RPC batching (PR #416)
2. Se agregó soporte para structured tool output (PR #371)
3. Se clasificó el servidor MCP como un servidor de recursos OAuth y se agregaron metadatos de recursos protegidos para facilitar el descubrimiento del servidor de Authorization vinculado (PR #338)
4. Se exige que el cliente MCP implemente el Resource Indicator de RFC 8707 (para evitar que un servidor malicioso obtenga access tokens) (PR #734)
5. Se aclararon las security considerations y las best practices dentro de la especificación de Authorization, y se añadió una página separada de guía de seguridad
6. Se agregó la función de Elicitation (solicitud de consulta), para que el servidor pueda pedir información adicional al usuario (PR #382)
7. Se agregó soporte para Resource Links, permitiendo incluir enlaces de recursos en los resultados de llamadas a herramientas (PR #603)
8. Durante la negociación de versión del protocolo, en HTTP ahora es obligatorio el encabezado MCP-Protocol-Version (PR #548)
9. En Lifecycle Operation, SHOULD cambió a MUST (referencia)

---

Other schema changes

1. El campo _meta se agregó a más tipos de interfaz (PR #710) y se especificó su uso adecuado
2. Se agregó el campo context a CompletionRequest, lo que permite incluir variables interpretadas previamente (PR #598)
3. Se agregó el campo title para una visualización amigable para el usuario separada del identificador para programas (name se usa como identificador de código y title para visualización) (PR #663)

[kernel00]

El comentario de Hacker News deja un poco que desear. Parece que solo vieron stdio, pero ahora mismo están apareciendo por todas partes los servidores MCP remotos y los registros que los intermedian...

[GN⁺]

Comentarios de Hacker News

• Lo más importante que aprendí con todo el boom de MCP (Machine Context Protocol) es que, en desarrollo de software backend, realmente no hace falta usar MCP. Hay partes donde arquitectónicamente no encaja. En entornos como Elixir, todavía menos. Si pones un servidor separado por cada API, eso significa correr 500 microservicios para 500 APIs. No me di cuenta hasta después de haber probado unas 20 clases de servidores MCP, pero al final MCP no era más que una envoltura para llamadas de funciones. Cada API basta con implementarla como un módulo aparte, no como un servidor. No hace falta seguir cada nueva versión de la especificación de MCP ni actualizar cientos de microservicios cada vez que cambie. Mi conclusión es que solo añade complejidad innecesaria
  • A menos que el cliente se conecte directamente a cada microservicio sin pasar por un gateway o un BFF, basta con poner MCP delante del servicio completo y exponer funciones como se ha hecho siempre con API, GraphQL, RPC, etc. Se siente básicamente como una interfaz especializada para LLM. Incluso las tool calls basadas en especificaciones OpenAPI son suficientes. En cualquier caso, imaginar que todos los microservicios van a comunicarse entre sí solo por MCP es exagerado
  • Yo veía MCP solo como una solución de integración estilo plugin que permite function calls sin costo de API, como en Claude. Si ya usas APIs y no tienes urgencia, realmente no es algo necesario
  • En realidad, creo que MCP es un protocolo estándar para conectar al cliente con el modelo. No es simplemente un contenedor que envuelve tool calls
  • Sí, tener un servidor MCP por API no escala. Si usas algo como nango.dev, un solo servidor puede cubrir más de 400 APIs. También ofrece manejo de autenticación, visibilidad y varias interfaces para hacer tool calls directamente. (Por cierto, soy el fundador)
  • Yo iría incluso más lejos: toda esta cultura de obligar al LLM a producir JSON me parece absurda. Se pierde demasiado tiempo y esfuerzo adaptándolo a un formato delicado que al LLM ni siquiera le gusta de manera natural. Un DSL basado en texto, mucho más restringido, me resultó una alternativa bastante mejor. En la época de GPT 3.5, con solo poner unos ejemplos simples en el prompt ya lograba que generara de forma confiable un DSL en inglés. Pero incluso los modelos más recientes siguen advirtiendo que a veces ignoran partes del JSON schema. Se siente como intentar meter un clavo redondo en un agujero cuadrado; ojalá todos dejaran de forzarlo
• De verdad me alegra que ahora exista una ruta simple hacia servidores MCP autenticados. Quiero expresar mi agradecimiento sincero a la comunidad de MCP y al equipo de Anthropic
  • No me queda claro por qué hace falta un servidor MCP. Si un agente quiere hacer RPC, ¿no bastaría con usar RPC directamente?
• Me parece muy curioso que la especificación central esté escrita en TypeScript en lugar de OpenAPI u otra cosa. Seguro hay una razón válida, pero igual se siente inesperado
  • Me da curiosidad por qué eso te sorprende. Yo también uso mucho TypeScript, pero nunca lo había pensado desde ese ángulo, así que me interesa saber qué decisiones hubo del lado del diseño del lenguaje
• Me alegra muchísimo que hayan introducido el challenge de WWW-Authenticate. Ahora quedó mucho más claro el flujo en el que el servidor MCP redirige al cliente al flujo OAuth del proveedor de recursos y solo tiene que recibir el header Authorization: Bearer ...
• Creo que en su <i>mayor parte</i> sí es complejidad innecesaria, pero extrañaré la ejecución por lotes. Fue divertido implementar algo como “haz todas estas tareas y responde con el resultado de una sola vez”. Claro, el cliente también podría agrupar por su cuenta las respuestas por lotes, pero igual tenía su encanto
  • Totalmente. La funcionalidad de lotes de JSON-RPC me hizo pensar “wow, esto está interesante”. Da pena que salga de la especificación, aunque también entiendo que al final solo agrega más complejidad
• Creo que la gran ganancia es la elicitation (manejo de prompts basado en inferencia). Uno de mis servidores MCP favoritos es un servidor SSH que hice yo mismo. Puedo automatizar el 90% del trabajo completo sobre servidores. La autenticación la manejo con un archivo de configuración, pero cuando necesito conectarme a un servidor nuevo tengo que editarlo manualmente, así que es un poco incómodo
  • En ese caso, también podrías usar algo como fabfile.org. Si es una conversación donde no hace falta meter un LLM, me parece mejor mantenerlo en privado
• En los últimos días estuve jugando con MCP para crear un wrapper de datasets

1. Me parece uno de los intentos más emocionantes en el mundo de los LLM. Claro, algo parecido podría hacerse con APIs y tool calls tradicionales, pero fue muy impresionante poder pasarle a un amigo que no es tan técnico solo una URL de MCP para Claude y que pudiera usarlo con unos cuantos clics
2. Estoy usando el SDK de csharp, y la parte de autenticación todavía solo existe en una rama, así que está muy verde. El 95% del tiempo de mi integración con MCP se fue en implementar autenticación (si no es un build local, es indispensable). Supongo que mejorará cuando haya más documentación, pero por ahora es un proceso bastante manual
3. También hace falta más visibilidad en los logs para desarrolladores. Me gustaría que Claude mostrara en modo desarrollador los logs de request/response de lo que intercambia en la web (no en desktop) y dónde ocurren los errores. Perdí muchísimo tiempo con un problema de renovación de autenticación, y solo después me di cuenta de que yo estaba registrando el endpoint equivocado. Si hubiera habido mejores logs de MCP, lo habría resuelto en minutos. En desktop y en MCP inspector sí funciona bien
4. Lo que más me preocupa es el manejo de tareas largas. El dataset que expongo consiste en varios documentos PDF. Parece que Claude por sí mismo no puede trabajar con PDF (si alguien sabe cómo, que me diga). Así que por ahora los convierto a texto pasando antes por gemini y luego los entrego por MCP. Los documentos simples funcionan bien, pero los largos tardan bastante en procesarse. Por ahora solo envío un mensaje de “se está procesando, inténtalo más tarde”. Existe la API de progreso, pero parece poco práctica porque obliga a mantener una conexión persistente con el servidor (y en Cloudflare se corta después de cierto tiempo). Sería genial que existiera una forma de hacer que el LLM volviera a revisar después de x segundos y, mientras tanto, siguiera con otras tareas, quedando “pausado temporalmente” hasta que expire el temporizador. Tal como está ahora, si mantienes la conexión abierta el LLM se queda esperando sin poder hacer nada, y si devuelves un job ID y sales, muchas veces la respuesta queda incompleta y se pierde el contexto general. Me parece que esto puede ser un gran obstáculo para tareas que toman más de 10 minutos

• Las tareas de larga duración siguen siendo un tema en discusión pública. Entiendo que MCP sí tiene la intención de resolverlo en el futuro. Han circulado varias propuestas, y como no siempre se sabe de antemano si una tarea va a tardar mucho, separar una API específica para tareas largas no resuelve por sí solo el problema. Yo mismo tengo una propuesta para abordarlo de forma integrada en esta discusión
• Me alegra mucho ver que la especificación de MCP está mejorando tan rápido. Con cada nuevo release veo que se va cubriendo uno por uno lo que yo extrañaba en mis integraciones con MCP
• Me pareció curioso que para aprobar un cambio en la especificación baste con una sola aprobación
• No termino de entender qué problema resuelve MCP en la práctica. Personalmente, solo se me ocurre su papel al prototipar algo rápido en una laptop. Si yo fuera a hacer un programa local, querría controlar de forma mucho más fina el conjunto de herramientas al que puede acceder el LLM. Por ejemplo, incluso pensando en un servidor MCP para Google Calendar, MCP no me ahorra tanto tiempo. Yo mismo podría usar la misma API, y además tendría que explicarle explícitamente al LLM cuándo y cómo llamar a Google Calendar, así que no quisiera delegárselo a un tercero. También me incomoda lanzar procesos arbitrarios en mi entorno sin importar en qué lenguaje esté escrito el MCP. Si mi lado está en Python y además tengo que pedirle al usuario que instale un runtime de TypeScript, puede ser problemático. Si aparece una vulnerabilidad en el wrapper de MCP, también me preocuparía por temas de seguridad. En entorno servidor es aún más difícil justificarlo. RPC ya es una forma excelente de invocar cosas entre máquinas distintas sin conocer los detalles de implementación. MCP se siente como una capa intermedia con muchas opiniones y más problemas de seguridad encima
  • Lo que no entiendo es por qué todos los MCP que he visto hasta ahora son basados en comandos y no usan una interfaz HTTP. Si fueran por HTTP, podrías levantar un solo servidor y compartirlo en toda la organización, sin que cada persona tenga que configurar su propio toolchain
  • A diferencia de los enfoques tradicionales donde el backend impone un flujo fijo, con MCP la ventaja es que el propio LLM puede encargarse directamente de la orquestación. Por ejemplo, al hacer búsquedas web puede reformular la consulta e intentarlo de nuevo hasta encontrar la información deseada. También al resolver problemas específicos por CLI puede usar varias herramientas en el orden apropiado. Ese tipo de organización no es posible con flujos fijos
  • Lo que resuelve MCP es conectar, desde una lógica centrada en el LLM, a agentes y herramientas mediante un protocolo estandarizado
  • También coincido bastante con eso. Cuando lo usas en la práctica, se siente lentísimo. Yo incluso dejé mi trabajo hace 2 años para desarrollar un cliente de LLM y todavía no he logrado integrar Google Calendar. Aun así, desde la perspectiva del usuario, MCP sí sirve para tapar este tipo de huecos temporales. Me acuerdo de esa idea de que en el iPhone las primeras tres filas de la pantalla de inicio se parecen entre sí, pero la última fila es completamente distinta para cada quien. Tengo la impresión de que, de aquí en adelante, los equipos de TI y de desarrollo van a seguir creando sus propios servidores MCP adaptados a su trabajo específico