Production MCP Server Architecture and Security

Production MCP Server Architecture and Security

A demo MCP server can run on a laptop, call one API, and return a cheerful answer. Production adds the less glamorous questions: What if a request lands on another instance? Who is the user behind it? What happens when the downstream API slows down? Can a support engineer trace a failed tool call without seeing someone’s access token?

The encouraging news is that the current MCP protocol is designed to fit ordinary HTTP infrastructure. The hard part is the same as any production service: make identity, permission checks, state, failure handling, and operations explicit.

Start with the service boundary

A production host connects to a remote MCP endpoint over Streamable HTTP. A typical path is: AI host → TLS / edge gateway → MCP application → domain services and data sources. The host controls its user experience and connection; your MCP application exposes a focused set of tools, resources, and prompts. Put business rules and data access in services that can enforce them consistently, rather than trusting a tool description to do so.

The 2026-07-28 revision introduces a stateless protocol lifecycle: it removes the protocol-level initialize handshake and Mcp-Session-Id. Requests carry their protocol version and client metadata, and a server/discover exchange can advertise supported revisions and capabilities. A request can therefore reach any healthy instance behind a normal load balancer—no sticky routing or protocol session store is required.

Stateless protocol does not mean every product is stateless. If a workflow needs durable state, store it in an application database and pass an opaque, authorization-checked handle between calls. Don’t rely on an in-memory instance variable or the old protocol session header to keep a user’s workflow alive.

Keep the trust boundaries visible

For a protected remote server, use the MCP authorization model with an external authorization server. The MCP service acts as a resource server: it validates tokens intended for itself, then checks permissions for the requested tool and data. Authentication answers who is calling; authorization answers whether that identity may perform this action on this record in this tenant.

Never trust clientInfo, user IDs, tenant IDs, or permissions sent as ordinary tool arguments as proof of identity. Bind the authenticated principal to server-side authorization checks. Use TLS, validate issuer, audience/resource and expiry, request the least privilege needed, and do not pass a token for your MCP service through to some other API. Obtain downstream credentials for that downstream resource.

Treat a tool request as untrusted input even when it passed schema validation. Apply limits to string sizes, list lengths, time and output size. Reject unexpected file paths and URLs. If a tool fetches user-provided URLs, block private and link-local IP ranges, re-check DNS resolution after redirects, restrict egress, and use a vetted URL-fetching component to reduce SSRF risk.

For HTTP endpoints, validate Host and Origin against the deployment’s intended hosts; use the SDK middleware or framework protections where available. A public server should not silently accept connections from arbitrary browser origins. Keep authorization on every request and inside every consequential tool handler, not just at the load balancer.

Put a gateway in the right role

An edge gateway can terminate TLS, enforce network-level policy, apply coarse rate limits, and route requests. On the current Streamable HTTP protocol, Mcp-Method and (for named operations) Mcp-Name headers give gateways a way to inspect the operation without parsing a JSON body. The MCP endpoint still needs to validate that the routing headers agree with the request body and apply its own business authorization.

The gateway is not a substitute for user-level access checks. Avoid treating a client-supplied Mcp-Name or other metadata as authenticated identity. Use a gateway-to-service identity of its own, prevent direct access around the gateway if it is part of your threat model, and make trusted-proxy behavior explicit.

Make scale and state boring

For ordinary tool calls, keep request handling short and bounded. Stateless protocol requests can be distributed across instances, and the SDK can handle protocol version negotiation and pagination. Store shared configuration and durable business state in suitable services. Apply resource limits and connection pools; graceful shutdown should stop accepting traffic and let in-flight requests finish or cancel cleanly.

For long-running work, don’t keep an HTTP request open indefinitely. Where the client and server support the io.modelcontextprotocol/tasks extension, a tool can create a task handle that the client polls or cancels. Task storage must be durable enough for your recovery needs, and a task ID must be unguessable and checked against the authenticated caller. A task is not a permission bypass.

Cache tool catalogs and resource reads only when their data is safe to reuse. The current protocol includes cache ttlMs and cacheScope hints. A per-user or per-tenant result must not enter a cross-user cache. Key caches by every security-relevant dimension, expire entries when policy or permissions change, and avoid caching sensitive tool results unless you have a clear reason and isolation strategy.

Build resilience around the work

Never automatically retry a purchase, email, deletion, or other side effect just because a network response was lost. The server may have completed the action even if the client timed out. Make writes idempotent where possible and return an operation ID that lets the host check what happened.

Observe a tool call without leaking secrets

Track request rate, errors, latency percentiles, active work, timeouts, rejected authorization, and downstream failures. Add structured fields for tool name, deployment version, request ID, and a pseudonymous tenant or principal key where policy permits. The current spec documents W3C trace context propagation in _meta, so traces can connect host, gateway, MCP handler, and dependency calls.

Logs should explain outcomes, not become a transcript of private data. Redact bearer tokens, authorization headers, passwords, and secret arguments. Minimize recording of prompts, tool inputs, and outputs; set retention deliberately and restrict who can search them. Alert on abnormal tool-call volume, repeated authorization failures, unexpected egress, and unusual rates of destructive actions.

Use an MCP-aware security checklist

• Tools: expose only what users need; give tools narrow descriptions and input schemas; authorize every call inside the handler.
• OAuth: validate the token for this MCP resource; don’t accept tokens for a different audience or forward them downstream.
• Browser and network: validate host/origin; restrict outbound destinations; defend against SSRF and DNS rebinding.
• Content: treat tool arguments, server results, resources, and prompts as untrusted; constrain content passed to the model.
• User control: make consequential actions understandable and request explicit approval in the host’s interface.
• Operations: rate-limit, bound resource use, rotate secrets, monitor, patch dependencies, and maintain an incident plan.

The security guide also warns against confused-deputy behavior and trusting tool annotations as authorization. An annotation like “read-only” may help a host present an action, but the server must enforce what actually happens.

Roll it out in steps

Start with one narrow service and read-only tools. Add OAuth and enforce the real principal in one tool. Test wrong audience, missing scopes, another tenant’s record, malformed input, oversized output, timeout and duplicate call cases. Then add a small write action with clear approval and idempotency. Load-test discovery, tool listing, and the heaviest downstream operation; verify traces and dashboards do not contain secrets. Roll out behind a feature flag or canary, and keep a way to disable a risky tool quickly.

MCP gives your app a shared way to communicate with tools and context providers. Production readiness still comes from your service boundaries, identity checks, safe failure behavior, and operational discipline. Build those deliberately and the protocol can scale with the rest of your application.

Further reading

• MCP Specification (2026-07-28)
• MCP Security Best Practices
• MCP Authorization specification (2026-07-28)
• MCP Specification: protocol change overview
• MCP Tasks extension