Las banderas stateless_http y json_response en los servidores MCP controlan aspectos fundamentales de cómo se comporta tu servidor. Comprender cuándo y por qué usarlas es crucial, especialmente si planeas escalar tu servidor o implementarlo en producción.
Cuándo necesitas HTTP sin estado
Imagina que construyes un servidor MCP que se vuelve popular. Al principio, podrías tener solo unos pocos clientes conectándose a una única instancia de servidor:
A medida que tu servidor crece, podrías tener miles de clientes intentando conectarse. Ejecutar una única instancia de servidor no escalará para manejar todo ese tráfico:
La solución típica es el escalado horizontal: ejecutar múltiples instancias de servidor detrás de un balanceador de carga:
Pero aquí es donde las cosas se complican. Recuerda que los clientes MCP necesitan dos conexiones separadas:
- Una conexión GET SSE para recibir solicitudes del servidor al cliente
- Solicitudes POST para llamar a herramientas y recibir respuestas
Con un balanceador de carga, estas solicitudes podrían enrutarse a diferentes instancias de servidor. Si tu herramienta necesita usar Claude (mediante sampling), el servidor que maneja la solicitud POST necesitaría coordinarse con el servidor que maneja la conexión GET SSE. Esto crea un problema de coordinación complejo entre servidores.
Cómo HTTP sin estado resuelve esto
Establecer stateless_http=True elimina este problema de coordinación, pero con compensaciones significativas:
Cuando el HTTP sin estado está habilitado:
- Los clientes no obtienen IDs de sesión: el servidor no puede rastrear clientes individuales
- No hay solicitudes del servidor al cliente: la vía GET SSE deja de estar disponible
- No hay sampling: no se puede usar Claude ni otros modelos de IA
- No hay informes de progreso: no se pueden enviar actualizaciones de progreso durante operaciones largas
- No hay suscripciones: no se puede notificar a los clientes sobre actualizaciones de recursos
Sin embargo, hay un beneficio: la inicialización del cliente ya no es necesaria. Los clientes pueden hacer solicitudes directamente sin el proceso de negociación inicial.
Comprendiendo JSON Response
La bandera json_response=True es más simple: simplemente deshabilita el streaming para las respuestas de solicitudes POST. En lugar de obtener múltiples mensajes SSE a medida que una herramienta se ejecuta, obtienes solo el resultado final como JSON plano.
Con el streaming deshabilitado:
- No hay mensajes de progreso intermedios
- No hay declaraciones de registro durante la ejecución
- Solo el resultado final de la herramienta
Cuándo usar estas banderas
Usa HTTP sin estado cuando:
- Necesitas escalado horizontal con balanceadores de carga
- No necesitas comunicación del servidor al cliente
- Tus herramientas no requieren sampling de modelos de IA
- Quieres minimizar la sobrecarga de conexión
Usa JSON response cuando:
- No necesitas respuestas con streaming
- Prefieres respuestas HTTP más simples, sin streaming
- Estás integrando con sistemas que esperan JSON plano
Desarrollo vs producción
Si estás desarrollando localmente con transporte de E/S estándar pero planeas implementar con transporte HTTP, prueba con el mismo transporte que usarás en producción. Las diferencias de comportamiento entre los modos con estado y sin estado pueden ser significativas, y es mejor detectar cualquier problema durante el desarrollo en lugar de después de la implementación.
Estas banderas cambian fundamentalmente cómo opera tu servidor MCP, así que elígelas según tus requisitos específicos de escalado y funcionalidad.