Servidores Guías
En esta página
Básico Lección 3 de 17 ≈ 30 min de lectura
Especificación 2026-07-28
Cómo viaja una petición
Especificación MCP 2026-07-28 · revisada el 2 de octubre de 2026
El protocolo MCP sin estado: qué lleva cada petición, cómo se negocia la versión, qué forma tienen resultados y errores, y cómo funcionan el progreso, la cancelación y los cortes de stream.
Qué aprenderás
- Leer una petición MCP completa y explicar qué aporta cada clave de _meta
- Decidir cuándo llamar a server/discover y cómo reaccionar a un rechazo de versión
- Clasificar un fallo como error de protocolo o de ejecución y elegir el código correcto
- Activar el progreso de una petición y cancelarla sabiendo qué cambia entre stdio y Streamable HTTP
- Diseñar tools que sobrevivan a un stream cortado sin duplicar efectos
Contenido de la lección
- 01 El problema
- 02 Cada petición se explica sola
- 03 Lo que vuelve: resultados y errores
- 04 `server/discover` y la versión
- 05 Peticiones largas: progreso y cancelación
- 06 Cuando se corta el stream
- 07 En producción
Además: quiz de comprobación y desafío práctico.
Extracto
El servidor nortia-pedidos atiende a los agentes de soporte de España y México desde mcp.nortia.example. En horas punta corre en cuatro réplicas detrás de un balanceador que reparte cada petición a la réplica menos cargada. Las réplicas se crean y se destruyen según la demanda.
Con un protocolo que empieza por un saludo y recuerda lo acordado, ese despliegue se complica. Solo la réplica que recibió el saludo sabe qué versión y qué capacidades tiene el cliente. Así que hay que fijar cada cliente a una réplica o compartir ese recuerdo entre todas. Cuando una réplica muere, además, el recuerdo se va con ella.
Fin del extracto · la lección sigue con 6 secciones más
Artículos relacionados
Preguntas frecuentes
¿Qué significa que MCP sea un protocolo sin estado?
Significa que, desde la especificación 2026-07-28, no hay saludo inicial (initialize) ni sesión: cada petición lleva todo lo que el servidor necesita para procesarla. En el _meta de cada petición viajan obligatoriamente io.modelcontextprotocol/protocolVersion y io.modelcontextprotocol/clientCapabilities, y si falta alguna el servidor la rechaza con -32602. Por eso cualquier réplica detrás de un balanceador puede atender cualquier petición sin afinidad, y el estado que dure varias peticiones tiene que ir en un identificador explícito que el cliente envía cada vez.
¿Para qué sirve `server/discover` en MCP?
Es la petición con la que un cliente pregunta a un servidor qué versiones del protocolo soporta y qué capacidades ofrece, ahora que no hay handshake. Todo servidor debe implementarla y para el cliente es opcional; devuelve supportedVersions, capabilities, opcionalmente unas instructions para el modelo, y se puede cachear según ttlMs y cacheScope. La versión no se negocia ahí: cada petición declara la suya y, si el servidor no la implementa, responde -32022 con data.supported y data.requested para que el cliente reintente con una versión común.
¿Qué diferencia hay entre un error JSON-RPC y un resultado con `isError: true` en MCP?
El error JSON-RPC es un error de protocolo (mensaje inválido, método desconocido, versión no soportada), mientras que isError: true marca un error de ejecución: la API interna falló, un argumento no pasó la validación o una regla de negocio impide la operación. La diferencia importa porque los clientes pasan los errores de ejecución al modelo para que se corrija, y los de protocolo pueden no llegarle. Si necesitas un código propio, va fuera del rango -32768 a -32000, y el subrango -32020 a -32099 está reservado a la especificación.