Cómo los servidores MCP manejan las solicitudes
El Protocolo de Contexto del Modelo (MCP) ofrece a Claude una forma estándar de acceder a sistemas externos a su propia ventana de contexto.
Un servidor que habla MCP puede envolver una base de datos, un sistema de tickets, un sistema de archivos o una API interna.
Sin embargo, antes de que todo eso sea útil, un cliente y un servidor deben acordar qué puede hacer el servidor y cómo hablar con él.
Ese acuerdo, y todo lo que le sigue, es el ciclo de vida de la solicitud que esta página describe.
Comprender el ciclo de vida es importante porque la mayoría de los errores en un nuevo servidor MCP no son errores de herramientas en absoluto.
Son errores del ciclo de vida: una herramienta registrada demasiado tarde, una capacidad nunca declarada, una respuesta mal formada para el paso en el que el cliente cree que se encuentra.
Resumen
- Idea Central: Cada interacción MCP atraviesa las mismas cuatro etapas: conectar, negociar capacidades, intercambiar solicitudes y, finalmente, desconectar.
- Por Qué Importa: Un servidor que omite o reordena una etapa parecerá roto para el cliente, incluso si cada manejador de herramientas individual es correcto.
- Conceptos Clave: conexión, negociación de capacidades, herramientas, recursos, prompts, ciclo de solicitud/respuesta.
- Cuándo Usar: Recurre a este modelo mental cada vez que depures "el cliente no ve mi herramienta", diseñes un nuevo manejador o decidas qué pertenece a una herramienta frente a un recurso.
- Limitaciones / Compensaciones: El ciclo de vida describe la estructura, no el rendimiento. Un ciclo de solicitud/respuesta bien formado aún puede ser lento, inseguro o incorrecto internamente.
- Temas Relacionados: configuración de un servidor mínimo, transporte stdio frente a HTTP/SSE, autenticación de servidores remotos.
Fundamentos
Un servidor MCP es un programa que expone un conjunto fijo de capacidades a un cliente a través de un protocolo definido.
Esas capacidades se dividen en tres categorías: herramientas que el cliente puede invocar, recursos que el cliente puede leer y prompts que el cliente puede obtener como plantillas reutilizables.
El cliente suele ser Claude mismo, actuando a través de una aplicación como Claude Code, Claude Desktop o una integración personalizada construida sobre el SDK de Agente.
Piensa en el servidor como un recepcionista en un edificio con varios departamentos.
El recepcionista no hace el trabajo de cada departamento, solo sabe qué sala maneja cada solicitud y la pasa correctamente.
Un servidor MCP se comporta de la misma manera: no necesita saber por qué Claude quiere llamar a una herramienta, solo cómo dirigir la llamada al manejador correcto y devolver un resultado bien formado.
El ciclo de vida en sí tiene cuatro etapas, en un orden fijo:
1. Conectar el cliente abre un transporte (tubería stdio, o sesión HTTP/SSE)
2. Negociar el cliente y el servidor intercambian capacidades y versiones admitidas
3. Intercambiar el cliente lista/llama herramientas, lee recursos, obtiene prompts
4. Desconectar el transporte se cierra, el estado de la sesión se desmantelaNo se puede omitir ninguna etapa, y la etapa 3 no puede comenzar hasta que la etapa 2 finalice con éxito.
Mecánicas e Interacciones
La conexión depende del transporte pero es agnóstica al protocolo en su intención.
A través de stdio, el cliente inicia el servidor como un subproceso y se comunica con él a través de la entrada y salida estándar.
A través de HTTP/SSE, el cliente abre una conexión de red a un proceso de servidor en ejecución, a menudo autenticándose primero.
En cualquier caso, el objetivo de esta etapa es el mismo: establecer un canal sobre el cual los dos lados puedan intercambiar mensajes estructurados.
La negociación de capacidades ocurre inmediatamente después de la conexión, antes de que el cliente confíe en el servidor para cualquier otra cosa.
El cliente envía una solicitud de inicialización que describe lo que admite; el servidor responde con su propia versión de protocolo admitida y un manifiesto de lo que ofrece: qué herramientas existen, qué recursos son legibles, qué prompts están disponibles.
Este es el punto donde un cliente se entera de que "este servidor tiene una herramienta search_tickets" o "este servidor expone un recurso config://settings".
Una herramienta que el servidor nunca registró en este intercambio, efectivamente no existe para el cliente, sin importar cuán correcto sea su código de manejador subyacente.
Esta es la fuente más común de errores de tipo "mi herramienta no aparece": la función manejadora fue escrita, pero nunca se conectó al registro que el servidor anuncia durante la negociación.
El intercambio de solicitudes es donde ocurre el trabajo real, y es en sí mismo un ciclo repetitivo de solicitud/respuesta.
El cliente envía una solicitud, nombrando una herramienta y sus argumentos, o nombrando un URI de recurso, o nombrando una plantilla de prompt.
Cliente -> Servidor: call_tool("get_weather", {"city": "Denver"})
Servidor: dirige a la función manejadora registrada para get_weather
Servidor -> Cliente: { "temperature": 61, "conditions": "clear" }El servidor dirige esa solicitud al manejador coincidente, lo ejecuta y devuelve una respuesta estructurada.
Cada llamada es independiente a nivel de protocolo; el servidor no asume ningún orden entre una llamada a herramienta y la siguiente, a menos que la propia lógica del servidor imponga uno.
Los recursos se comportan de manera similar pero están orientados a la lectura: el cliente solicita un URI, el servidor devuelve contenido; normalmente no se involucran argumentos más allá del propio URI.
Los prompts son plantillas que el servidor devuelve para que el cliente las complete y use, más cercanas a un fragmento reutilizable que a una acción en vivo.
La desconexión cierra el transporte y descarta cualquier estado por sesión que el servidor estuviera manteniendo.
Un servidor bien construido trata cada sesión como desechable: si necesita recordar algo más allá de una única conexión, eso pertenece a un almacén de datos real, no a la memoria vinculada al transporte.
Consideraciones Avanzadas y Aplicaciones
A escala, el ciclo de vida interactúa con dos cosas que no aparecen en un ejemplo simple: concurrencia y estado.
Un único proceso de servidor, especialmente uno desplegado sobre HTTP/SSE, puede mantener muchas sesiones de cliente abiertas a la vez, cada una habiendo pasado por su propia negociación de forma independiente.
El servidor debe mantener separadas las capacidades negociadas de cada sesión y cualquier estado con ámbito de sesión; mezclarlos entre clientes es un error de corrección, no solo de rendimiento.
El estado dentro de un manejador de herramientas también merece ser considerado deliberadamente.
Una herramienta que lee y escribe en un sistema externo, una fila de base de datos, un archivo, una API, debe tratar cada invocación como una solicitud nueva, incluso si el recurso subyacente tiene estado, porque el protocolo en sí no ofrece garantía sobre cuántas veces se llamará a una herramienta o en qué orden en relación con otras herramientas.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Manejadores sin estado, el estado vive externamente | Seguro bajo clientes concurrentes, fácil de razonar | Requiere un almacén de datos real o una API detrás de la herramienta | Servidores de producción con más de un cliente |
| Estado de sesión en memoria | Simple, rápido, sin dependencia externa | Perdido al reiniciar, falla bajo múltiples instancias de servidor | Servidores de desarrollo locales, de un solo usuario, stdio |
La seguridad también se deriva directamente del ciclo de vida.
Dado que la negociación ocurre antes de que se confíe en cualquier llamada a herramienta, un servidor HTTP/SSE que omite la autenticación en la etapa de conexión no tiene un punto posterior en el ciclo de vida donde pueda agregar de manera segura esa verificación sin romper las suposiciones del protocolo.
Es por eso que la autenticación para servidores remotos se maneja en el momento de la conexión, no dentro de manejadores de herramientas individuales.
Conceptos Erróneos Comunes
- "Una herramienta existe una vez que escribo la función manejadora." - El cliente solo se entera de una herramienta durante la negociación de capacidades, por lo que la función manejadora también debe registrarse en la lista de herramientas del servidor, no solo implementarse.
- "Las herramientas, los recursos y los prompts son intercambiables." - Son tipos de capacidades distintos con diferentes semánticas: las herramientas realizan acciones y pueden tener efectos secundarios, los recursos son contenido de solo lectura, los prompts son plantillas reutilizables.
- "El servidor recuerda lo que sucedió en la última llamada a herramienta." - A menos que el servidor persista explícitamente el estado fuera de la conexión, cada solicitud debe tratarse como independiente; depender de la memoria implícita entre llamadas es una fuente común de errores sutiles.
- "La negociación es un formalismo que se puede omitir en un servidor mínimo." - Incluso un servidor mínimo construido con un SDK realiza la negociación automáticamente; omitirla o configurarla incorrectamente es lo que causa fallos de tipo "el cliente no ve ninguna herramienta".
- "stdio y HTTP/SSE tienen ciclos de vida fundamentalmente diferentes." - El ciclo de vida de cuatro etapas es el mismo para ambos; solo la etapa de conexión difiere en sus mecánicas.
Preguntas Frecuentes
¿Cuáles son las cuatro etapas del ciclo de vida de las solicitudes MCP?
- Conectar: el cliente y el servidor establecen un transporte.
- Negociar: ambos lados intercambian capacidades admitidas y la versión del protocolo.
- Intercambiar: el cliente llama a herramientas, lee recursos u obtiene prompts, y el servidor responde.
- Desconectar: el transporte se cierra y el estado de la sesión se desmantela.
¿Por qué un cliente no puede llamar a una herramienta antes de que finalice la negociación?
El cliente aún no sabe lo que ofrece el servidor. La negociación es donde se envía el manifiesto de herramientas, recursos y prompts del servidor, por lo que cualquier llamada intentada anteriormente no tiene nada contra lo que dirigirse en el lado del cliente.
Mi manejador de herramientas funciona cuando lo pruebo directamente, pero el cliente dice que no existe. ¿Por qué?
- Es probable que la función manejadora se haya escrito pero nunca se haya registrado en la lista de herramientas del servidor.
- El registro es lo que hace que una herramienta aparezca en el manifiesto de capacidades enviado durante la negociación.
- Escribir la función sola no es suficiente; debe estar conectada a las capacidades declaradas del servidor.
¿Cuál es la diferencia entre una herramienta y un recurso?
Una herramienta es algo que el cliente invoca para realizar una acción, que puede tener efectos secundarios y toma argumentos. Un recurso es contenido de solo lectura que el cliente recupera por URI, más parecido a leer un archivo que a llamar a una función.
¿Necesita el servidor recordar llamadas a herramientas anteriores en una sesión?
No por defecto. Cada solicitud en la etapa de intercambio generalmente se trata como independiente. Si un servidor necesita memoria entre llamadas, eso debe construirse deliberadamente, generalmente respaldado por un almacén externo, no asumido por el protocolo en sí.
¿El ciclo de vida es diferente para servidores stdio frente a HTTP/SSE?
No. Las cuatro etapas son las mismas para ambos. Lo que difiere es cómo funciona mecánicamente la etapa de conexión, una tubería de subproceso para stdio frente a una sesión de red para HTTP/SSE.
¿Qué sucede si un cliente y un servidor admiten diferentes versiones de protocolo?
La negociación es exactamente donde surge esta discrepancia. El cliente y el servidor intercambian información de versión en esta etapa, y los SDK generalmente manejan la retroalimentación a una versión mutuamente compatible o fallan claramente si no existe ninguna.
¿Puede un solo servidor manejar múltiples clientes a la vez?
Sí, particularmente sobre HTTP/SSE, donde se pueden abrir múltiples sesiones simultáneamente. Cada sesión pasa por sus propias etapas de conexión y negociación de forma independiente, y el servidor debe mantener sus estados separados.
¿Dónde encaja la autenticación en este ciclo de vida?
Para servidores remotos, la autenticación ocurre en la etapa de conexión o antes, ya que todo lo posterior a la negociación asume que la conexión ya es de confianza. Verificar credenciales dentro de manejadores de herramientas individuales está demasiado tarde en el ciclo de vida para ser un límite de seguridad sólido.
¿Cuál es un ejemplo práctico de un ciclo de solicitud completo?
Un cliente llama a una herramienta get_weather con un argumento de ciudad. El servidor dirige esa llamada a su manejador get_weather registrado, el manejador se ejecuta y devuelve datos estructurados, y el servidor envía esos datos como respuesta, cerrando un intercambio dentro de la sesión más grande.
¿Por qué importa este ciclo de vida si solo estoy usando un SDK que lo maneja por mí?
El SDK maneja la mecánica, pero comprender las etapas te ayuda a diagnosticar por qué una herramienta no aparece, por qué una sesión se comporta de manera inesperada bajo clientes concurrentes o por qué una verificación de autenticación necesita estar donde está.
¿Los prompts y recursos también pasan por la negociación de capacidades?
Sí. La negociación cubre los tres tipos de capacidades juntos: herramientas, recursos y prompts. Un recurso o prompt que el servidor no ha declarado es tan invisible para el cliente como una herramienta no registrada.
Relacionados
- Fundamentos del Servidor MCP - configura un servidor mínimo y ve el ciclo de vida en una forma ejecutable.
- Comparación de Despliegue de MCP stdio vs HTTP/SSE - cómo la etapa de conexión difiere según el transporte.
- Autenticación de Servidores MCP Remotos - dónde encaja la autenticación en relación con las etapas de conexión y negociación.
- Construcción de un Servidor MCP con el SDK de Python - ve el registro de herramientas, recursos y prompts en código.
Versiones de Stack: Escrito contra la línea de modelos de Claude actual a partir de ~junio de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado) y Claude Haiku 4.5 - y los SDK actuales del Protocolo de Contexto del Modelo de Python/TypeScript. Los nombres de los modelos, las versiones de los SDK y la especificación MCP cambian rápidamente; verifica los detalles actuales en platform.claude.com/docs y modelcontextprotocol.io antes de confiar en ellos.