El transporte HTTP streamable permite que los clientes MCP se conecten a servidores alojados de forma remota a través de conexiones HTTP. A diferencia del transporte estándar de E/S, que requiere que tanto el cliente como el servidor estén en la misma máquina, este transporte abre posibilidades para servidores MCP públicos a los que cualquiera puede acceder.
Sin embargo, hay una advertencia importante: algunas configuraciones pueden limitar significativamente la funcionalidad de tu servidor MCP. Si tu aplicación funciona perfectamente con el transporte estándar de E/S de forma local pero falla al implementarse con el transporte HTTP, esto probablemente sea la causa.
Configuraciones que importan
Dos configuraciones clave controlan cómo se comporta el transporte HTTP streamable:
stateless_http- Controla la gestión del estado de la conexiónjson_response- Controla el manejo del formato de respuesta
Por defecto, ambas configuraciones son false, pero ciertos escenarios de implementación pueden obligarte a establecerlas en true. Cuando están habilitadas, estas configuraciones pueden romper funcionalidades principales como las notificaciones de progreso, el registro (logging) y las solicitudes iniciadas por el servidor.
El desafío de la comunicación HTTP
Para entender por qué existen estas limitaciones, necesitamos revisar cómo funciona la comunicación HTTP. En el HTTP estándar:
- Los clientes pueden iniciar solicitudes a los servidores fácilmente (el servidor tiene una URL conocida)
- Los servidores pueden responder a estas solicitudes fácilmente
- Los servidores no pueden iniciar solicitudes a los clientes fácilmente (los clientes no tienen URLs conocidas)
- Los patrones de respuesta del cliente de vuelta al servidor se vuelven problemáticos
Tipos de mensajes MCP afectados
Esta limitación de HTTP impacta patrones de comunicación específicos de MCP. Los siguientes tipos de mensajes se vuelven difíciles de implementar con HTTP simple:
- Solicitudes iniciadas por el servidor: Solicitudes de Create Message, solicitudes de List Roots
- Notificaciones: Notificaciones de progreso, notificaciones de registro (logging), notificaciones de inicialización, notificaciones de cancelación
Estas son exactamente las funcionalidades que se rompen cuando habilitas las configuraciones HTTP restrictivas. Las barras de progreso desaparecen, el registro deja de funcionar y las solicitudes de muestreo iniciadas por el servidor fallan.
La solución del HTTP streamable
El transporte HTTP streamable sí proporciona una solución ingeniosa para sortear las limitaciones de HTTP, pero viene con compensaciones. Cuando te ves obligado a usar stateless_http=True o json_response=True, básicamente le estás diciendo al transporte que opere dentro de las restricciones de HTTP en lugar de sortearlas.
Comprender estas limitaciones te ayuda a tomar decisiones informadas sobre:
- Qué transporte usar para diferentes escenarios de implementación
- Cómo diseñar tu servidor MCP para manejar con elegancia las restricciones de HTTP
- Cuándo aceptar una funcionalidad reducida a cambio de los beneficios del alojamiento remoto
La clave está en saber que estas restricciones existen y planificar la arquitectura de tu servidor MCP en consecuencia. Si tu aplicación depende en gran medida de solicitudes iniciadas por el servidor o de notificaciones en tiempo real, es posible que debas reconsiderar tu elección de transporte o implementar patrones de comunicación alternativos.