Multi-Agent Coordination and MCP

The growth numbers are not incidental. They make the argument.

MCP server downloads went from roughly 100,000 in November 2024 to approximately 8 million by April 2025. That kind of curve usually takes years to accumulate on a new open standard. It took five months.

Raw download volume can reflect hype as easily as adoption, though. What actually matters is what the platform layer did next. OpenAI adopted MCP across its Agents SDK, Responses API, and ChatGPT desktop in March 2025. Google DeepMind confirmed Gemini support in April. Microsoft Azure built MCP into Azure AI Agent Service in May. Three dominant model providers, all shipping support within a few months of each other.

When that happens, the calculus for developers shifts entirely. The alternative is fragmentation: maintaining separate integration layers for each provider, each with its own quirks and versioning. Nobody wants that work. Network effects handle the rest.

By mid-2026, more than 9,400 public MCP servers had been indexed across major registries, with private enterprise deployments estimated conservatively at three to four times that number. GitHub repositories built on MCP grew from roughly 2,000 in early 2025 to roughly 12,000 a year later. The developer community drove this, not platform vendors executing a product roadmap. That distinction matters more than people acknowledge.

One governance milestone that gets underreported: both MCP and A2A were donated to the Linux Foundation, with Anthropic, OpenAI, and Block as contributors and AWS, Google, Microsoft, and Cloudflare backing the effort. The coordination infrastructure of agentic AI is now, formally, nobody's proprietary asset.

Infrastructure that achieves this adoption velocity in under eighteen months tends to outpace the governance structures organizations build before deploying it. That gap between "widely deployed" and "properly governed" is where the real risks in this story live.

Why Coordinating Multiple Agents Is Harder Than Coordinating One

Sam Schillace, Microsoft's deputy CTO, put the core tension plainly: "To be autonomous you have to carry context through a bunch of actions, but the models are very disconnected and don't have continuity the way we do."

That disconnection is not a flaw in any particular model. It is structural. In MCP's original implementation, agents and servers are stateless. No global context accessible across the system. Each agent starts fresh, in a meaningful sense.

In a single-agent system, statelessness is manageable. One workflow, retrieve what you need, produce an output. In a multi-agent system, the same property produces cascading problems: redundant retrieval as each agent reconstructs what another already gathered, inconsistent state between agents working on related sub-tasks, no shared ground truth to arbitrate when two agents reach contradictory conclusions.

The failure rate data here is worth sitting with. Research cited in a 2025 arXiv paper by Cemri et al. and extended by Acharya in 2026 puts production failure rates for multi-agent LLM systems between 41% and 87%. The majority of those failures trace to coordination defects: specification ambiguity, inter-agent misalignment, verification gaps. These are coordination failures, not base-model capability failures.

The ceiling at 87% is not an edge case; it is close to the median of what production teams should anticipate without deliberate coordination design. The floor, 41%, still means nearly half of deployments fail. Both ends of that range are alarming, just differently so.

Scaling makes this structurally worse. As the number of agents grows, the number of possible interactions between them grows faster. Communication overhead can degrade total system performance even as individual agent capability improves. More agents can produce worse outcomes, counterintuitively, if the coordination layer was not designed for scale.

The tempting alternative, putting one agent in charge of everything, produces its own failure mode. A monolithic agent asked to handle a sufficiently broad task will fall into endless execution loops, or toward hallucinations that arise when a single model gets overwhelmed by scope. Specialization is necessary. But specialization without coordination is just fragmentation at a different level of abstraction.

What MCP's Architecture Actually Provides as a Coordination Layer

Consider what it used to take to build a research workflow using multiple agents across different models and tool providers. Each agent needed its own integration code for each tool. Passing context between agents required custom translation layers. Adding a new tool meant touching every agent that would eventually need it. Nobody writes much about this part, but it was miserable work.

MCP changes the underlying math. A compliant agent can discover what tools are available through standard capability advertisement, without bespoke negotiation. Agents can discover and invoke tools on demand rather than loading all tool definitions upfront, which matters for token efficiency at scale. A shared schema means an agent built by one team on one model can hand off context to an agent built by a different team on a different model, without either side needing to know the other's implementation details.

BCG articulated the efficiency argument precisely: without MCP, integration complexity rises quadratically as agents proliferate through an organization. With MCP, the relationship becomes linear. The difference between those two curves is the difference between enterprise-scale multi-agent systems being feasible or not.

Research by Krishnan in 2025 (arXiv:2504.21030) found measurable performance gains for MCP-enabled systems specifically on complex tasks requiring diverse expertise and sustained context awareness. The gains show up exactly where you'd expect: not in simple single-tool queries, but in the scenarios where coordination overhead is highest.

