MCP sin Bridges: Cómo Conectamos Workers Remotos vía HTTP Directo
Esta es la historia de un problema que nos persiguió durante meses y cómo lo resolvimos cambiando una línea de configuración. De 7 bridges Python a cero. De 45ms a 8ms. De caídas semanales a cero timeouts.
Gonzalo Monzón
7 julio, 2026 · Serie: Arquitectura — Cómo se Comunican los Agentes (1/3)
TL;DR
Nuestros agentes se conectaban por MCP con transporte stdio. En Windows, cada servidor stdio se caía sin avisar. Teníamos 7 bridges Python como traductores, 7 procesos, 7 puntos de fallo. La solución fue migrar a transport: url — HTTP directo entre Hermes y los Workers. Un cambio de una línea por agente. Resultado: latencia de 45ms a 8ms, cero caídas, y la puerta abierta a service bindings de Cloudflare. Primer artículo de la serie Arquitectura.
Bridges stdio en Windows
Nuestros agentes se conectaban por MCP usando el transporte stdio estándar. En Linux funciona bien. En producción con Docker también. Pero en Windows — el entorno de desarrollo — cada servidor stdio era un problema:
- ⚙️ Se iniciaba como un proceso hijo de Hermes
- 💬 Hablaba por stdin/stdout con JSON-RPC
- 💥 Se caía sin avisar al primer timeout
- 🧟 Dejaba procesos zombies imposibles de matar — solo
taskkill /Flos eliminaba - 🔗 Requería un bridge Python para convertir la REST API del worker a stdio
Teníamos 7 bridges. 7 procesos Python. 7 puntos de fallo.
| Métrica | Antes (stdio + bridges) | Después (HTTP directo) | Mejora |
|---|---|---|---|
| Latencia por llamada | ~45 ms | ~8 ms * | 82% |
| Caídas de bridge / semana | 3-4 | 0 | 100% |
| Procesos en background | 7 bridges Python | 0 | 100% |
| Tiempo de diagnóstico por caída | ~15 min | instantáneo | ∞ |
* Con service bindings. Sin ellos, ~25 ms por llamada HTTP directa.
La migración paso a paso
El cambio no fue instantáneo. Hubo que migrar cada agente de stdio a HTTP uno por uno, con un patrón repetible de 5 pasos:
Añadir handler MCP
Cada Worker recibe un endpoint /mcp con POST JSON-RPC + handshake PROBE/ACK en HTTP
Configurar transport: url
Cambiar de transport: stdio a transport: url
Probar handshake
Verificar tools/list devuelve herramientas correctas
Desplegar Worker
wrangler deploy — rolling, sin downtime
Retirar el bridge
Eliminar el proceso Python. Ya no hace falta.
Repetido para cada agente. 5 pasos, ~30 minutos por agente, cero downtime.
El cambio: una línea de configuración
# Antes (stdio — Windows dice NO)
mcpServers:
tom:
transport: stdio
command: python
args: [bridge_tom.py]
# Después (HTTP directo — sin bridges)
mcpServers:
tom:
transport: url
url: "https://tom.worker.dev/mcp"
Un cambio de stdio a url. Y todos los bridges desaparecieron.
Service bindings: el turbo
Cloudflare Workers tiene una feature llamada service bindings: un Worker puede llamar a otro Worker directamente, sin pasar por HTTP público.
Zalo (service binding) → Tom: "clasifica este texto"
Tom (service binding) → Lisa: "analiza este objetivo"
0 ms
Latencia de red
0
DNS lookup
0
TLS handshake
0
Cold starts
Es como RPC entre microservicios en la misma máquina, pero distribuido globalmente. Y lo mejor: si no hay binding disponible, el sistema fallbackea automáticamente a HTTP público — la misma arquitectura MCP funciona en ambos casos.
La deuda técnica: vendor lock-in
Service bindings son específicos de Cloudflare. Si mañana quisiéramos migrar a otra plataforma (Fastly, Deno Deploy, AWS), perderíamos esa comunicación interna directa. Es un trade-off asumido: la ganancia en latencia y simplicidad compensa el riesgo. En caso de migración, volveríamos a HTTP público — más lento (~15-20 ms extra) pero funcional. La arquitectura MCP sobre HTTP es agnóstica al provider.
El cambio que no parecía importante
Mirando atrás, cambiar de stdio a HTTP parece trivial. Pero desbloqueó cuatro cosas fundamentales:
🔒 Estabilidad
Cero caídas de bridges desde entonces. Fin de los timeouts aleatorios en Windows.
⚡ Rendimiento
De 45ms a 8ms por llamada. Sin la sobrecarga de serialización del bridge.
📈 Escalabilidad
Añadir un agente es solo desplegar un Worker. Sin bridges, sin configuración extra.
🔧 Mantenimiento
Un wrangler deploy y ya está. Sin procesos que monitorizar.
Serie: Arquitectura — Cómo se Comunican los Agentes (1/3)
← Anterior
Hermes Agent — El RuntimeSiguiente →
Service Bindings — La Red PrivadaTodos los artículos de la serie:
La comunicación es la base
Los bindings son la red privada que conecta a los agentes. El siguiente artículo profundiza en cómo Zalo, Lisa y Tom se hablan sin latencia.
Serie Arquitectura — 3 artículos. Cadences Lab © 2026.