Convierte tu MCP Server de STDIO a HTTP, lo que permite el acceso remoto y el deploy en la nube.
MCP admite dos modelos de transporte: STDIO (entrada/salida estándar) y HTTP (a través de la red). STDIO es local, simple y rápido — ideal para desarrollo y uso personal. HTTP es remoto, accesible a través de la red y perfecto para deploy en la nube. La pregunta clave es: ¿cuándo migrar? Cuando otras personas necesitan acceder a tu server, ya sea tu equipo, tus clientes o tu infraestructura de producción.
STDIO funciona como un pipe de Unix: el client inicia el server como proceso hijo y se comunica mediante stdin/stdout. No requiere configuración y es instantáneo, pero está limitado a la máquina local. HTTP expone el server como un servicio web: cualquier client de la red puede conectarse mediante una URL. Esto habilita escenarios como varios clients simultáneos, el deploy en containers y el acceso desde cualquier lugar del mundo. La contrapartida es que HTTP exige configurar la red, la seguridad y la infraestructura, pero la flexibilidad que ofrece es enorme.
La especificación MCP define oficialmente dos transportes: STDIO e HTTP con SSE. En la práctica, la mayoría de los MCP Servers en producción utiliza HTTP/SSE para permitir la integración con múltiples clients y el deploy en la nube. El protocolo HTTP suele agregar 1-5ms de latencia por solicitud en redes locales, pero esa diferencia es imperceptible en comparación con el tiempo de procesamiento de las herramientas. La versión más reciente del protocolo también admite HTTP transmitible, una evolución de SSE con mejor compatibilidad con la reconexión.
FastMCP abstrae toda la complejidad de configurar un servidor HTTP. Con una sola línea de código, cambias el transporte de STDIO a HTTP o SSE. El framework se encarga de las rutas, la serialización JSON-RPC, la administración de conexiones y el streaming; tú te enfocas en la lógica de tus tools.
Configurar HTTP en FastMCP es cambiar un único parámetro:
# Antes — transporte STDIO (padrão) mcp.run() # Depois — transporte HTTP mcp.run(transport="http", host="0.0.0.0", port=8000) # Ou com SSE (Server-Sent Events) mcp.run(transport="sse", host="0.0.0.0", port=8000)
El parámetro host="0.0.0.0" acepta conexiones desde cualquier IP (necesario para Docker/cloud). El port define el puerto del servidor. FastMCP usa internamente el uvicorn como servidor ASGI, garantizando rendimiento y compatibilidad con el ecosistema Python.
Usa una variable de entorno para alternar entre transportes sin modificar el código: transport = os.getenv("MCP_TRANSPORT", "stdio"). En desarrollo local, usa STDIO. En producción, define MCP_TRANSPORT=http. Así, el mismo código funciona en ambos casos sin ningún cambio en el source.
Agregar uvicorn e starlette a las dependencias en el pyproject.toml.
Cambiar mcp.run() para mcp.run(transport="http", host="0.0.0.0", port=8000).
Probar localmente accediendo a http://localhost:8000 y verificar que las tools respondan por HTTP.
SSE (Server-Sent Events) es una tecnología que permite que el server envíe actualizaciones continuas para el cliente mediante una conexión HTTP persistente. A diferencia de WebSockets (bidireccional), SSE es unidireccional: el servidor envía y el cliente recibe. Esto es ideal para operaciones largas en las que el cliente necesita seguir el progreso en tiempo real.
En el transporte SSE de MCP, el client hace una solicitud HTTP y mantiene la conexión abierta. El server envía mensajes JSON-RPC como eventos SSE mientras procesa las solicitudes. Esto permite transmitir resultados parciales, notificaciones de progreso y respuestas incrementales. MCP usa SSE como canal de respuesta mientras el client envía solicitudes mediante POST normal. Esta arquitectura es sólida y funciona bien con proxies, balanceadores de carga y CDNs, a diferencia de WebSockets, que requieren soporte especial de infraestructura.
SSE es compatible de forma nativa con todos los browsers modernos y con la mayoría de los frameworks HTTP. En comparación con WebSockets, SSE usa HTTP estándar, lo que significa compatibilidad total con proxies inversos (Nginx, Cloudflare) sin configuración especial. La reconexión automática viene integrada en la spec SSE: si la conexión se interrumpe, el browser se reconecta automáticamente usando el último Last-Event-ID. La evolución de SSE en MCP es HTTP transmitible, que combina POST para el envío y SSE para la recepción en un único endpoint.
Exponer un MCP Server vía HTTP significa exponerlo a la red y, potencialmente, a internet. La seguridad no es opcional: HTTPS obligatorio en producción, la autenticación mediante headers, la configuración de CORS y el rate limiting son lo mínimo. Un server MCP sin protección es una puerta abierta para ejecutar código arbitrario.
Lista de verificación de seguridad para MCP Server HTTP:
Authorization: Bearer <token>).¡NUNCA uses HTTP sin TLS en producción! Sin HTTPS, los tokens de autenticación y los datos de solicitudes y respuestas se transmiten en texto sin cifrar: cualquiera en la misma red puede interceptarlos. Un MCP Server expone tools que pueden ejecutar código, acceder a bases de datos y manipular archivos. Usar HTTP sin TLS en producción equivale a dejar abierta la puerta de la caja fuerte con la contraseña pegada en la pared.
allow_origins=["*"] en producciónCon el server funcionando por HTTP, el siguiente paso es ponerlo en la nube. Hay varias opciones, desde plataformas sencillas como Railway e Fly.io hasta una infraestructura completa con AWS Lambda o Docker en VPS. La elección depende de tu presupuesto, escala y necesidades de control.
Un Dockerfile básico para el deploy del MCP Server:
FROM python:3.12-slim WORKDIR /app COPY . . RUN pip install --no-cache-dir . ENV MCP_TRANSPORT=http ENV PORT=8000 EXPOSE 8000 CMD ["meu-server"]
El Dockerfile instala el paquete de Python, define variables de entorno y expone el puerto. Plataformas como Railway y Fly.io detectan automáticamente el Dockerfile y hacen el build. Para AWS Lambda, usa un adapter como mangum para convertir ASGI en un handler de Lambda.
Crear el Dockerfile en la raíz del proyecto con la configuración del server HTTP.
Configurar variables de entorno en la plataforma: tokens de API, MCP_TRANSPORT, puerto y secrets.
Haz push del código al repositorio Git conectado a la plataforma: el deploy es automático.
Comprobar los logs del deploy, probar la URL pública y configurar un dominio personalizado si es necesario.
Para proyectos personales y MVPs, Railway e Fly.io son las opciones más rápidas: deploy directo desde GitHub en minutos, con HTTPS automático y nivel gratuito. Para producción con más control, usa Docker + VPS (Hetzner, DigitalOcean) con Nginx como reverse proxy y Let's Encrypt para TLS. Siempre usa .dockerignore para excluir .env, .git e __pycache__.
Con el server deployed, es hora de verificar que todo funcione desde fuera — desde otra máquina, de otra red, como lo haría un client real. Las pruebas remotas revelan problemas que las pruebas locales ocultan: firewalls, DNS, latencia de red y configuraciones de CORS.
Probando con curl y configurando un cliente remoto:
# Testar se o server responde $ curl https://meu-server.railway.app/sse # Configurar no Claude Desktop (claude_desktop_config.json) { "mcpServers": { "meu-server": { "url": "https://meu-server.railway.app/sse" } } }
Para clientes HTTP/SSE, basta con indicar la URL del server desplegado. El cliente se conecta mediante HTTPS, mantiene abierta la conexión SSE y envía solicitudes con normalidad. Verifica la latencia con curl -w "%{time_total}" para garantizar que el tiempo de respuesta sea aceptable.
Prueba a partir de múltiples entornos: tu máquina local, una VM en otra región y el celular (mediante hotspot 4G). Cada entorno revela problemas diferentes: el DNS puede fallar en una red, CORS puede bloquear en un navegador y la latencia puede ser inaceptable desde otra región. Usa mcp-cli o npx @modelcontextprotocol/inspector para inspeccionar los mensajes JSON-RPC intercambiados.
Comprobar que la URL pública responda con curl — HTTP 200 en la verificación de estado.
Conectar un MCP client remoto y listar las tools disponibles con tools/list.
Ejecutar una tool y medir la latencia: verificar que el tiempo de respuesta sea menor que 5 segundos para operaciones simples.
Siguiente Módulo: 5.4 — MCP con TypeScript