MCP for Enterprise Agents: Production Architecture

Model Context Protocol is an open standard published by Anthropic in late 2024. It defines a JSON-RPC 2.0 based communication layer between a host application (the environment running the AI model), an MCP client (the agent or orchestrator making requests), and one or more MCP servers (processes that expose tools and data sources).

The core primitives are straightforward. Tools are functions the model can call — think “run SQL query” or “fetch document by ID”. Resources are data the model can read — structured or unstructured content available via a URI scheme. Prompts are reusable instruction templates that MCP servers can expose. The host application negotiates capabilities with each server at session initialization, producing a manifest of available tools and resources that the model can reason about.

MCP has seen rapid adoption since its introduction. As of early 2026, it has surpassed 97 million monthly SDK downloads and is supported by every major AI vendor — Anthropic, OpenAI, Google, Microsoft, and AWS. For agents that need to interact with internal enterprise systems, MCP is quickly becoming the default integration pattern.

This post is not about getting started with MCP. If you need that, Anthropic’s official documentation covers it well. This is about what happens when you take a working single tenant MCP setup and try to run it in production for an enterprise with multiple tenants, strict compliance requirements, and a need to attribute costs per business unit.

The default MCP architecture makes three assumptions that hold in a developer sandbox but fail in enterprise production.

Each of these is solvable. The solutions require deliberate architectural decisions that you make before you scale to production, not after.

The core requirement for multitenant MCP is that every piece of server state — session context, tool inputs, tool outputs, cached data — must be scoped to a tenant at the point it is created, not filtered at the point it is accessed.

Namespace isolation. Assign every session a tenant ID at authentication time and bind it to the session object. Inject the tenant ID as a first-class parameter into every tool call, even tools that do not explicitly need it. This is belt and suspenders: you do not want a tool that “obviously” only returns the current tenant’s data to silently return another tenant’s data because of a caching bug.

Per-tenant tool sets. Different tenants often have different service agreements and should not see tools they do not have access to. Implement a tool registry that returns different tool manifests based on tenant ID at the capability negotiation phase. When the MCP client initializes a session and the server advertises its tools, the tenant should only see tools it is entitled to call. Do not rely on access control checks at call time as the only guard — if the tool is not in the manifest, it cannot be called by accident.

Session scoping. MCP sessions are long lived by design — the protocol is built around a persistent JSON-RPC channel, not request response HTTP. This means session state accumulates over time. Audit what each session stores: conversation history fragments, cached tool results, resolved resource references. The safest approach is to key every session store entry on {tenantId}:{sessionId}:{key} rather than {sessionId}:{key} alone.

For a deeper look at how this fits into the broader architecture of production agentic systems, see the guide on agentic AI production architecture.

OAuth 2.1 with PKCE is the right authentication model for production MCP servers. The MCP Authorization Specification standardizes this approach. Each agent authenticates with your identity provider using client credentials flow, receives a short-lived access token, and presents that token with every MCP session initialization. The key advantages over static API keys: automatic token expiry limits the blast radius of a compromised credential, centralized credential management at the identity provider, and auditability of every authentication event.

For environments with stronger cryptographic requirements, mutual TLS (mTLS) is supported alongside OAuth. Certificate-based authentication binds agent identity to a cryptographic key pair, making impersonation significantly harder than with bearer tokens. The operational overhead of certificate rotation is non-trivial, but for agents handling regulated data it is worth it.

Tool-level permission scoping is where most MCP deployments fall short. Even teams that implement session-level authentication often grant agents access to all tools on a given server. The principle of least privilege applies here as clearly as it does anywhere else in security engineering: an agent should be able to call exactly the tools its defined role requires and nothing more.

Implement a permission layer as middleware between the MCP client and the tool execution layer. The middleware intercepts every tool call, looks up the calling agent’s role in a permissions table, and allows or rejects the call before it reaches the tool implementation. The permissions table maps {agentRole}:{toolName} to allow/deny. Start with an allowlist model — deny everything by default, allow specific tools explicitly — rather than a denylist model that relies on you correctly enumerating every dangerous tool.

A practical way to define roles: create one role per agent type in your system. A research agent might have access to web search, document read, and database read tools. A write agent might additionally have document write and database write access. An admin agent might have access to configuration tools that no other role can call. Keep roles narrow. The temptation to create a single “agent” role that has access to everything is the single most common authorization mistake in production MCP deployments.

For a broader view of how authentication fits into enterprise AI systems architecture, the design decisions here connect directly to how you structure agent identity across the whole system.

Every MCP tool call should produce a structured log entry. The minimum fields are: tenant ID, agent ID, session ID, tool name, input hash, output hash, call latency in milliseconds, token cost (if applicable), and a timestamp. Each field has a reason.

Tenant ID and agent ID make it possible to answer “which agent from which tenant caused this incident” after the fact. Without both, post-incident investigation collapses into guesswork.

Call latency is your primary signal for tool performance degradation. Set an alert for p95 latency exceeding a threshold per tool — a slow tool is often the leading indicator of an underlying service problem before it produces errors.

Token cost at the call level enables cost attribution per agent and per tenant. Accumulate this in a separate analytics store rather than your operational log pipeline — log pipelines are optimized for high-volume event storage, not aggregation queries.

Alerts to configure: p95 tool call latency exceeding baseline by 2x; error rate per tool exceeding 1 percent over a 5 minute window; any tool call with a tenant ID that does not match the session’s authenticated tenant ID (this should be impossible — if it fires, it is a critical incident); total token spend per tenant exceeding a configured threshold per hour.

Token spend attribution in MCP-based systems requires instrumentation at the tool call boundary because the token cost is incurred at the LLM layer, not the MCP layer. MCP itself does not track token spend — the MCP server executes a function call, but the tokens are consumed by the model during the reasoning that produced the function call and during the processing of the function result.

The practical approach is a wrapper middleware on the MCP client that intercepts tool calls and pairs each one with the token counts from the model’s response object. The OpenAI API and the Anthropic API both return token counts in the response metadata. By logging the tool call event and the associated token counts together — keyed by agent ID and tenant ID — you build a per-call cost record that rolls up into per-agent and per tenant cost totals.

For SaaS products where you are billing tenants based on usage, this attribution layer is not optional — it is the billing system’s data source. Store cost records in an analytics database (Postgres, ClickHouse, or BigQuery depending on your scale) with tenant ID, agent ID, tool name, input token count, output token count, and timestamp.

Working through the enterprise concerns above is part of what agentic AI consulting looks like in practice — the architecture decisions made here shape the security and cost profile of the entire system.