Protocol Interop (MCP / A2A)
Standard servers for tools and agent-to-agent messaging across vendors.
Problem
Every agent framework used to need its own custom connector for every tool and data source, and agents from different vendors couldn’t work together at all. Ten agents and twenty systems meant up to two hundred one-off integrations, each with its own auth, error handling and upkeep.
- Organizations use agents and tools from many vendors.
- Custom connectors multiply as agents and systems are added.
- Standard interfaces only help if both sides adopt them.
- Opening systems to agents widens the security surface.
Solution
Put standard protocols between the parts. For agent-to-tool access, expose each system once as a server using a common protocol such as the Model Context Protocol (MCP), describing its tools, resources and prompts in a standard way. Any compatible agent can then use it. For agent-to-agent work, use an agent-to-agent protocol such as A2A, where agents publish what they can do and exchange tasks and results. Put auth, rate limits and audit at these protocol boundaries, through a gateway where possible, so every connection follows the same rules.
Diagram
Integrations go from many-to-many to many-to-one: each system is exposed once, and each agent speaks one protocol.
When to use
Use it when
- Several agents need the same systems
- Agents from different vendors or teams must work together
- You want to swap models or frameworks without rewriting integrations
- Security wants a single choke point for agent access
Avoid it when
- One agent and one or two systems; a direct integration is simpler
- The system's API is too sensitive to expose broadly, even behind policy
- The protocol's maturity doesn't yet meet your compliance requirements
Trade-offs
Gains
- Each system is integrated once, then reused by every agent
- Agents, models and frameworks can be swapped independently
- One place to enforce auth, rate limits and audit
Costs
- Protocols and their security practices are still maturing
- Every exposed server is a new attack surface
- Tool descriptions from third-party servers can't be fully trusted
Worked example
An enterprise with 6 agents from 3 vendors and 8 internal systems.
- BeforeEach agent had custom connectors, adding up to 31 integrations, with 4 different approaches to CRM auth alone.
- Tool serversThe platform team exposes each of the 8 systems once as an MCP server: CRM, ticketing, the HR system, document storage and others.
- GatewayAll agent traffic to those servers goes through one gateway that checks the user’s identity, applies per-agent tool allowlists and logs every call.
- Agent to agentA vendor’s sales agent asks the internal pricing agent for a quote over an agent-to-agent protocol. The pricing agent returns a structured quote without exposing its own tools.
- After8 servers and 1 gateway replace 31 custom connectors. Adding a 7th agent takes a configuration change instead of new integrations.
Failure modes
| Failure | Symptom | Mitigation |
|---|---|---|
| Malicious or poisoned tool descriptions | Third-party server's tool text steers the agent | Allowlist servers; review descriptions; treat server output as untrusted |
| Over-exposed servers | Server offers write tools every agent can reach | Per-agent allowlists and scopes enforced at the gateway |
| Version drift | Server update breaks agents that relied on old behavior | Version servers; test agents against new versions before rollout |
| Auth shortcuts | Shared service accounts instead of user-level access | Pass user identity through; see Delegated Agent Identity |