MCP Server Patterns for Enterprise AI Agents

The Model Context Protocol gives AI agents a standardized interface to tools, prompts, and resources — but spec version 2025-11-25 introduced a mandatory authorization framework that fundamentally changes how enterprise teams should design their MCP server deployments. OAuth 2.1 with PKCE S256, RFC 9728 Protected Resource Metadata, RFC 8707 Resource Indicators, and an explicit ban on token passthrough together define a security posture that most tutorial coverage still glosses over.

The stakes are material. MCP servers sit at the intersection of language models and production data surfaces — databases, APIs, internal tooling. A misdesigned auth layer doesn't just introduce a compliance gap; it creates a confused-deputy attack surface where a malicious prompt can redirect tool calls and exfiltrate tokens through a legitimately-authorized agent. According to the spec's security section, the protocol intentionally grants "powerful capabilities through arbitrary data access and code execution paths" — and expects implementors to handle the security weight that comes with that.

This guide covers the 2025-11-25 spec's transport and auth requirements in engineering-grade detail, then maps four enterprise deployment topologies — single-tenant, multi-tenant row-isolated, federated gateway, and edge-cached read-only — against the spec's constraints. Every pattern includes its auth assignment, caching posture, and the trade-off that rules it in or out for a given deployment.

The MCP specification version 2025-11-25 is the current revision. It defines the wire format as JSON-RPC 2.0, UTF-8 encoded, with stateful connections and an explicit capability negotiation phase between client and server on every new session. Servers expose three primitive types to clients: Tools, Prompts, and Resources. Clients expose three primitive types to servers: Sampling, Roots, and Elicitation. This direction matters — Sampling, Roots, and Elicitation are CLIENT features, not server features. A common misconception in enterprise architectures is treating them as server capabilities, which produces incorrect access-control reasoning.

The spec defines exactly two standard transports. stdio is the local process transport — the MCP host manages the server process and communicates over standard input and output. It is the appropriate transport for local agent tooling and development workflows, and credentials SHOULD be read from the environment rather than managed via OAuth. Streamable HTTP is the remote transport, introduced in the 2025-11-25 revision to replace the earlier HTTP+SSE (Server-Sent Events) transport from the 2024-11-05 revision. HTTP+SSE is now deprecated — backward compatibility is maintained through the MCP-Protocol-Version header mechanism, but new servers should not implement it. Clients that send an HTTP request without the version header are assumed to be speaking the 2025-03-26 protocol, not 2025-11-25.

Streamable HTTP introduces session management via the MCP-Session-Id header. Servers MAY assign a session ID in the InitializeResult response; clients MUST echo it on subsequent requests. Servers MAY terminate a session at any time — the client will receive an HTTP 404 and should start a fresh session. For clean shutdown, clients SHOULD send an HTTP DELETE to the session endpoint. DNS-rebinding protection requires servers to validate the Origin header on all incoming connections, returning HTTP 403 on invalid origins, and to bind to 127.0.0.1 rather than 0.0.0.0 when running locally.

Authorization for remote MCP servers is built on OAuth 2.1 (draft-ietf-oauth-v2-1-13), layered with four additional RFCs the spec references by name. This is not optional architecture guidance — the MCP spec's authorization section defines these as MUST requirements for HTTP transport implementations that support authorization.

The PKCE requirement deserves specific attention. MCP clients MUST use PKCE with the S256 code challenge method. Before initiating an authorization request, the client MUST verify PKCE support by inspecting the code_challenge_methods_supported field in the authorization server metadata document. If that field is absent or does not include S256, the client MUST refuse to proceed. The plain method is only permitted when S256 is not technically possible — in practice, all modern server environments support it. The plain fallback is an implementation escape hatch, not a design choice.

The supporting RFC ladder specifies four additional requirements: authorization server discovery via RFC 8414 Authorization Server Metadata; resource discovery via RFC 9728 Protected Resource Metadata (covered in section 03); audience-binding of tokens via RFC 8707 Resource Indicators (section 04); and dynamic client registration via RFC 7591, which is a MAY for servers but directly enables zero-configuration client onboarding for enterprise agent fleets. The spec also references draft-ietf-oauth-client-id-metadata-document-00 for client identity, which enables lightweight client verification without a dedicated registration endpoint.

