MCP Implementation Roadmap: A Six-Phase Enterprise Rollout Plan for the Model Context Protocol

An MCP implementation roadmap for a company, as I would run it in October 2026, has six phases. Phase 0: pick two or three workflows and map what they touch. Phase 1: ship read-only MCP servers for internal knowledge, behind company sign-in. Phase 2: add authorisation, with per-tool scopes and no shared service tokens. Phase 3: allow writes, with approval, idempotency and an audit trail. Phase 4: govern a catalogue of approved servers. Phase 5: add tracing, evaluations and an incident runbook. Then scale out.

This is not the protocol's own roadmap of specification changes, which I covered in August. This one is about what to build, in what order, on revision 2026-07-28, still the current specification as of October 28, 2026. The order is mine. The requirements come from the specification and its security guidance, and I say where I go beyond them.

The MCP implementation roadmap at a glance

Source: my plan.

Phase 0: choose two or three workflows and map what they touch

Start with work, not servers: workflows with an owner and a result someone can check, such as answering questions from the staff handbook. For each, list the systems it reads, the data classes, every action it could take and the worst one. Note which clients people will use, because elicitation and enterprise sign-in both depend on client support.

Then mark three properties: private data, untrusted content such as customer email, and any route outward. A March post on the MCP blog about tool annotations uses Simon Willison's lethal trifecta for that combination, and notes that risk belongs to the session, not to one server. A workflow with all three needs Phase 3's controls before it ships.

Phase 1: read-only MCP servers behind company sign-in

Serve internal knowledge first, where a mistake costs least. Three decisions matter on day one.

• Remote, not local. The official local-server guidance prefers a remote server where one exists: no code runs on the laptop, and OAuth replaces a token in a config file. A token left in a local file is what the agent found and used in the PocketOS deletion in April.
• Read-only below the tool. The specification calls readOnlyHint, like every tool annotation, a hint. Give the server a credential that cannot write.
• Company sign-in. Run the OAuth flow against your identity provider, so each request carries the user's own token. Check that its metadata lists code_challenge_methods_supported, or compliant clients refuse to proceed, and that its tokens name your server as the audience.

This is the shape of the Verifiable AI Analyst, a governed analyst I built as a sovereign-data proof of concept for a Saudi digital-services company. Its stack includes MCP and IBM ContextForge. The only thing the model can reach is a registry of typed capabilities, executed under PostgreSQL's native row-level security, with sensitive columns masked in governed views, through a read-only role that cannot bypass either. There is no raw-SQL tool. An injected prompt can change what the model asks for, not what the role may read.

Phase 2: MCP authorisation with your identity provider

Authorisation is optional in MCP. An HTTP server that adopts it acts as an OAuth 2.1 resource server, publishes Protected Resource Metadata and rejects tokens issued for anything else. It must not forward a client's token upstream, which the specification calls token passthrough. On top of that floor:

• Scopes per tool. Challenge for the write scope only when a write is attempted: the server answers 403 with insufficient_scope and the scopes needed, and the client steps up. The security guidance lists wildcard scopes among its common mistakes.
• The identity provider decides. Enterprise-Managed Authorization, a stable extension since June 18, has the company identity provider check group and role policy, then issue an ID-JAG that the client exchanges for the MCP server's token. Okta was the first supported provider, and client support varies.
• Known clients and jobs. Pre-registered clients come first in the specification's priority order, so that list doubles as your approved clients. A scheduled agent should use the OAuth Client Credentials extension, not a pasted secret.

Tool lists may now vary with the authorisation on the request. In the Verifiable AI Analyst, a per-user permissioned manifest means a capability the user is not entitled to does not exist for that turn. Hiding a tool is still not authorisation, so check every call.

Phase 3: write actions with approval, idempotency and an audit trail

The tools specification says a human should be able to deny any tool call, but that is client behaviour, and clients differ. As I argued in my post on secure agents, approval must arrive through a route the agent cannot write to, so I would enforce it on the server.