The underlying mechanism deserves precision. MCP does not just standardize message format. It creates a shared access layer, so what one agent knows about available tools and resources is structurally available to another without each agent reconstructing it independently. That is what makes MCP a coordination primitive rather than merely a messaging protocol.

What MCP omits is equally important. It standardizes the interface, not the coordination logic. How agents divide work, hand off state, and recover from partial failure is still an architectural choice the builder makes. MCP makes those choices feasible to implement. It does not make them for you.

The Four Orchestration Patterns Production Teams Use and Their Trade-offs

The pattern you choose determines where control concentrates, where failure propagates, and where governance gets difficult. These are not academic distinctions.

Hub-and-Spoke, or Hierarchical Coordination

A central orchestrator manages all agent interactions. Workflows are predictable. Debugging is tractable because you can trace decisions back to a single point. State consistency is relatively easy to enforce.

The trade-off is concentration. The orchestrator is a bottleneck; if it fails or gets overwhelmed, the entire system stalls. IBM research confirms that for enterprise-scale deployments spanning multiple business domains, hierarchical coordination is typically the only viable approach at scale. In practice, these architectures layer: domain-specific agent clusters, each managed by a supervisor, each supervisor reporting to a top-level strategic coordinator. It is organizational hierarchy expressed in software, which is either reassuring or unsettling depending on how much you trust organizational hierarchies.

Mesh Architecture

Agents communicate directly with each other. No single point of failure. When one agent fails, others route around it. Resilience is the defining property.

The trade-off: auditing is harder. Enforcing consistent access policy across direct peer connections requires a different governance approach than enforcing it at a central orchestrator. If you are responsible for compliance, mesh architectures demand rigorous distributed policy enforcement, and that rigor is difficult to achieve.

Swarm

Peer agents share state and pass control based on capabilities, with no fixed hierarchy. Maximum flexibility. Research tasks and long-horizon workflows benefit most from this model because the task structure itself is not known in advance.

Most production teams limit swarm architectures to back-office or research workloads. Control and observability are hardest to maintain here, and that difficulty carries real consequences when something goes wrong in a live system.

Hybrid: The Emerging Default

Most mature production systems do not choose one pattern. They compose them: hierarchical at the top level, mesh coordination within leaf-level agent clusters, pipeline stages that spawn swarm configurations for parallel data collection. The patterns are composable, and thoughtful architectures match the pattern to each subsystem's actual requirements.

Across all four, task decomposition is foundational. High-level objectives need to be broken into sub-goals assigned to specialized agents: retrievers, planners, executors, evaluators. Without that decomposition, agents get overwhelmed by scope, and you reproduce the monolithic failure mode at the multi-agent level, which is a frustrating place to end up.

Each pattern also distributes access and authority differently. Hub-and-spoke concentrates policy enforcement at the orchestrator, which is tractable to govern. Mesh and swarm distribute it in ways that require a fundamentally different control approach, and that carries forward into every conversation about security.

How MCP Fits Alongside A2A and the Other Emerging Agent Protocols

The ecosystem has not converged on one protocol for all agent communication. It has converged on four complementary protocols, each addressing a different layer: MCP from Anthropic, A2A from Google, ACP from IBM, ANP from the community. Treating them as competing alternatives is a mistake. They are more accurately a stack.

The distinction that matters most for multi-agent coordination is between MCP and A2A. MCP handles the vertical connection: agent to tools, data sources, and external systems. A2A handles the horizontal connection: agent to agent, including task delegation and capability advertisement. Almost any serious multi-agent system needs both, and framing them as rivals misunderstands what each one actually does.

A2A launched in April 2025 with more than 50 technology partners, using HTTP, Server-Sent Events, and JSON-RPC 2.0, with Agent Cards for advertising what a given agent can do. By April 2026, more than 150 organizations had joined.

A concrete architecture illustrates how the layers interact. A planning agent receives a high-level objective and decomposes it into sub-tasks, delegating via A2A. A research agent uses MCP to access web search and document retrieval. A coding agent uses MCP to access a code execution environment. The planning agent synthesizes results through A2A. Each protocol layer can evolve independently, which is the architecture's real strength.

There is also a governance implication that follows directly from this structure. The boundary between MCP and A2A is a governance boundary. An organization that governs its MCP layer but not its A2A layer has controlled tool access while leaving inter-agent delegation ungoverned. Both boundaries require deliberate policy. In practice, the A2A side gets neglected more often.

The Security Vulnerabilities That Appear When MCP Servers Go Ungoverned

A July 2025 internet-wide scan identified more than 1,800 MCP servers responding to unauthenticated tool-listing requests. Servers that would hand their full capability manifest to any requester, no credential check required.

That is the default state of servers deployed without deliberate security posture, and it is not a misconfiguration affecting a handful of early adopters.