The most underimplemented requirement in current MCP deployments is RFC 9728 OAuth 2.0 Protected Resource Metadata. The spec is unambiguous: "MCP servers MUST implement OAuth 2.0 Protected Resource Metadata, and MCP clients MUST use it for authorization-server discovery." The MCP-specific discovery flow uses the WWW-Authenticatechallenge on the server's well-known endpoint — clients inspect the challenge to find the authorization server URI, then fetch RFC 8414 Authorization Server Metadata from that URI.

The practical impact: clients can bootstrap authorization for any compliant MCP server without out-of-band configuration. The server self-describes which authorization server governs it via its well-known document. For enterprise deployments, this matters because it decouples client configuration from server deployment — adding a new internal MCP server doesn't require updating every agent client's config file.

The spec's security section notes that authorization servers fetching metadata documents SHOULD consider Server-Side Request Forgery (SSRF) risks — a subtlety that matters when the gateway pattern (section 06) aggregates PRM documents from multiple internal MCP servers. Enterprise implementations should validate that well-known URIs resolve to internally-controlled hosts before fetching.

Even with RFC 9728 in place, a token issued for one MCP server can theoretically be reused at another server that trusts the same authorization server — if the token does not carry an explicit audience claim binding it to the intended resource. RFC 8707 Resource Indicators closes that gap. MCP clients MUST include a resource parameter on both the authorization request and the token request. The value is the canonical URI of the MCP server — for example, https://mcp.internal.example.com/analytics.

Authorization servers that support RFC 8707 embed the resource URI as the aud(audience) claim in the issued access token. The MCP server MUST validate that the token's audience matches its own canonical URI on every request. A token issued formcp.internal.example.com/analytics will be rejected by mcp.internal.example.com/crmbecause the audience doesn't match — even if both servers share the same authorization server.

For multi-tenant deployments (pattern 2 in section 06), this mechanism extends naturally: the resource parameter can include a tenant-specific path segment, and the authorization server issues tenant-scoped tokens. Server-side validation of the audience claim then enforces tenant isolation at the token level before any row-level filtering is applied — providing defense in depth without additional application logic.

The MCP spec's security section states it plainly: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server." A companion requirement governs the upstream direction: "If the MCP server makes requests to upstream APIs, it may act as an OAuth client to them. The access token used at the upstream API is a separate token, issued by the upstream authorization server. The MCP server MUST NOT pass through the token it received from the MCP client."

The security rationale is the confused-deputy principle at the token level. If an MCP server proxies the inbound client token to an upstream API, the upstream API receives a token whose permissions it cannot independently validate — it is trusting the MCP server's judgment about the client's identity rather than the authorization server's. A compromised MCP server, or a server tricked by a prompt injection, can then make requests to upstream APIs with a client's full permission scope, in ways the client never authorized.

The correct pattern is token exchange: the MCP server authenticates the inbound client token against its own authorization server, extracts the client identity and requested scope, then independently obtains a new short-lived token from the upstream API's authorization server scoped to the specific operation being performed. This token exchange can use the OAuth 2.0 Token Exchange specification (RFC 8693) or service-to-service credentials managed separately. The upstream token's scope SHOULD be the minimum required for the tool call being executed — not the client's full scope.

Most published MCP guides describe a single-tenant tutorial and stop. Real enterprise estates need to reason across four deployment archetypes, each with different auth assignments, caching postures, and failure modes. The matrix below maps the four patterns against the spec requirements established in sections 01-05. For the engineering-level enterprise agent platform reference architecture, including ingress, orchestration, and observability layers, see our companion post.

The pattern selection is not arbitrary — each emerges from a different combination of tenancy model, regulatory posture, and throughput requirement. Pattern 1 is the correct starting point for any new internal MCP server and can be extended to pattern 2 or 3 if the tenancy or scale requirements evolve. Teams building their first MCP infrastructure should resist the temptation to start with a federated gateway — the operational complexity is significant and the audience for central audit is usually the security team, not the end-user engineers. For guidance on how to architect and build this infrastructure in a production environment, our web development team has direct experience deploying patterns 1-3 for enterprise clients.

