Streamable HTTP, autorización y publicación remota de un servidor MCP
Aprende el salto de servidor local a servidor remoto en MCP: cuándo usar Streamable HTTP, qué cambia con la autorización y cómo pensar la publicación remota sin mezclar demo, despliegue y distribución.
Hasta ahora el curso se ha apoyado en `stdio` y entorno local porque era la forma más clara de aprender el protocolo. Pero una integración MCP madura muchas veces necesita un servidor remoto accesible por varios clientes.
Ahí entra `Streamable HTTP`, que hoy es la opción recomendada para servidores remotos en la documentación oficial y en el SDK de TypeScript.
El cambio importante no es solo técnico. En remoto aparecen sesiones, publicación, visibilidad pública, autorización formal y decisiones de arquitectura que no existen igual en local.
También conviene separar tres ideas que suelen mezclarse: desplegar un servidor, autorizar el acceso y publicarlo para descubrimiento. Son piezas relacionadas, pero no equivalentes.
- Para remoto, el SDK y la documentación oficial ya lo tratan como la vía moderna.
- En el SDK oficial de TypeScript, `Streamable HTTP` aparece como el transporte recomendado para servidores remotos. Soporta `POST`, notificaciones del servidor al cliente, modo JSON cuando conviene y gestión de sesiones.
- Eso lo convierte en una mejor base para producción que el viejo patrón HTTP+SSE usado por compatibilidad. Si vas a pensar una integración nueva, conviene partir de la opción moderna y no de la heredada.
- La decisión real es esta: si el servidor va a vivir fuera de la máquina del usuario y atender a varios clientes, diseña ya con mentalidad de transporte remoto.
- La autorización remota no es un extra decorativo: forma parte del contrato operativo.
Por qué Streamable HTTP
Para remoto, el SDK y la documentación oficial ya lo tratan como la vía moderna.
En el SDK oficial de TypeScript, `Streamable HTTP` aparece como el transporte recomendado para servidores remotos. Soporta `POST`, notificaciones del servidor al cliente, modo JSON cuando conviene y gestión de sesiones.
Eso lo convierte en una mejor base para producción que el viejo patrón HTTP+SSE usado por compatibilidad. Si vas a pensar una integración nueva, conviene partir de la opción moderna y no de la heredada.
La decisión real es esta: si el servidor va a vivir fuera de la máquina del usuario y atender a varios clientes, diseña ya con mentalidad de transporte remoto.
Qué cambia con autorización
La autorización remota no es un extra decorativo: forma parte del contrato operativo.
La especificación actual de autorización para MCP se apoya en OAuth 2.1 para escenarios HTTP. Eso significa descubrimiento del servidor de autorización, metadatos y flujos que un cliente debe respetar.
Si la integración tiene usuario humano, el flujo normal de autorización encaja mejor. Si no hay usuario presente, la documentación oficial añade la extensión de OAuth Client Credentials para escenarios máquina a máquina.
Ese punto evita un error muy común: reutilizar el mismo enfoque de permisos para un editor local y para un backend automatizado que invoca un servidor MCP en segundo plano.
Despliegue vs publicación
Que un servidor exista en remoto no significa que ya esté preparado para descubrimiento público.
Desplegar significa que tu servidor responde y funciona en una URL real. Publicar significa que su metadata queda preparada para que otros clientes lo descubran, por ejemplo a través del Registry oficial.
El Registry trabaja con `server.json` y metadata estandarizada. En el caso de servidores remotos, usa la propiedad `remotes` para declarar la URL y el tipo de transporte.
Eso obliga a pensar también en estabilidad, documentación, versión y reputación del servidor. Un endpoint remoto no es automáticamente un buen candidato para publicación.
Caso guiado
Imagina que tu equipo ha construido un servidor MCP para consultar métricas de negocio. En fase local, lo validas por `stdio`. En fase remota, lo despliegas con `Streamable HTTP`, proteges el acceso con autorización y solo después decides si merece publicarse para descubrimiento por clientes externos o internos.
Ese orden importa porque evita mezclar madurez del producto con simple disponibilidad técnica. Primero funciona. Luego se protege. Después, si tiene sentido, se publica.
Práctica
Define una ficha breve para tu futuro servidor remoto: transporte, tipo de autorización y criterio para decidir si lo publicarías o no. La evidencia observable de logro es que sabes separar esas tres decisiones sin mezclarlas.
Una respuesta correcta debe dejar claro qué resuelve `Streamable HTTP`, qué resuelve la autorización y qué resuelve el Registry.
