Key takeaways
- MCP became infrastructure in 2026: a Linux Foundation fund governs it, and the 2026-07-28 specification made remote servers stateless.
- MCP now standardizes who is calling, including enterprise single sign-on. What each caller may do, and the audit trail that proves it, stays with you.
- Each system of record gets one curated MCP server. One MCP gateway in front of those servers handles identity, registry, policy, and audit.
- The build runs in four moves: a read-only spike, identity before the second server, registry and policy as servers multiply, and audit designed as evidence.
- The Write-Access Ladder grants write access tool by tool, and A2A enters only when independent agents must delegate work.
This playbook shows CTOs and platform engineers how to build an MCP server for enterprise systems of record and how to govern it through an MCP gateway. An MCP server is a service that exposes one system’s selected capabilities to AI agents through the Model Context Protocol. The playbook covers the reference architecture and the build order, focusing on the controls that decide when an agent may write. Implementers who need a first working server should start with the official MCP server quickstart, since this piece has no code walkthrough.
What changed in 2026: MCP became infrastructure
Between December 2025 and July 2026, the Model Context Protocol (MCP) gained the traits infrastructure teams check before they adopt a standard.
Neutral governance and enterprise sign-on
Governance changed first: on December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation. Anthropic co-founded the fund with Block and OpenAI, and AWS, Bloomberg, Cloudflare, Google, and Microsoft joined them as platinum members. By April 2026, the foundation counted 170 member organizations. MCP’s direction now comes from an open process in which competing vendors take part.
Enterprise single sign-on (SSO) followed on June 18, 2026, when the maintainers declared the Enterprise-Managed Authorization (EMA) extension stable. With EMA, employees sign in once through the corporate identity provider (IdP), and the client exchanges the resulting assertion for access tokens. IT then decides centrally which servers each group of employees can reach.
The stateless 2026-07-28 specification
The largest technical change came with the 2026-07-28 specification, published as final on July 28, 2026, about 10 weeks after its release candidate. The revision removed the initialization handshake along with protocol-level sessions, which had made remote servers hard to scale. In December 2025, MCP transport maintainers Kurtis Van Gent and Shaun Smith described the problem on the MCP blog. Stateful connections, they wrote, “force ‘sticky’ routing that pins traffic to specific servers, preventing effective auto-scaling.” Instead, each request now carries its protocol version and client capabilities, so any instance behind a load balancer can serve it. A remote MCP server is now an ordinary HTTP workload for the Kubernetes clusters and API gateways a team already runs.
The same release adopted a feature lifecycle and deprecation policy. Deprecated features stay in the specification for at least 12 months. For a feature that poses an active security risk, however, the minimum drops to 90 days. A public registry of deprecated features lists when each one becomes eligible for removal, so teams can plan migrations against a known window.
MCP adoption in 2026
On December 9, 2025, Anthropic counted over 10,000 active public MCP servers and over 97 million monthly SDK downloads. On July 28, 2026, it reported more than 400 million monthly SDK downloads. Demand for agents keeps rising as well. In August 2025, Gartner predicted that 40% of enterprise applications would integrate task-specific AI agents by the end of 2026. The comparable share at the time of the forecast was less than 5%.
Why the integration math changed
Without a shared protocol, each agent surface needs its own connector to each system, with its own authentication code. A company with 4 systems and 3 agent surfaces therefore needs 12 integrations. With MCP, a company exposes each system once through a governed server, and every agent surface speaks the same protocol. The build shrinks to 7 components: 4 servers and 3 clients. The count now grows as N+M instead of N×M. Every agent added later also inherits the controls already built into the servers it calls.
MCP security: What the specification leaves to you
The specification is explicit about its limits. Its security section says that “MCP itself cannot enforce these security principles at the protocol level” and hands the work to implementers. The tools chapter requires servers to implement access controls and rate limits, and it asks clients to log tool usage for audit purposes. The specification defines no policy model and no audit record format for either duty. Even its OAuth-based authorization framework is optional.
The roadmap shows the same split. In March 2026, the maintainers named audit trails, SSO-integrated authentication, gateway behavior, and configuration portability as the open enterprise problems. SSO has since arrived as EMA, but the roadmap updated on August 22, 2026, no longer lists the other items among its priorities. Its enterprise track now centers on agent identity, including proof-of-possession tokens and workload identity federation.
The protocol, in other words, increasingly standardizes who is calling a server. Deciding what that caller may do with each tool, and keeping evidence of it, stays with the deploying organization. This playbook covers authorization policy and audit evidence. SumatoSoft’s AI integration services design that layer first, because every later agent depends on it.
The protocol in brief, and the version to target
MCP follows a client-server model over JSON-RPC 2.0. A host application, such as a chat assistant or your own agent runtime, runs one MCP client per server connection. Each server wraps a system and exposes selected capabilities from it, which MCP calls primitives. Tools let the model query or change a system, and resources carry data into its context. Prompts package reusable message templates.
The protocol also has an outer boundary. MCP connects an agent to tools and data, while Agent2Agent (A2A) connects agents to each other. The AAIF has hosted A2A as a separate project since August 2026, and a later section sets the boundary between them.
Local and remote MCP servers
The transport decides where a server can run safely. A stdio server is a local subprocess that talks over standard input and output and reads credentials from the environment. That model suits a developer’s personal productivity tools. Default to remote servers over Streamable HTTP, the protocol’s standard network transport, for anything that touches shared company data. A remote server can enforce central authentication and write every call to a shared log. The exception is a local server that reads a developer’s own files with that developer’s own credentials.
The MCP revision to target
Target the 2026-07-28 revision for every new build. It is not backward-compatible with 2025-11-25 and earlier, so a server built on an older revision faces a migration. The changelog lists every change, and the table below covers the ones that shape a server build.
| What changed | What to do |
|---|---|
| The initialization handshake and the Mcp-Session-Id header are gone. Each request carries its protocol version and client capabilities. | Drop session state from the server, and implement the required server/discover method so clients can check versions up front. |
| Every result carries a required resultType field, and multi-round-trip requests replace server-initiated requests. | Mark each result as complete or input_required. Where the server used to send its own request, return input_required and let the client retry with the answer. |
| Tasks moved out of the core protocol into an official extension. | Use the Tasks extension for long-running calls, and poll for results with tasks/get. |
| Results from tools/list, prompts/list, resources/list and resources/read must carry ttlMs and cacheScope cache hints. | Set a cache lifetime and a cache scope on every list and read result. |
| Roots, Sampling, Logging, and Dynamic Client Registration are deprecated. | Leave them out of new builds. The changelog names a replacement for each, such as Client ID Metadata Documents for client registration. |
| The legacy HTTP+SSE transport, deprecated since 2025-03-26, is now on the removal track. | Serve remote clients over Streamable HTTP only. |
| A request that declares an unsupported revision returns an UnsupportedProtocolVersionError. | Migrate servers on older revisions before their clients move to 2026-07-28. |
Enterprise MCP architecture: One gateway, one server per system
The Governed MCP Stack is a four-layer reference architecture for enterprise MCP. Every agent reaches systems of record through one gateway and one curated MCP server per system. Each layer does one job.
Agent clients include commercial assistants and the agents your own teams build. None of them connects to a system of record directly. Each registers as its own OAuth client, so the logs can tell agents apart.
What is an MCP gateway?
An MCP gateway is a single enforcement point between agents and MCP servers. Agents see it as one MCP server, and the servers behind it see a client with its own credentials. The gateway carries four duties, listed in the order you build them: identity, registry, policy, and audit.
Identity at the MCP gateway
The MCP gateway authenticates each agent and its user through your IdP, and through EMA where clients support it. The MCP roadmap notes that existing servers “lean on pasted API keys and long-lived refresh tokens.”
The gateway replaces those credentials with short-lived tokens bound to a single audience. The specification forbids token passthrough. The gateway therefore obtains a separate token for each target server, for example through OAuth token exchange (RFC 8693).
The MCP registry
An MCP registry is the catalog of approved MCP servers that the gateway checks before it routes a call. It records which servers exist, who owns each one, which tools each exposes, and which reviewed version of each tool definition is live. Unregistered servers stay out of reach, and a changed tool definition goes back through review. Researchers who cataloged MCP threats (Hou et al.) describe “rug pulls,” in which a trusted server later changes its behavior. At the April 2026 MCP Dev Summit, Uber described an internal MCP gateway and registry with stricter review for third-party servers.
Policy at the MCP gateway
The policy engine decides, per tool and per scope, whether a call proceeds. An inventory agent may read stock and draft purchase orders, while payroll tools stay out of every agent’s reach. The effective permission for any call is the intersection of the agent’s rights and the rights of its human principal. Since the 2026-07-28 revision, Mcp-Method and Mcp-Name headers let standard gateways route and meter traffic by tool without parsing bodies. Argument-level rules, such as an amount cap, need body inspection unless the server marks that argument for mirroring into an Mcp-Param header. Quotas and rate limits belong here too, because a looping agent causes cost overruns and outages at once.
Audit at the MCP gateway
The MCP gateway writes one record per tool call with the agent identity, the human principal, the tool, its arguments, the result, and any approval. The 2026-07-28 revision documents how to carry OpenTelemetry trace context in request metadata. One trace can then follow a call from the client to the backend system.
Per-system MCP servers and systems of record
Per-system MCP servers give each system of record one server with a curated toolset that covers only the operations the use cases need. If an ERP API offers 200 endpoints and the first use cases need 5 operations, the server exposes those 5. Choosing those tools is the biggest security decision in the stack. The specification also lets a server list only the tools a caller’s scopes permit, so each agent sees its own surface. Every server inherits the quality of the data behind it as well. SumatoSoft’s AI readiness research surveyed 72 business and technology leaders. Of those, 58% named messy, fragmented, poorly labeled, or inconsistently structured data as their biggest readiness gap.
Systems of record stay unchanged, and each MCP server reaches its system through a service account with the narrowest rights its toolset needs.
Why governance concentrates at the MCP gateway
Governance concentrates at the gateway because copies of one policy across many servers get edited separately until they disagree. The servers stay thin, but each still validates its token audience and every input, as the specification requires. A request that reaches a server around the gateway therefore fails. This rule prevents direct connections, where each agent-server pair negotiates its own credentials and the N×M problem returns as a security problem.
The core argument. MCP now passes the tests infrastructure teams apply: neutral governance, a stateless transport behind ordinary load balancers, a published deprecation window, and enterprise sign-on. The remaining engineering is the control layer. Expose each system once behind one governed gateway, and grant write access tool by tool as evidence accumulates.
How to build an MCP server in four moves
The build order follows dependency, since each move creates something the next one needs. The same sequence shapes SumatoSoft’s AI agents development work, in which agents reach enterprise systems only through governed tools.
Move 1: A read-only spike on one system
Pick the system that people ask the most questions about, such as the ERP or the data warehouse. Build one remote MCP server with 3 to 5 read-only tools against a read replica of production data. Scope the work as a spike with one system and one business question, timeboxed to 2 to 4 weeks. The spike answers whether governed tool calls create enough value on this system to justify the rest of the stack. If the first system is still open, an AI readiness assessment settles the choice before engineering starts. Our comparison of a spike vs. a full PoC describes the spike shape in more detail.
Done when: a named agent answers business questions from the system’s data through authenticated calls, and the MCP gateway logs every call.
Move 2: Central identity before server number two
Adding central authentication after several servers go live costs more than building it first. The extra cost shows up in code and in talks with the server owners. Put OAuth-based authentication at the MCP gateway before the second server exists. That means a distinct client identity per agent, the human principal on every call, tokens bound to one server, and no shared API keys. Connect the gateway to your IdP and adopt EMA where clients support it, so agent access follows existing identity groups. A departing employee then loses agent access in the same step as all other access.
Done when: the logs alone show, for any call, which agent made it and on whose behalf.
Move 3: A registry and a policy engine for the second team
Once a second team runs a server, discovery and authorization become the bottleneck. Stand up the registry with an owner and trust tier per server, and move per-tool authorization into the policy engine. Add quotas and rate limits per agent and per tool in the same move. Treat third-party servers as a stricter tier, since their tool definitions change on another company’s release schedule.
Done when: an unregistered server cannot be reached, and no agent can exceed its quota on a registered one.
Move 4: Audit records a reviewer can use
An audit record for agent actions has to let a reviewer reconstruct a decision, which standard access logs cannot do. Each record captures the tool, the arguments, the agent identity, the human principal, the result, and any approval. One trace ID joins the records across every hop.
For EU deployers of high-risk AI systems, these records support Article 26 of the AI Act. Article 26 requires deployers to follow the provider’s instructions, assign human oversight, monitor the system, and keep the logs it generates. Deployers must retain the logs under their control for at least 6 months, unless Union or national law provides otherwise. Under the Digital Omnibus amendment, Regulation (EU) 2026/1744, those duties apply to Annex III systems from December 2, 2027. Our guide to EU AI Act deployer obligations covers classification.
The gap shows clearly in regulated industries. In SumatoSoft’s research on compliance and audit barriers, 19 of the 33 blocking constraints concerned producing evidence. For banks, our guide to AI in regulated finance lists the evidence an examiner asks for.
Done when: a reviewer can reconstruct any consequential agent action without asking an engineer.
Take the four moves to your platform team. The Governed MCP Stack blueprint turns this playbook into a working document. It holds the reference architecture, a checklist for each move with its done-when gate, the ladder’s promotion criteria, and a readiness score. Get the blueprint (PDF).
The Write-Access Ladder
The Write-Access Ladder is a four-tier model for granting AI agents write access to enterprise systems tool by tool. Its tiers run from Read to Propose to Scoped write to Autonomous write. Human approval applies at the Propose tier, and every tier writes to the audit record.
Write access needs its own framework because tool calls and API calls differ in where the decision comes from. A REST integration runs a code path that a developer wrote and a reviewer approved before release. An MCP tool call runs because a model decided at runtime that this tool, with these arguments, serves the request. The traffic looks alike, yet the second case needs a different threat model and a richer audit record. Teams that govern MCP as just another API integration end up with logs that name the caller. Those logs omit the context that led to the call.
The four tiers
- Tier 0: Read. Every system starts here, with curated read tools under narrow scopes. Many systems should stay here for months, because read access alone answers the questions that justified the spike.
- Tier 1: Propose. The agent drafts an action, such as a purchase order or customer email, and a named person approves it first. The approval and the approver’s identity enter the audit record. Plan for most production use cases in 2026 to run at this tier. The agent does the drafting, and each decision keeps a named owner.
- Tier 2: Scoped write. The agent writes directly, but only for narrow, reversible actions. Hard limits apply, such as an amount cap or an allowlist of target records. Each tool earns this tier on its own, and a tested kill switch must revoke its write access within seconds.
- Tier 3: Autonomous write. This tier stays closed for most organizations in 2026. Tier 3 stays on the ladder to keep the roadmap honest. A team requesting it this quarter should get a plain no and a list of the evidence it needs first.
Promotion criteria between tiers
Each promotion is an engineering decision that needs evidence, and the audit record names the person who approved it. A tool moves from Read to Propose when its read calls show stable accuracy and its owner has named approvers. It moves from Propose to Scoped write once four conditions hold:
- Approvers accept drafts without edits at a rate set in advance.
- Red-teaming finds no path around the tool’s limits.
- A rollback procedure exists for every action the tool can take.
- The kill switch has passed a live test.
The ladder applies the red-teaming and AgentOps phases of SumatoSoft’s Agentic Development Lifecycle (ADLC) to tool access. It also supplies the mechanism behind two of the seven enterprise AI adoption risks: the expanding attack surface and ungoverned agentic autonomy.
What the protocol contributes to the ladder
The protocol supports the ladder at its edges without enforcing it. Step-up authorization lets a server challenge for a broader scope when a privileged tool is first called. Each tier can then map to a scope. Tool annotations such as readOnlyHint describe intent, but clients must treat them as untrusted unless the server is trusted. Enforcement therefore belongs in the MCP gateway. Multi-round-trip requests let a server pause a call until the user confirms or supplies missing input. A second person’s approval, such as a finance manager’s, still runs through your workflow and lands in the audit record.
MCP vs. A2A: Where the boundary falls
MCP connects an agent to tools and data, and A2A connects independent agents so they can delegate work to one another. In the Linux Foundation’s words, A2A “defines how agents communicate and coordinate with each other across organizational boundaries.” MCP, by the same statement, “defines how agents connect to internal tools and data sources.” A 2025 survey of agent interoperability protocols (Ehtesham et al.) formalizes the split. It describes MCP as a JSON-RPC interface for calling tools and A2A as peer-to-peer task delegation through capability-based Agent Cards.
A2A in 2026
A2A matured quickly after Google announced it on April 9, 2025, and the Linux Foundation became its home on June 23, 2025. Version 1.0, the first stable specification, followed on March 12, 2026, with signed Agent Cards and multi-tenancy. At the one-year mark on April 9, 2026, the foundation reported more than 150 supporting organizations. It also reported that Microsoft integrated A2A into Azure AI Foundry and Copilot Studio, and that AWS added support through Amazon Bedrock AgentCore Runtime. The foundation named production use in supply chain, financial services, insurance, and IT operations. On August 17, 2026, A2A joined the AAIF as a hosted project, so both protocols now share one foundation.
The Agent Payments Protocol (AP2) for agent-led payments launched in September 2025 with more than 60 organizations and is now stewarded by the FIDO Alliance.
Which protocol to build first
For an enterprise integration program, build MCP first. Inside one organization, a single orchestrating agent that calls governed tools covers most 2026 use cases. A2A becomes necessary when independent agents, owned by different teams or vendors, need to delegate work to one another. The boundary test is simple: connecting an agent to a system calls for MCP, and connecting an agent to another agent’s judgment calls for A2A. Adding A2A before two independent agents exist gives security a second protocol to govern while the use cases need only MCP.
Buying or building an MCP gateway: Four paths
Four paths lead to a working MCP gateway, and each suits a different organization.
| Path | Best for | Main cost | What you own |
|---|---|---|---|
| Buy a commercial gateway | Teams with servers already in production and no spare platform capacity | License fees and lock-in to one vendor | Policy definitions and accountability for agent actions |
| Run an open-source gateway | Teams that want no license fees or vendor lock-in | Patching and on-call duty | The deployment and its uptime |
| Extend the infrastructure you run | Strong platform teams that avoid new vendors | Integration engineering | The links from your API gateway to your identity and policy services |
| Build a thin gateway of your own | Regulated firms whose examiners set the audit format | Build and upkeep effort | Every field of the audit record and the code that writes it |
A commercial MCP gateway reaches governance fastest. Judge each product on its identity model and on whether it governs servers outside its own catalog. The third path works because an existing API gateway, once connected to your identity and policy services, covers most of the four duties. The 2026-07-28 routing headers make MCP traffic legible to that stack. For a team that already runs an API layer, the fourth path is ordinary engineering.
Whichever path you choose, own the architecture, with identity, registry, policy, and audit as layers you can replace one at a time. Before signing, check that every candidate exports complete audit records in your format and sees servers installed outside it. A purchased gateway leaves accountability for agent actions with you, so the contract should guarantee your reviewers’ audit access.
Frequently asked questions
What is an MCP server, and how does it differ from an API?
An MCP server wraps one system and exposes selected capabilities as tools and resources that AI agents can call. A conventional API serves code that developers write and review in advance. An MCP server serves a model that picks tools at runtime, so it needs curated tools and per-call audit records.
How does MCP authorization work?
MCP authorization is an optional framework for HTTP transports, built on the OAuth 2.1 draft. The MCP server acts as an OAuth resource server and advertises the authorization server that issues its tokens. The client gets a token from that authorization server and sends it with every request. The server accepts only tokens issued for it as the audience. Scopes in the token can limit which tools a client sees, and a server can ask for a broader scope through step-up authorization. The Enterprise-Managed Authorization extension adds single sign-on through the corporate identity provider.
What changed in the 2026-07-28 MCP specification?
The 2026-07-28 revision, final since July 28, 2026, made MCP stateless by removing the initialization handshake and protocol sessions. Any server instance behind a load balancer can now answer any request. The revision also added routing headers for gateways, moved Tasks into an extension, tightened authorization, and set a deprecation policy. Deprecated features stay for at least 12 months, or 90 days when they pose an active security risk. Clients must now validate the issuer named in an authorization response, and client credentials stay bound to the authorization server that issued them. Client ID Metadata Documents become the preferred way to register clients, and Dynamic Client Registration is deprecated. Servers built on earlier revisions need a migration.
Who governs MCP now, and is it still an Anthropic project?
Anthropic created MCP and donated it on December 9, 2025, to the Agentic AI Foundation, a Linux Foundation fund. Anthropic co-founded the foundation with Block and OpenAI, and AWS, Bloomberg, Cloudflare, Google, and Microsoft joined as platinum members. MCP’s core maintainers now include engineers from Microsoft and Google.
How do we give AI agents write access to enterprise systems safely?
Treat write access as something each tool earns. Start every system at read-only, then move a tool to Propose, where a named person approves each agent draft. Allow direct writes only for bounded, reversible actions with hard limits, and only after red-teaming and a tested kill switch. Read access delivers value from the first day, and each tool’s write access opens only after it meets the promotion criteria.
Do we need an MCP gateway, or can agents connect to servers directly?
Direct connections work for a single server during a spike. Once two servers or two teams are involved, route agents through an MCP gateway. Otherwise each agent-server pair builds its own authentication and logging, and policy ends up split across servers. The gateway gives you one place for identity, registry, policy, and audit, whether you buy it or build it.
What is the difference between MCP and A2A, and which do we need first?
MCP connects an agent to tools and data, and A2A lets independent agents delegate work across teams or organizations. The Agentic AI Foundation hosts both protocols, which complement each other. Most organizations need MCP first, because one orchestrating agent that calls governed tools covers most current use cases. A2A comes in once independent agents must work together.
How long does it take to build a first enterprise MCP server?
Plan 2 to 4 weeks for a first governed server scoped as a spike. The spike covers one system, 3 to 5 read-only tools, authentication through your identity provider, and a log entry for every call. That timebox answers whether agent access creates enough value to justify the full stack. The registry and the policy engine follow as more servers and teams arrive.
Conclusion: The remaining work is governance
MCP settled its infrastructure questions in 2026 through neutral governance, a stateless specification, a deprecation policy, and enterprise sign-on. The organizations that gain most will build identity, registry, policy, and audit once. Every new agent then connects to a governed server from its first day.
SumatoSoft has delivered 350+ custom solutions for clients in 25+ countries since 2012, including IoT platforms and legacy system modernization. The company holds ISO 27001 and ISO 9001 certification. We build AI agents as production software under our Agentic Development Lifecycle (ADLC). Its red-teaming and AgentOps phases produce the evidence that the Write-Access Ladder asks for.
Last verified: October 20, 2026.
Scope your first governed MCP server
Bring your systems map, and our engineers will scope a first MCP server as a 2- to 4-week spike. The spike connects one system through curated read-only tools, with identity and audit in place from the first call. Your platform team keeps the reference architecture and owns it from then on. SumatoSoft is ISO 27001 certified and has delivered 350+ custom solutions in 14 years.
Download the Governed MCP Stack blueprint
The blueprint gives your platform team a checklist for each move, a planning table for the first server, the Write-Access Ladder with promotion criteria, and a readiness score.
Further reading
- For the wider rollout picture, read about the seven enterprise AI adoption risks; this playbook supplies the mechanism for two of them.
- To scope the first build, compare what a spike vs. a full PoC should deliver.
Let’s start
If you have any questions, email us info@sumatosoft.com
