MCP Direct HTTP · 16 min read

MCP Without Bridges: Connecting Remote Workers via Direct HTTP

This is the story of a problem that haunted us for months and how we solved it by changing one line of configuration. From 7 Python bridges to zero. From 45ms to 8ms. From weekly crashes to zero timeouts.

Gonzalo Monzón

July 7, 2026 · Series: Architecture — How Agents Communicate (1/3)

TL;DR

Our agents used to connect via MCP with stdio transport. On Windows, each stdio server would crash without warning. We had 7 Python bridges acting as translators, 7 processes, 7 points of failure. The solution was migrating to transport: url — direct HTTP between Hermes and the Workers. A one-line change per agent. Result: latency from 45ms to 8ms, zero crashes, and the door open to Cloudflare service bindings. First article of the Architecture series.

The Problem

stdio Bridges on Windows

Our agents connected via MCP using the standard stdio transport. On Linux it works fine. In production with Docker too. But on Windows — the development environment — each stdio server was a problem:

⚙️ It started as a child process of Hermes
💬 It communicated via stdin/stdout with JSON-RPC
💥 It crashed without warning at the first timeout
🧟 It left zombie processes that were impossible to kill — only taskkill /F could eliminate them
🔗 It required a Python bridge to convert the worker's REST API to stdio

We had 7 bridges. 7 Python processes. 7 points of failure.

Metric	Before (stdio + bridges)	After (Direct HTTP)	Improvement
Latency per call	~45 ms	~8 ms *	82%
Bridge crashes / week	3-4	0	100%
Background processes	7 Python bridges	0	100%
Time to diagnose a crash	~15 min	instant	∞

* With service bindings. Without them, ~25 ms per direct HTTP call.

The Solution

Step-by-Step Migration

The change wasn't instant. We had to migrate each agent from stdio to HTTP one by one, following a repeatable 5-step pattern:

Add MCP handler

Each Worker gets an /mcp endpoint with POST JSON-RPC + PROBE/ACK handshake over HTTP

Configure transport: url

Change from transport: stdio to transport: url

Test handshake

Verify tools/list returns the correct tools

Deploy Worker

wrangler deploy — rolling, zero downtime

Retire the bridge

Delete the Python process. No longer needed.

Repeated for each agent. 5 steps, ~30 minutes per agent, zero downtime.

The Change: One Line of Configuration

# Before (stdio — Windows says NO)
mcpServers:
  tom:
    transport: stdio
    command: python
    args: [bridge_tom.py]

# After (Direct HTTP — no bridges)
mcpServers:
  tom:
    transport: url
    url: "https://tom.worker.dev/mcp"

One change from stdio to url. And all the bridges disappeared.

Service Bindings: The Turbo

Cloudflare Workers has a feature called service bindings: a Worker can call another Worker directly, without going through public HTTP.

Zalo (service binding) → Tom: "classify this text"
Tom (service binding) → Lisa: "analyze this objective"

0 ms

Network latency

DNS lookup

TLS handshake

Cold starts

It's like RPC between microservices on the same machine, but distributed globally. And the best part: if there's no binding available, the system automatically falls back to public HTTP — the same MCP architecture works in both cases.

Trade-off

The Technical Debt: Vendor Lock-In

Service bindings are specific to Cloudflare. If tomorrow we wanted to migrate to another platform (Fastly, Deno Deploy, AWS), we'd lose that direct internal communication. It's an accepted trade-off: the gain in latency and simplicity outweighs the risk. In case of migration, we'd fall back to public HTTP — slower (~15-20 ms extra) but functional. The MCP-over-HTTP architecture is provider-agnostic.

Conclusion

The Change That Didn't Seem Important

Looking back, switching from stdio to HTTP seems trivial. But it unlocked four fundamental things:

🔒 Stability

Zero bridge crashes since then. No more random timeouts on Windows.

⚡ Performance

From 45ms to 8ms per call. No more bridge serialization overhead.

📈 Scalability

Adding an agent is just deploying a Worker. No bridges, no extra configuration.

🔧 Maintenance

One wrangler deploy and done. No processes to monitor.

Series: Architecture — How Agents Communicate (1/3)

← Previous

Hermes Agent — The Runtime

Service Bindings — The Private Network

All articles in this series:

1. MCP Without Bridges (this) 2. Service Bindings 3. Agent Dashboards

Communication is the Foundation

Bindings are the private network that connects the agents. The next article dives into how Zalo, Lisa, and Tom talk to each other with zero latency.

Next: Service Bindings → Back to Blog