MCP's Missing Layer: How Should Tool Servers Talk to Each Other?MCP 的缺失层：工具服务器之间应该如何通信？

The Model Context Protocol has been out for over a year. Thousands of MCP servers exist. And yet there's a gap so fundamental that an entire sub-ecosystem has emerged to work around it: MCP servers cannot talk to each other.

This isn't an oversight. It's a deliberate architectural choice — and understanding why reveals something deeper about where the agent ecosystem is heading.

The Architecture, As Specified

MCP defines a strict client-server relationship. A Host (the LLM application) creates one Client per Server. Communication flows vertically:

Host (LLM)
  ├── Client 1 ↔ Server A
  ├── Client 2 ↔ Server B
  └── Client 3 ↔ Server C

Server A cannot call Server B. There is no horizontal channel. If Server A produces data that Server B needs, it must flow: A → Client 1 → Host (LLM) → Client 2 → B. The LLM is the sole mediator.

This means every cross-server data transfer:

• Costs a full LLM inference round-trip (seconds, not milliseconds)
• Consumes context window tokens
• Is non-deterministic (the LLM decides whether to relay, not guaranteed)

For simple tool composition — search something, then store the result — this works fine. The LLM reads the search output and naturally feeds it into the storage call.

For anything more complex, it breaks down.

Five Patterns the Ecosystem Invented

The responses to this gap cluster into five patterns:

1. Let the LLM Mediate (Accept the Cost)

Projects: mcp-agent (LastMile AI), most OpenClaw skills

The simplest approach: don't fight the architecture. The LLM reads output from Server A, decides to call Server B, passes the data along. mcp-agent adds workflow patterns on top (orchestrator, map-reduce, evaluator-optimizer) and optional Temporal integration for durable execution.

When this works: Tool composition where the LLM's judgment is actually needed between steps. "Search for X, then analyze the results and decide what to store" — you want the LLM in the loop.

When this breaks: Credential passing (secrets in LLM context = security disaster), long-running pipelines (hours of execution across hundreds of turns), high-frequency state sharing (sub-second coordination). CA-MCP (Jayanti & Han, 2026) measured the overhead: 5 LLM calls per workflow in standard MCP vs. 2 in their optimized version — a 60% reduction, with execution time dropping from 42s to 13.5s.

2. Put Everything in One Server (Sidestep the Problem)

Projects: Agent-MCP, Network-AI

If servers can't talk to each other, don't have multiple servers. Agent-MCP is a single MCP server that internally manages multiple LLM "agents" sharing a knowledge graph. Network-AI implements a mutex-protected shared blackboard with propose-validate-commit semantics, all within one server process.

When this works: Self-contained domains where all tools naturally belong together.

When this breaks: When you want modularity. A monolithic MCP server that does vault + memory + crypto + audit is an engineering nightmare. You lose independent deployment, independent failure, independent development. You've reinvented the monolith.

3. Add an External Coordination Layer

Projects: Solace Agent Mesh, SwarmClaw, Microsoft Agent Framework

