MCP (Model Context Protocol) crossed 97 million monthly SDK downloads. Every major AI provider adopted it. It solved a real problem: how do agents invoke tools and retrieve context in a standardized way?

But MCP is a protocol for what agents can do. It says nothing about where they are or how they find each other.

Your MCP server lives at a URL. That URL is hardcoded in your agent's config. If it changes, your agent breaks. If you want another agent to discover your server's capabilities, you need a registry, a service mesh, or a human to copy and paste the URL.

This is the network identity problem for MCP, and it's more tractable than it looks.

What MCP Actually Does (and Doesn't Do)

MCP standardizes the tool-calling layer. An agent sends a request, the MCP server handles tool invocation, and returns structured results. The protocol defines:

• Tool schemas (what parameters each tool accepts)
• Resource definitions (what data sources are available)
• Request/response format

It does not define:

• How agents discover MCP servers without prior knowledge
• How MCP servers maintain stable identities across IP changes
• How multiple agents route to the same MCP server based on capability
• How MCP servers establish encrypted tunnels to requesting agents

These are network problems, and MCP isn't a network protocol.

The Hardcoded URL Problem

Most MCP deployments today look like this:

{
  "mcpServers": {
    "my-tool-server": {
      "url": "https://api.mycompany.com/mcp",
      "apiKey": "sk-..."
    }
  }
}

This works for a single agent with a fixed configuration. It breaks down when:

• The server moves to a new host
• You want to run multiple instances behind a load balancer
• Another agent outside your org wants to use the same tool
• You want to discover all MCP servers with a given capability type
• You're building a marketplace of tools that agents can discover dynamically

The current solution is to build a registry. A centralized service that maps tool names to URLs. But now you have a new dependency: the registry has to be available, consistent, and kept up to date. You've reintroduced the single point of failure you were trying to avoid.

What a Network Identity Gives an MCP Server

Pilot Protocol gives MCP servers a stable address at the session layer (L5), below HTTP, above UDP/TCP. Instead of a URL, the server gets an address like:

0:A91F.0000.7C2E

This address is independent of IP. The server can move, scale horizontally, or restart. The address stays the same. Other agents route to the address, not to a specific host.

In practice, this means:

Discovery without a registry: Agents can find MCP servers by capability type. A server tagged as a finance tool is discoverable by any agent on the network querying for finance-related capabilities. No hardcoded URL required.

Encrypted tunnels by default: Pilot uses X25519 key exchange and AES-256-GCM per connection. The MCP server doesn't implement TLS or manage certificates. The network layer handles it.

NAT traversal: MCP servers behind corporate firewalls or home networks are routable without port forwarding. Hole-punching handles direct P2P where possible; relay fallback handles symmetric NATs.

Stable addressing for the agent economy: When tools are addressable at the network layer, you can build agent workflows that discover and invoke tools dynamically, without human configuration at each step.

Setting It Up

Giving an existing MCP server a Pilot address takes one command:

$ curl -fsSL https://pilotprotocol.network/install.sh | sh
$ pilotctl daemon start --hostname my-mcp-server --tags mcp,finance
Daemon running (pid 24817)
Address: 0:B331.0000.4D12
Hostname: my-mcp-server
Tags: mcp, finance

The MCP server continues running as normal. Pilot runs alongside it, handling network addressing and tunnel establishment. Agents on the Pilot network can now discover my-mcp-server by querying for mcp or finance tagged nodes.

For agents that want to connect:

$ pilotctl connect my-mcp-server
Tunnel established · 0:B331.0000.4D12 · 22ms

The MCP protocol runs over the tunnel. The tool call format doesn't change. The network layer changes underneath it.

The Broader Picture: MCP + A2A + Transport

The agent protocol stack in 2026 has three layers:

• MCP (L7): Agent-to-tool communication. Tool invocation, context retrieval.
• A2A (L7): Agent-to-agent coordination. Task delegation, capability negotiation.
• Transport (L5): Addressing, discovery, encrypted tunnels, NAT traversal.

MCP and A2A both assume an underlying transport. Both currently default to HTTP. HTTP works, but it carries the full overhead of a human-facing protocol: DNS, TLS via public CAs, JSON serialization, and no native addressing for agents.

A session-layer protocol handles the transport problems once, at the network level, so MCP and A2A don't have to keep reinventing it.

Practical Impact

350+ specialized service agents on the Pilot network are already addressable this way. An agent that needs current FX rates connects to a finance-tagged peer. An agent checking SSL certificate transparency hits the security group. No configuration. No registry call. Network-layer discovery, direct connection, structured data back.

Average response time: 12 seconds for a data retrieval query routed through the Pilot network vs. 51 seconds scraping the same data over HTTP.

If you're running MCP servers in production and want to make them discoverable to the broader agent ecosystem without maintaining a central registry, this is the path.

Get started: Give your MCP server a network identity | Install Pilot | Browse service agents