MCP and A2A in the Enterprise: How AI Agents Reach Your Systems

Every agent program reaches the point where the agent must read the account in Salesforce, check the order in SAP and open the ticket in ServiceNow, as the person who asked. The Model Context Protocol (MCP) is the open standard for those connections; the Agent2Agent protocol (A2A) is the open standard for one agent to hand work to another.

• ~500Mmonthly downloads of MCP's main SDKs by July 2026¹
• 150+organizations supporting the A2A protocol at its first anniversary in April 2026⁸
• 1,467MCP servers found exposed on the internet in April 2026, nearly triple the July 2025 count¹¹

What MCP is and what an MCP server does

MCP is an open protocol that defines how an AI application discovers and calls tools and reads data held in other systems.³ It has three roles: the host is the AI application, a client inside the host holds each connection, and a server exposes capabilities. A server offers three kinds of capability: tools the model can call, resources that supply data, and prompts that package common workflows. Every message is JSON-RPC 2.0.³

An MCP server is a thin adapter in front of a system you already run. It describes each capability in a schema the model can read and translates each call into that system's own API. Build one server for your CRM and every MCP-capable agent and tool in the company can use it, so integrations stop multiplying with every new agent.

Adoption has been fast: more than 97 million monthly SDK downloads in December 2025, close to half a billion a month by July 2026.⁷¹ About a year after its release, the lab that introduced MCP donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation, which does not dictate the protocol's technical direction; that stays with its maintainers.⁷

What A2A is and when you need it

A2A (Agent2Agent) is an open protocol that lets AI agents discover, communicate and transact with each other across frameworks, vendors and platforms.⁸ Where MCP connects an agent to tools, A2A connects agents to agents: the calling agent hands over a task, and the receiving agent plans the work and uses its own tools to do it.

A2A is hosted by the Linux Foundation. By its first anniversary in April 2026, its supporting organizations had grown from more than 50 to over 150, including Salesforce, SAP and ServiceNow.⁸ Version 1.0, its first stable specification, added multi-tenancy and modernized security flows, and the protocol supports signed Agent Cards, so an agent's published description of itself can be verified cryptographically.⁸

Most enterprises need MCP first. A2A earns its place when an agent must hand work to one you do not build or control: a supplier's agent, an agent inside a SaaS platform, or another business unit's agent with its own release cycle. SAP's guidance draws the same line, sending multi-agent scenarios that cross system and vendor boundaries to A2A.¹⁰ Inside one team's system, an agent calling a sub-agent is ordinary code.

MCP vs A2A vs APIs vs RAG

They work at different layers: an API is how a system exposes functions, MCP is how an agent discovers and calls those functions, A2A is how an agent delegates to another agent, and RAG is a technique for retrieving documents to ground a model's answer. A production agent often uses all four.

Two misreadings are common. The first treats MCP as a replacement for APIs. An MCP server calls your APIs, so every weakness in them (coarse permissions, missing validation, no rate limits) reaches the agent unchanged. The second expects MCP to make agents understand your business. SAP's reference architecture is blunt: "MCP is a connectivity protocol" that adds no business context. Wiring it straight to raw transactional APIs, SAP warns, brings poor entity discovery, heavy token use and, on writes, a significant risk of incorrect business transactions.¹⁰

RAG and MCP meet in the middle. A retrieval service over your policies and contracts can be offered to agents as an MCP tool, behind the same identity, gateway and logs as every other call. Answer quality still depends on the pipeline; see Enterprise RAG in production.

What the 2026-07-28 MCP specification changed

The revision published on July 28, 2026 made MCP stateless, made its traffic routable by standard HTTP infrastructure, hardened authorization and moved long-running work into an official Tasks extension.¹ The changes that matter in production, from the release notes and changelog:¹²

Two details matter more than they look. A broken response stream now loses the in-flight request, and the client must resend it as a new request, so every tool that writes needs an idempotency key or a retried write can land twice.² And the specification now documents how OpenTelemetry trace context travels in each request, so one trace can follow a task from the agent through the gateway into the system of record.² The official TypeScript, Python, Go and C# SDKs support the revision, with Rust in beta.¹

Enterprise MCP reference architecture: gateway, registry, identity and audit

Run MCP the way you run any API tier: agents reach tools only through a gateway, see only servers in your private registry, act with identities from your identity provider, and leave a trace of every call. The protocol will not do this for you. Authorization is optional in the specification, which says MCP cannot enforce its security principles at the protocol level.⁴³

The public MCP Registry does not replace your own. It is in preview, holds metadata only for publicly accessible servers, does not accept private ones and leaves security scanning to others; the project recommends a private registry for internal servers, which can implement the public registry's OpenAPI interface.⁶ An entry needs little more than this:

# One entry in the private MCP registry. The gateway refuses any server or tool not listed.
server: crm-accounts
owner: sales-operations              # a named team, reviewed every quarter
endpoint: https://mcp.internal.example.com/crm
protocol: "2026-07-28"
data_class: confidential
auth:
  issuer: https://idp.example.com    # your identity provider
  audience: https://mcp.internal.example.com/crm