The Vulnerable MCP Project, a research collaboration spanning SentinelOne, Snyk, Trail of Bits, and CyberArk, tracks more than 50 known MCP vulnerabilities across servers, clients, and infrastructure, with 13 rated critical. New CVE disclosures continued through the first half of 2026. The attack surface is active and growing.

The specific vectors deserve naming because each represents a distinct failure mode, not variations on a theme.

Tool poisoning is the most direct: a malicious MCP server exposes tools with legitimate-sounding names that perform unauthorized actions, including data exfiltration, when an agent invokes them. The agent has no mechanism to verify that the tool does what its name implies. It trusts the name.

EchoLeak, catalogued as CVE-2025-32711, targeted Microsoft 365 Copilot. Attackers embedded engineered prompts inside ordinary Word documents and emails. When Copilot summarized those files, it executed the hidden instructions and exfiltrated sensitive data, with no user interaction required at the moment of attack. The user opened a document. That was the whole exposure.

MCPoison, CVE-2025-54136, exploited Cursor IDE through a tactic researchers called rug-pulling. An attacker commits a benign MCP configuration to a shared repository. Developers review it, approve it, move on. The attacker then replaces the configuration with a malicious payload. Every subsequent development session silently executes the attacker's commands, because no re-approval prompt fires after the initial review. The attack specifically exploits the trust that comes from a reviewed configuration, which makes it particularly insidious.

The September 2025 npm supply chain attack compromised 18 widely-used packages, including indirect dependencies of the official MCP TypeScript SDK. Malicious versions carrying arbitrary code execution capabilities reached an estimated 2.6 billion weekly download counts across affected packages.

Cross-agent context poisoning extends the blast radius further. In a single-agent system, a compromised tool damages one workflow. In a multi-agent system where agents share context through MCP, a single compromised server can propagate malicious state to every agent drawing from that context. The coordination capability that makes multi-agent systems powerful is precisely what makes a single point of compromise more consequential. The same architecture produces different effects depending on who gets there first.

None of these were surprises that emerged only after deployment. An ungoverned MCP server is exploitable from the moment it goes live.

What Governing the MCP Coordination Layer Requires in Practice

Start with the registry problem. Every MCP server deployed without a registry entry is an identity the organization cannot account for, and an unaccounted identity is reliably the one that gets exploited. With thousands of public servers indexed and an estimated multiple of that in private deployments, informal tracking, a spreadsheet, a shared document, a developer's memory, is not a viable approach. Organizations need centralized registries that enforce enrollment before a server is permitted to participate in any agent workflow.

Access control for AI agents requires the same intentionality that access control for human users requires, but most security teams are still applying a mental model built for people logging into systems, not for agents invoking tools on behalf of other agents. Role-based access control for agents is not about restricting capability for its own sake. It is about ensuring that what a given agent can access reflects a choice the organization made deliberately, not an accident of deployment order.

Each orchestration pattern distributes that question differently. In a hierarchical system, governing the orchestrator is the primary surface; it is the chokepoint, and policy enforcement there is tractable. In mesh and swarm architectures, access decisions are distributed, which means policy needs to follow the agents rather than concentrate at a central node. The security approach that works well for hub-and-spoke can leave significant exposure in a mesh deployment. These are not the same problem with different labels.

Authentication cannot be optional. Servers that respond to unauthenticated requests offer no meaningful perimeter. Token-based or certificate-based authentication, enforced before capability advertisement, is a baseline requirement, not a configuration preference.

Tool verification addresses the trust gap that tool poisoning and rug-pulling both exploit. Cryptographic signing of tool definitions, combined with validation at invocation time, allows an agent to confirm that the tool it is about to call has been modified since it was reviewed. The rug-pull attack vector exists specifically because most current deployments skip this step.

Monitoring in multi-agent systems needs to account for inter-agent communication, not just individual agent actions. An anomalous action that would be obvious in a single-agent log can disappear into the noise of a high-volume multi-agent workflow if the monitoring layer is not designed to correlate across agents and across MCP connections. This is less a technology problem than an instrumentation discipline problem, which makes it harder in some ways than a purely technical challenge.

Prompt injection defenses require treating content retrieved from external sources, documents, emails, web pages, database fields, as potentially adversarial. EchoLeak was not a novel attack concept; it was a known attack class applied to a new surface. The defense is known too: sanitizing or sandboxing external content before it reaches an agent's instruction context. It requires deliberate implementation, which is different from being technically difficult.

The throughline across all of this is that MCP's standardization creates leverage in both directions. The shared interface that makes compliant agents interoperable also means a governance control applied at that interface propagates broadly. A policy enforced at the MCP layer reaches every agent and every tool that speaks the protocol. A gap in MCP governance is a gap the entire system shares.

The architecture gives you the surface. Registries, access controls, authentication, verification, monitoring: those are decisions, not defaults. They happen because the people responsible for these systems decide to do that work, not because the protocol required it.