Qué comprobar en la aceptación de integración tras la nueva especificación de MCP

Los cambios en MCP pasan de definir cómo hacer visible una herramienta para un modelo a garantizar que su integración sea un servicio mantenible a largo plazo. Para ti como desarrollador, la acción más valiosa no consiste en actualizar la fecha del protocolo en la configuración, sino en verificar qué conjunto de comportamientos admiten realmente el cliente, el servidor y la red intermedia.

Este artículo analiza la especificación MCP 2026-07-28 y la hoja de ruta publicada posteriormente, con datos verificados al 5 de septiembre de 2026. No constituye un anuncio de actualización de EveryInfra ni implica que los cambios mencionados se encuentren activos en EveryInfra o en el cliente que utilices.

Distingue entre especificaciones publicadas y planes futuros

Los mantenedores de MCP publicaron formalmente la versión 2026-07-28 en el anuncio del 28 de julio, donde el núcleo del protocolo sin estado figura como uno de los cambios principales. Esto difiere de dar por hecho que un servicio ha completado su migración: la especificación indica a los implementadores qué pautas seguir, mientras que las notas de versión y la respuesta real de cada servicio determinan lo que puedes utilizar en cada momento.

La nueva hoja de ruta del 22 de agosto plantea direcciones adicionales como la identidad de agentes, la expresión de resultados y el descubrimiento gradual de herramientas. Incluir estas propuestas en una lista de funciones ya soportadas por la versión más reciente de MCP genera valoraciones erróneas. La hoja de ruta ayuda a comprender la dirección del proyecto, pero no sustituye la implementación pendiente en un cliente específico.

En la discusión de Hacker News sobre esta hoja de ruta surgieron dudas acerca del cumplimiento de los nuevos requisitos por parte de los servicios y sobre la carga progresiva de herramientas. Esto aporta pistas de interés periodístico, no una encuesta de adopción en el ecosistema. Nuestro foco se centra en la cuestión práctica derivada de esta situación: si dos puntos de conexión que afirman ser compatibles con MCP utilizan realmente el mismo lenguaje de protocolo.

La eliminación de la sesión de protocolo traslada la responsabilidad al ámbito de negocio

Conforme al registro de cambios oficial, la nueva versión elimina el protocolo de inicio de sesión anterior y los identificadores de sesión a nivel de protocolo. Las aplicaciones que requieran conservar estados entre llamadas pueden utilizar identificadores de negocio explícitos. Esto significa que el protocolo deja de depender de sesiones ocultas en la conexión para retener el contexto, permitiendo que la aplicación gestione sus propias tareas, recursos y estados.

Esta aproximación al diseño de integraciones indica que debes evitar sustituir la propiedad clara de las tareas por la mera persistencia de la conexión. Cualquier operación prolongada debe permitir identificar quién la inició, qué usuario cuenta con permisos de consulta, en qué estado se encuentra y cómo verificar el resultado si la red se desconecta.

Considera un escenario hipotético donde un agente inicia una tarea de generación de informes y el cliente pierde la conexión de red. Al reconectarse, necesitas comprobar si el informe se generó, más allá de verificar la conectividad con el servicio. Si la aplicación carece de identificadores de tarea y mecanismos para consultar resultados, los usuarios podrían enviar el mismo trabajo repetidamente a pesar de simplificarse las conexiones del protocolo.

Por este motivo, recomendamos diseñar de forma independiente el número de solicitud del protocolo, el identificador de la tarea de negocio y el mecanismo de prevención de ejecuciones duplicadas. Es posible mantener relaciones entre ellos, pero la existencia de uno no garantiza que los otros dos problemas estén resueltos. Se trata de un criterio de diseño de la aplicación y no de una garantía automática de idempotencia que MCP proporcione a todos los procesos de negocio.

Una gestión más sencilla en HTTP no exime de realizar comprobaciones adicionales

La nueva versión de la especificación Streamable HTTP define cabeceras de metadatos de solicitud como Mcp-Method y utiliza Mcp-Name en los métodos aplicables. Los campos de las cabeceras y del cuerpo deben coincidir. Dado que la especificación sigue permitiendo respuestas SSE dentro del ámbito de la solicitud, no debes simplificar este cambio asumiendo que MCP prescinde por completo de las respuestas en flujo.

Estos diseños facilitan que las capas intermedias distingan las solicitudes, si bien el uso requiere realizar dos tipos de validación. La primera corresponde a la verificación del protocolo para confirmar si obtienes un error claro ante cabeceras ausentes, versiones no soportadas o discrepancias entre la cabecera y el cuerpo. La segunda corresponde a la verificación de negocio para comprobar si el usuario actual posee autorización para ejecutar una herramienta concreta o acceder a un recurso determinado tras identificarse la llamada.

Imagina una cuenta con permisos exclusivos de lectura que configura la cabecera para consulta pero solicita una modificación en el cuerpo. Si la capa intermedia y la capa de aplicación confían parcialmente en los datos, el sistema puede generar incoherencias. Las pruebas prácticas deben simular este tipo de solicitudes inofensivas e incongruentes para confirmar su rechazo, sin limitarse a comprobar que una cabecera correcta obtiene luz verde.

Asimismo, un código HTTP 200 indica únicamente que la solicitud obtuvo una respuesta normal, pero no garantiza que la operación de negocio haya concluido. Una herramienta puede devolver errores de negocio, requerir datos de entrada o proporcionar resultados parciales. Gestionar adecuadamente la devolución de estos estados a los usuarios resulta más prioritario que mostrar todas las respuestas como operaciones exitosas. Para profundizar en el diseño de clasificaciones de errores, consulta el artículo sobre métodos de manejo de errores de API y autorrecuperación disponible en nuestro sitio.