Pattern 4 is specifically suited for scenarios where tool-discovery traffic significantly outweighs tool-invocation traffic — common in large agent fleets where many agents enumerate the available tool surface before deciding which server to invoke. The read-only nature of tools/list makes it safe to cache, but the cache TTL must be chosen conservatively and wired to the tools/list_changed notification to avoid serving stale tool definitions to agents.

Our MCP server security best practices guide covers the full hardening surface for all four patterns, including session-ID format recommendations (<user_id>:<session_id> binding), input validation on tool arguments, and output sanitization before sending results to the LLM context.

The confused-deputy problem in MCP occurs when a proxy server acts as both a relying party for inbound MCP clients and an OAuth client to an upstream authorization server. The spec documents the specific attack: a proxy with a static client ID at the upstream AS plus dynamic registration for inbound MCP clients plus cached consent cookies enables an attacker to skip user consent by replaying a session. The fix is not a single control — it requires two specific mitigations working together.

The MCP transport history is short but consequential. The original spec (2024-11-05) defined HTTP+SSE as the remote transport: a standard HTTP POST endpoint for client-to-server messages and a separate Server-Sent Events endpoint for server-to-client notifications. The 2025-03-26 revision replaced HTTP+SSE with Streamable HTTP, which unifies the two endpoints into a single connection that supports bidirectional streaming. The 2025-11-25 revision formalized Streamable HTTP as the only supported remote transport and officially deprecated HTTP+SSE — though it remains backward-compatible via the protocol-version header.

The practical consequence: any new MCP server built today should use Streamable HTTP. Existing servers that implement HTTP+SSE continue to function for clients that send the legacy protocol version, but teams should plan migration. The enterprise patterns in section 06 all assume Streamable HTTP — pattern 4's edge-caching model in particular depends on the unified endpoint architecture that Streamable HTTP provides.

This timeline matters for enterprise procurement teams evaluating MCP vendors and third-party server implementations. A server that still advertises HTTP+SSE as its primary transport is running on a deprecated foundation — either the vendor hasn't updated to the current spec, or it's targeting backward compatibility with a specific older client. Neither is a disqualifying condition, but both warrant a question about the vendor's spec-tracking cadence. For the full picture of how MCP adoption is evolving at the enterprise level, see our Q3 2026 MCP adoption forecast.

The spec's security best practices section treats scope minimization as a first-class concern, not an afterthought. The recommended model is progressive least-privilege: issue a minimal initial scope set (for example, mcp:tools-basic) on first authorization, then use incremental WWW-Authenticate scope challenges to request elevation only when a specific operation requires it. Servers SHOULD avoid publishing the full list of available scopes in their scopes_supportedmetadata — this limits the information available to an attacker enumerating the server's attack surface.

Rate limiting on tool invocations is a separate but related requirement. The spec explicitly places server-side rate limiting in the security category: servers MUST implement access controls and rate-limit tool invocations. For the federated gateway pattern, the gateway is the natural enforcement point for cross-server rate limits — individual downstream servers can enforce per-server limits while the gateway enforces aggregate limits per client identity. For pattern 2 (multi-tenant), per-tenant rate limits at the storage access layer prevent one tenant's agent workload from consuming capacity that degrades other tenants.

Tool input validation is the third control in this tier. Servers MUST validate all tool inputs against their declared JSON Schema before executing the tool logic. This is not just a correctness concern — it is a security boundary. An agent that has been injected with a malicious prompt can craft tool arguments that, if not validated, trigger unexpected behavior in the downstream API the MCP server wraps. Clients, for their part, SHOULD prompt for user confirmation on sensitive tool operations and SHOULD display tool inputs to the user before sending them to the server.

For teams building out their first enterprise MCP deployment, our MCP server anti-patterns guide catalogs the specific design mistakes we encounter most often — from overly broad initial scopes to missing input validation on tool arguments. Our AI transformation service includes architecture review for MCP deployments at this layer, specifically the auth, scope, and rate-limiting posture.