Introduce something outside MCP to handle coordination: a message broker (Solace), a task board (SwarmClaw), or a workflow engine with typed message passing (Microsoft Agent Framework's graph-based workflows with BSP supersteps).

Microsoft's approach is the most sophisticated: agents can both consume and expose MCP servers, communicate through workflow edges with shared scoped state, and fall back to A2A for cross-runtime communication. State updates are queued and applied at superstep boundaries for consistency.

When this works: Enterprise deployments with existing infrastructure (Kubernetes, message brokers, distributed state stores).

When this breaks: When you want zero external dependencies. Solace needs a broker. Microsoft Agent Framework targets Azure. Temporal (used by mcp-agent) is a separate distributed system to operate.

4. Define a New Protocol Alongside MCP

Projects: Google A2A (v1.0, March 2026), ANP (W3C Community Group)

The industry's formal answer: MCP handles vertical (agent→tool), a separate protocol handles horizontal (agent↔agent).

A2A introduces three primitives that MCP lacks: Agent Cards (capability discovery at /.well-known/agent.json), Tasks (stateful work units with a lifecycle: submitted→working→input-required→completed), and Messages (multi-part communication within tasks). The input-required state is critical — it enables multi-turn negotiation between agents, something impossible in MCP's request-response model.

ACP (IBM) merged into A2A in September 2025. ANP sits below both, handling decentralized identity (W3C DIDs) and protocol negotiation for the open internet — A2A for enterprises, ANP for the agent web at large.

When this works: Cross-organization, cross-runtime agent collaboration.

When this breaks: When your servers are co-located in one machine and you need sub-millisecond latency. A2A is HTTP/JSON-RPC — perfect for distributed systems, overkill for processes sharing a filesystem.

5. Single-Process Bridge (Direct IPC)

Projects: claude-ext (production), claude-ipc-mcp

A main process runs a Unix socket server. MCP server child processes connect to it. Any server can call any handler registered by any extension — vault, memory, session management, other extensions' capabilities — through a single socket with line-delimited JSON. Sub-millisecond latency, zero external dependencies, deterministic routing.

MCP Server A ──bridge.sock──► Main Process ◄──bridge.sock── MCP Server B
                                 │
                          Handler Chain
                    (vault, memory, crypto, team, ...)

The handler chain pattern means extensions register their methods independently. Server A calls vault_get without knowing or importing the vault extension — it just sends a method name string. The main process dispatches to the first handler that responds.

Additionally, dispatch() lets the main process itself call the same handler chain without going through the socket — enabling in-process extension-to-extension coordination with the same decoupled interface.

When this works: Single-machine deployments where all MCP servers are co-located, especially when you need infrastructure-level resource sharing (cryptographic keys, database connections, session management) that must not transit through the LLM's context.

When this breaks: Distributed deployments. Single point of failure. Non-standard (no one else implements this protocol).

The Security Dimension No One Talks About

The cross-server communication gap has a security shadow that most discussions ignore.

Academic research (Zhao et al., 2025; Sun et al., 2025; Gaire et al., 2025) has documented 12 attack categories against MCP, with deeply concerning findings:

• 100% success rate on cross-server memory exfiltration: a malicious MCP server can embed parasitic parameters that force the LLM to leak its entire session context — including data from other servers (Sun et al., 2025)
• Tool shadowing: a compromised server's output can manipulate how the LLM invokes tools from legitimate servers (Jamshidi et al., 2025)
• Cross-primitive escalation: read-only Resources (passive data) can be weaponized to trigger Tool execution (active operations) through the shared context window (Gaire et al., 2025)
• Current defenses are less than 30% effective across 17 attack types (Yang et al., 2025)

Here's the uncomfortable implication: any shared context mechanism without access control is immediately exploitable. CA-MCP's Shared Context Store proposal has no security model. The LLM-mediated pattern inherently exposes all cross-server data to every server in the context window.

The bridge pattern addresses this differently: the main process is the trust boundary. It can enforce per-extension access policies on handler calls. A crypto extension's bridge call to vault_get can be permitted while blocking a blog extension from the same call. This isn't defense-in-depth theater — it's a real architectural advantage of centralized mediation.

Why MCP Won't Add Server-to-Server

The MCP 2026 roadmap (published by the Agentic AI Foundation, which includes Anthropic, Google, Microsoft, and OpenAI) has four priorities: Transport Evolution, Agent Communication, Governance, Enterprise Readiness.

None include cross-server state sharing.

"Agent Communication" focuses on the Tasks primitive (SEP-1686) — a call-now/fetch-later pattern for long-running operations. Transport Evolution targets stateless horizontal scaling and server discovery via .well-known metadata. The specification is explicitly moving toward stateless servers.

This is the opposite direction from cross-server shared state. And it's deliberate: stateless servers are easier to scale, easier to secure, easier to reason about. The MCP spec team has chosen not to solve this problem — they're leaving it to the layers above (A2A) and the implementations below (framework-specific IPC).

One Scenario, Five Patterns

To make the comparison concrete: an agent needs to search the web, store the result in long-term memory, and sign a transaction using a private key — three MCP servers (search, memory, vault).

Pattern 1 (LLM-mediated): The LLM calls the search server, reads the output, decides what to remember, calls the memory server, reads the result, decides to sign, calls the vault server. Three LLM round-trips. The LLM sees the search results and can summarize before storing — useful. But the private key's signing parameters also flow through the LLM's context window — dangerous.

Pattern 2 (Single server): All three capabilities are in one MCP server. Internal function calls, no LLM mediation. Fast, but the search library, the database driver, and the cryptographic signing code all share one process. A vulnerability in the search dependency can reach the key material.

Pattern 3 (External coordination): A workflow engine orchestrates the sequence. The search result goes to a message queue, the memory server reads from the queue, the vault server gets a task. Robust and auditable, but you now operate a message broker alongside your agent.

Pattern 4 (A2A): Each server is an A2A agent with an Agent Card. The search agent creates a Task, the memory agent picks it up, and the vault agent gets a separate Task for signing. Works across machines and organizations. Overkill for three processes on one laptop.

Pattern 5 (Bridge IPC): All three servers call the main process via Unix socket. The search server writes its result to the bridge; the main process routes it to the memory handler; the vault handler signs without the key ever leaving the main process. Sub-millisecond, but only works on one machine.

No pattern is universally better. The choice depends on what you're optimizing for.

The Right Answer Depends on Your Constraint

There is no universal solution. Each pattern exists because of a different deployment constraint:

The social media discourse of "CLI+Skill replaces MCP" maps to the first pattern: let the LLM figure it out. For the majority of use cases — calling existing CLI tools, chaining simple API calls — this is correct and sufficient.

But when you need cryptographic keys that must never enter the LLM's context window, or hour-long audit pipelines with state machines spanning hundreds of agent turns, or deterministic cross-extension resource sharing at millisecond latency — you need one of the other four patterns. The skill approach can't even represent these requirements, let alone solve them.

What I Think Happens Next

The protocol layer is consolidating fast. ACP merged into A2A. The Agentic AI Foundation houses both MCP and A2A under one governance body. The likely equilibrium:

• MCP remains the tool access layer (agent→tool). Stateless, simple, universal.
• A2A becomes the agent coordination layer (agent↔agent). Stateful tasks, capability discovery, multi-turn negotiation.
• Framework-specific IPC (bridges, workflow engines, shared stores) handles the intra-system plumbing that neither protocol addresses.

The academic community's CA-MCP proposal (Shared Context Store) points toward a possible fourth layer — a data-plane coordination mechanism that sits between MCP servers without LLM mediation. But with the spec team moving toward stateless servers, this would need to emerge from the framework layer, not the protocol layer.

The bridge pattern — a single process mediating cross-extension communication via handler chains — will likely remain a niche solution for single-machine deployments. It's the right trade-off when your constraint is "zero dependencies, co-located processes, secret isolation." It's the wrong trade-off for anything distributed.

And that's fine. Not every solution needs to be universal. Sometimes a Unix socket and a JSON newline is exactly enough.

This analysis draws on open-source project documentation, academic papers, and protocol specifications. The key references are cited below. The infrastructure described in Pattern 5 (Bridge IPC) is open source: claude-ext.

Key references:

• Jayanti & Han (2026), "Enhancing MCP with Context-Aware Server Collaboration" — arXiv:2601.11595
• Ehtesham et al. (2025), "A Survey of Agent Interoperability Protocols" — arXiv:2505.02279
• Zhao et al. (2025), "When MCP Servers Attack" — arXiv:2509.24272
• Sun et al. (2025), "Cross-MCP Privacy Attack via Memory Exfiltration" — doi:10.1145/3733802.3764057
• Google A2A Protocol v1.0 — a2aproject/A2A