Los directorios admiten caché, pero los permisos exigen validación constante

La nueva especificación incorpora ttlMs y cacheScope en respuestas como los directorios para indicar sugerencias de frescura y ámbitos de caché compartida respectivamente. Los objetos de aplicación específicos se detallan en la sección de caché del registro de cambios. Aunque esto ayuda a disminuir descubrimientos repetidos e innecesarios, no representa el compromiso de que el inventario de herramientas permanezca inalterable de forma indefinida.

Puedes concebir el directorio como un mapa dotado de marcas temporales e identidades de uso aplicables. Este mapa guía al modelo en la selección de herramientas, mientras que la ejecución final requiere someterse de nuevo a controles de permisos y parámetros. El hecho de que un usuario haya visualizado una herramienta en el pasado no garantiza su disponibilidad permanente.

Conviene validar un caso concreto: cuando se retiran los permisos a un usuario y el cliente conserva un directorio obsoleto. La experiencia de usuario ideal no consiste en que la herramienta desaparezca de forma silenciosa o falle sin aviso, sino en que el punto de ejecución rechace la solicitud de manera explícita, permitiendo al cliente explicar el motivo y actualizar el directorio en el momento oportuno. Evita enmascarar modificaciones en los permisos mediante la ampliación del tiempo de caché.

Si estás construyendo tu propio directorio de capacidades, puedes continuar leyendo el artículo por qué los directorios de capacidades en tiempo real necesitan verificabilidad. Dicha publicación analiza la relación entre los directorios y el comportamiento real, sin implicar que la plataforma haya implementado la totalidad de los mecanismos de caché de esta nueva especificación.

La conexión establecida no resuelve los problemas de identidad

La validación de la identidad en el servidor de autorización forma parte de los cambios de esta especificación. El parámetro iss definido en el estándar RFC 9207 ayuda a que el cliente confirme si la respuesta de autorización procede del emisor esperado, previniendo confusiones en el servidor de autorización. Este estándar resuelve una categoría específica de problemas de identidad, mas no constituye el interruptor general para toda la seguridad de los agentes.

Desde una perspectiva de producto, la identidad abarca al menos tres cuestiones diferenciadas: qué usuario realiza la acción en curso, qué acciones permite realizar el usuario para esta tarea específica y qué privilegios concede realmente el servicio durante la ejecución. El hecho de que un usuario complete un inicio de sesión no equivale a concederle autorización para cualquier operación posterior de envío, eliminación o adquisición de recursos.

Aconsejamos mostrar de nuevo los objetos clave y sus consecuencias antes de ejecutar acciones de gran impacto. Por ejemplo, la modificación de configuraciones debe especificar el entorno y los campos afectados, mientras que el envío debe detallar el destinatario y el contenido. El modelo puede asistir en la preparación de la operación, pero la autorización no debe quedar oculta únicamente en una descripción ambigua de la herramienta.

Esto explica por qué contar con un servicio compatible con OAuth, un cliente que soporte MCP y herramientas enumeradas no constituye por separado un resultado de aceptación para entornos de producción. El descubrimiento mediante el protocolo, la autorización de identidades y la finalización de las tareas deben contar con evidencias verificables independientes.

Establece una matriz de aceptación clara y concisa antes de actualizar

Al verificar tu implementación según las instrucciones oficiales de versión y compatibilidad, te sugerimos listar de manera individual cada combinación de uso real en lugar de registrar una única línea con el texto genérico «MCP: soportado». Cada fila debe incluir el cliente y su versión, la versión del protocolo soportada por el servidor, los mecanismos de transporte y autenticación utilizados, las operaciones verificadas y las capacidades pendientes de validación.

La primera ronda no requiere probar todas las herramientas, pero sí debe cubrir los escenarios que alteran la evaluación de entrega:

• Una tarea de solo lectura devuelve resultados comprensibles que corresponden al usuario y al objetivo actuales.
• Las versiones no compatibles, los parámetros erróneos y las credenciales inválidas se rechazan explícitamente sin derivar en resultados vacíos aparentes.
• El servicio omite la ejecución de la acción si el usuario rechaza una operación de alto impacto.
• Ante la interrupción de una solicitud, es posible determinar el estado original de la tarea y se evita repetir automáticamente operaciones con efectos secundarios cuando el resultado es incierto.
• Tras un cambio de permisos, los directorios o conexiones obsoletos pierden la capacidad de proporcionar accesos revocados.

Estos puntos corresponden a nuestras recomendaciones de aceptación de integración y no representan informes de pruebas concluidos por este medio para ningún producto. Las instrucciones de integración vigentes para EveryInfra se consultan en aceptación de integración de MCP remoto; al leerlas debes conservar sus versiones específicas y límites de prueba reales, sin interpretarlas como una certificación de compatibilidad con la especificación 2026-07-28.

La decisión de actualizar debe responder en última instancia a una cuestión concreta: si la nueva versión soluciona un problema específico en el despliegue o uso actual y si las combinaciones clave de clientes operan de forma estable. Si la respuesta genera dudas, completa primero la validación de compatibilidad; si la respuesta resulta clara, procede con la migración y la estrategia de reversión. La actualización en la fecha del protocolo es solo el punto de partida, pues el verdadero resultado consiste en que los usuarios completen sus tareas de forma continuada.