Under the 2026-07-28 Multi Round-Trip Requests pattern, a tool returns an input_required result carrying an elicitation request, and the client retries with the person's answer. Form mode suits routine confirmations and must never collect passwords, tokens or payment credentials. For a payment or a deletion, my reading is to use URL mode: the person confirms on a page your server controls, after signing in, so neither client nor model can produce the yes.

The specification treats the requestState that comes back on a retry as attacker-controlled: protect it with an HMAC or AEAD, bind it to the user, an expiry and the request, and enforce single use for one-time actions. Since a dropped stream or an MRTR retry arrives with a new JSON-RPC id, that id cannot be your idempotency key. Put one in the arguments, or commit against a handle from a prepare step.

MerlinX, the agentic platform whose core I designed and directed at DXWand, has two rules I would copy into any MCP write tool. The model cannot write a price: it points at a cell in the customer's data, and code renders the number. And a retry returns the same record, so a customer never gets a duplicate. Record each write with its user, tool, arguments, approval and result, where the agent cannot edit it. MCP Apps, now a stable extension, can draw an approval form from the tool result.

Phase 4: a governed catalogue of approved MCP servers

By now people will want more servers, and will not ask first. The official local-server guidance recommends an allowlist of vetted servers with pinned versions, an inventory of client configurations, and central deployment wherever local access is not needed.

The official MCP Registry is not that allowlist. As of October 2026 it is still in preview, as it has been since September 2025. It lists public servers only, leaves security scanning to package registries and aggregators, and its moderation policy says consumers "should assume minimal-to-no moderation". Its OpenAPI specification is the useful part: a private registry can implement it and serve your list to existing clients. IBM ContextForge, which calls itself an open-source registry and proxy, is one product in that space.

Each entry needs an owner, a digest pin, its source repository and its expected network destinations. Last week, LiteLLM's own pipeline built a malicious release from a lookalike fork and signed it; the build provenance named the fork, as Socket pointed out on October 21. A signature says who built an artifact, not from what. Treat a changed tool description as a new version, because the model reads descriptions as instructions.

Phase 5: observability, evaluations and incident response

The 2026-07-28 revision reserves traceparent, tracestate and baggage in a request's _meta for OpenTelemetry, so one trace can follow a call from client to gateway to server to database. Give each workflow an evaluation set: real tasks, expected tool calls, planted instructions and requests the user may not make. Run it before any model, prompt, tool or server change. Then rehearse: disable a server, revoke a scope, rotate its credentials and time each step.

Scaling an MCP implementation: stateless servers and gateways

Scaling comes last because 2026-07-28 made it the easy part. With no handshake and no Mcp-Session-Id, any request can land on any instance behind a round-robin load balancer. Cross-call state becomes a handle the server mints, and the security guidance is plain that holding a handle is not authentication: bind it to the user it was issued to, and check the caller on every call.

The Mcp-Method and Mcp-Name headers let a gateway apply per-tool policy without parsing JSON, and servers must reject requests whose headers and body disagree. Mark per-user lists cacheScope: "private", or a shared cache can show one user's tools to another.

As I read the specification, a gateway that federates servers needs its own credentials for each, because forwarding the user's token is the passthrough it forbids. A secret that never enters the model's context cannot be repeated by the model; it can still be misused through a tool that holds it. I would run that gateway the way the LiteLLM incident argues: pinned by digest, restricted egress, short-lived credentials.

The first deliverable of this MCP rollout is a spreadsheet with no MCP in it. It will not make the launch slide, and it is the first document the incident review will ask for.

Sources

• MCP specification 2026-07-28, its changelog and release post, July 28, 2026
• Authorization, its Security Considerations and Client Registration, Elicitation, Multi Round-Trip Requests, Tools and Streamable HTTP, revision 2026-07-28
• Security Best Practices and Local Server Security
• Enterprise-Managed Authorization, June 18, 2026; extensions overview and OAuth Client Credentials
• Tool Annotations as Risk Vocabulary, March 16, 2026
• The MCP Registry and moderation policy; registry preview announcement, September 8, 2025
• IBM ContextForge repository
• LiteLLM attack chain, October 23, 2026; Socket, October 21, 2026
• Railway, April 29, 2026

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on agentic AI, enterprise integration, and governed data access.