tools:
  - name: get_account                # read
    scope: crm.accounts.read
    description_sha256: 3f9a0c...    # a changed description blocks the server until reviewed
  - name: log_call_note              # reversible write
    scope: crm.activities.write
    idempotency: required
    rate_limit: 60/min
  # close_account is irreversible and deliberately absent
next_review: 2026-12-31

Identity is where the 2026 extensions help most. With the Enterprise-Managed Authorization extension, your identity provider checks group membership, roles and conditional access, then issues the MCP client a signed grant (an ID-JAG) that it exchanges for an access token.⁵ IT grants access from one console, and removing a person at the identity provider revokes their access across every MCP client. Client support varies and the extension is off by default, so confirm it for each client you allow.⁵

For audit, SAP's guidance makes a good minimum everywhere: log every tool invocation with the caller's identity, parameters with personal data redacted, the target API, response status and latency.¹⁰

Which systems to expose through MCP first

Expose first the systems that score high on business value and API quality and low on write risk and data sensitivity. In most estates that means read access to knowledge bases, CRM records and service tickets, well ahead of writes to ERP, payroll or payments. Score each candidate from 1 to 3 on four criteria, where 3 always favors going early, and add the scores.

Two rules sit on top of the score. A tool that is absent from the server cannot be called, so the safest treatment for an irreversible action in the early waves is to leave it out. And count the tools: descriptions are typically loaded into the model's context, so sixty loosely named tools cost tokens and accuracy on every turn, while a handful of task-shaped ones are easier to test and review.

Vendor-hosted MCP servers vs building your own

Use the vendor's hosted MCP server where one exists and covers the task, because it enforces the permissions you already maintain; build your own where you need task-shaped tools, logic that spans systems, or a system with no vendor offering. Most estates end up with both, behind one gateway.

Salesforce made its hosted MCP servers generally available in April 2026 for Enterprise Edition orgs and above. Access runs through OAuth with PKCE, every transaction runs as the authenticated user with no anonymous service account, and object permissions, field-level security and sharing rules still apply.⁹ That is the reason to prefer it: the permission model your Salesforce administrators maintain becomes the agent's, and a change there needs no change in the agent.

SAP's guidance, updated in June 2026, is more guarded. It permits third-party MCP servers to call SAP APIs provided its API Policy is followed in full, and offers managed alternatives: an MCP gateway in SAP Integration Suite that creates MCP servers from your existing APIs, and servers generated by its agent-building tools.¹⁰ If you run your own server against SAP, it expects authentication on every call, parameter validation, rate limits that protect API quotas from runaway agent loops, and a log of every invocation.¹⁰ That list is the scope of work for any server you build.

Is MCP secure? The risks a CISO should control

MCP is as secure as the controls around it. The failures seen so far come from five places, and each has a known control.

• Unauthenticated servers Research published in July 2025 found 492 MCP servers with no client authentication or traffic encryption; by April 2026 exposed servers had nearly tripled to 1,467, and 70 hosts offered a tool that executes SQL.¹¹ Control: servers are reachable only through the gateway.
• Over-broad scopes The specification asks for least privilege: a minimal scope set up front, with more granted through step-up authorization when a privileged tool is first used.⁴ Control: a scope per tool, reviewed in the registry.
• Tool poisoning Researchers showed in April 2025 that instructions hidden in a tool's description, invisible to the user but read by the model, can steer an agent into leaking data, and that a server can change a description after approval.¹² The specification says tool annotations are untrusted unless they come from a trusted server.³ Control: pin description hashes in the registry and block any server whose descriptions change until reviewed.
• Token passthrough MCP servers must accept only tokens issued for themselves and must not pass any other token on.⁴ SAP adds that forwarding the caller's token hands the server the user's full permissions and breaks audit attribution, and points to OAuth token exchange (RFC 8693) instead.¹⁰ Control: the gateway checks the audience on every call.
• Shadow servers Local servers on developer laptops sit outside the OAuth flow: the specification tells STDIO servers to take credentials from the environment.⁴ Control: managed clients that load only registered servers, and a regular scan for the rest.

These controls cover the connection layer. Our AI agent security guide sets out the threat model for the agent itself and the controls a CISO should require.

Who governs MCP and A2A, and where lock-in sits

Both protocols sit under the Linux Foundation: MCP through the Agentic AI Foundation since December 2025, and A2A as a Linux Foundation project.⁷⁸ MCP now has a formal feature lifecycle with a minimum twelve-month deprecation window, so a deprecated feature keeps working for at least a year after notice and upgrades can be scheduled.¹²

Neutral protocols move the lock-in question up a layer, to the tool designs your team writes, the gateway and registry product you choose, and the terms of any vendor-hosted server. Keep the first two as your own assets: tool schemas and descriptions in your repository, registry entries and gateway policies as exportable configuration. Test servers against both a frontier model and an open-weights model, so changing the model never forces a change to the integration.

The protocol is settled enough to build on, and the architecture around it is familiar. In our AI agent development work, the gateway, registry, identity and audit layers go in before the first server goes live, the first wave is read access as the requesting user, and agents are allowed to do more only as the traces show they can be trusted with it.