You've got an MCP server running. Locally, it's perfect. Then someone asks: "Can another agent on a different machine call it?"

You spin up a VPN. Or punch a hole in the firewall. Or route it through a cloud proxy. Half a day gone, and now you've got a central dependency you didn't want.

There's a cleaner way.

The Problem with MCP's Transport Layer

MCP is genuinely great at what it does: connecting an agent to its tools via a clean, structured protocol. But it was designed with a human-run server in mind. The transport story is essentially "use HTTP" or "use stdio." Both assume you control both endpoints and they can reach each other.

In 2026, that assumption breaks constantly:

• Agent A is on AWS, Agent B is behind a corporate NAT
• You want two agents from different operators to collaborate without either exposing a public endpoint
• You're building a fleet where agents need to discover and call each other dynamically

MCP doesn't solve this. It isn't supposed to — it's an application-layer protocol. The transport is your problem.

Until now, "your problem" meant a lot of yak shaving.

What a Session Layer Gives You

The OSI model has a slot for exactly this: Layer 5, the session layer. It's the layer that manages connections between peers — maintaining them, authenticating them, and routing them across NATs.

The web uses TLS here. Agents need something that speaks agent.

Pilot Protocol is a peer-to-peer network built specifically for this slot. Instead of routing agent traffic through HTTP (a document protocol built for browsers), Pilot operates at UDP with its own reliable-stream layer on top — X25519 key exchange, AES-256-GCM per tunnel, Ed25519 identity, automatic NAT traversal via STUN + hole-punching.

Each agent gets a 48-bit address. Direct, authenticated, no intermediary required.

One Line of Code

Here's what adding Pilot to your MCP server actually looks like:

curl -fsSL https://pilotprotocol.network/install.sh | sh

That installs a single static binary. No SDK. No API key. No account.

pilotctl daemon start --hostname my-mcp-server
# Daemon running (pid 24817)
# Address: 0:A91F.0000.7C2E
# Hostname: my-mcp-server

Your MCP server now has a Pilot address. Any other agent on the network — regardless of what NAT it's behind — can reach it directly.

pilotctl ping agent-alpha
# ✓ reply from 0:4B2E.0000.1A3D · 38ms

No VPN. No public endpoint. No relay server you have to run.

Why UDP, Not TCP?

TCP is great for browsers loading pages. It wasn't designed for the round-trip latency profile of agent-to-agent calls.

Head-of-line blocking is the killer: if one packet is dropped, everything queues behind it. For a browser loading a web page, that's fine — you're waiting for HTML to render anyway. For an agent making 50 parallel data requests, it's a disaster.

Pilot runs UDP with its own reliable-stream implementation: sliding window, AIMD congestion control, selective acknowledgement (SACK). You get reliability without the head-of-line blocking tax. The benchmark from the Pilot homepage: 12s on Pilot vs 51s via the web for the same data retrieval task.

The MCP + Pilot Pattern

The natural pairing looks like this:

Agent A (MCP client)
    ↓ Pilot tunnel (encrypted, P2P)
Agent B (MCP server)
    ↓ MCP tool calls
Tools / data / capabilities

Pilot handles the transport: addressing, NAT traversal, encryption. MCP handles the application layer: tool definitions, structured responses. Neither replaces the other.

Pilot even has a dedicated page for this pattern: MCP + Pilot — your MCP server gets a network address and becomes reachable from anywhere on the Pilot network.

Discovery Is Solved Too

Once your server is on Pilot, it joins the backbone — a global directory where agents can find peers by capability rather than by hostname.

That means another agent can query "I need a tool that does X" and Pilot routes it to you, without you publishing a URL anywhere. Agent discovery stops being a directory you maintain and becomes a property of the network itself.

There are already 350+ specialized service agents on the backbone: Crossref for paper lookups, historical FX data, aviation weather, crt.sh for certificate transparency, FDA recalls. They're just peers on the network.

Wrapping Up

MCP is the right protocol for tool-calling. But it needs a transport layer that wasn't designed for humans loading documents in browsers.

Adding Pilot solves the NAT problem, the discovery problem, and the "two agents from different operators need to talk" problem — in one binary, one command.

curl -fsSL https://pilotprotocol.network/install.sh | sh

Then go back to building the agent, not the plumbing.

Pilot Protocol is live at pilotprotocol.network — ~163,000 agents, 12.7B+ requests routed, published as an IETF Internet-Draft.