MCP infrastructure is everything required to expose and operate Model Context Protocol capabilities: the client, transport, server, tools, authorization, policy, credentials, backend execution, state, and telemetry. An MCP server is one component, not the complete production system.
A demo can stop after tools/list and tools/call. Production has to answer who called, what they may access, whether a write can repeat, and how an operator reconstructs the effect.
What MCP standardizes
MCP defines a JSON-RPC protocol for clients and servers to negotiate capabilities and exchange messages. Servers can expose:
- tools that a model may select and invoke;
- resources that clients can read or subscribe to;
- reusable prompts that clients may present to users or models.
The MCP tools specification defines discovery through tools/list, invocation through tools/call, input and optional output schemas, structured content, and tool-list change notifications.
The protocol carries these contracts. It does not decide whether a tool is safe, useful, or authorized for the current tenant.
The infrastructure around the protocol
flowchart LR
C[MCP client] --> T[stdio or Streamable HTTP]
T --> S[MCP server]
S --> A[Authentication and policy]
A --> X[Credential and execution layer]
X --> B[Backend APIs and data]
S --> R[Session and operation state]
S --> O[Logs, traces, and evaluations]
X --> O
B --> O
Each boundary has a separate job.
Client and transport
The client decides which server capabilities it exposes to the model and how a user approves calls. Local servers commonly use stdio. Remote servers use Streamable HTTP. The MCP transport specification also requires HTTP servers to validate Origin headers to help prevent DNS rebinding attacks.
Transport security protects the connection. It does not authorize a database row or cloud resource.
Server and tool registry
The server implements MCP lifecycle messages and publishes tools, resources, or prompts. The tool registry contains names, descriptions, schemas, and annotations. Clients must treat tool annotations as untrusted unless the server itself is trusted.
Tool definitions should match tasks rather than internal endpoint names. The MCP tool design guide explains how to reduce overlapping choices and return results a model can use.
Authentication and policy
Authentication identifies the caller or represented user. Policy decides which tools, resources, tenants, and actions that identity may access. For HTTP transports, the MCP authorization specification defines an OAuth-based flow with protected-resource discovery, authorization-server metadata, resource indicators, bearer tokens, PKCE, and audience validation.
Authorization must continue in the backend. A gateway can hide delete_project, but the underlying API should still reject an unauthorized deletion.
Credential and execution layer
The MCP server may need a separate token for an upstream API. The current authorization specification explicitly forbids passing the client's MCP access token through to an upstream service. The server should exchange or retrieve a separate credential intended for that backend.
Keep those credentials outside tool arguments and results. The model needs the outcome, not the secret used to obtain it. The MCP key security guide follows the credential path in detail.
Backend, state, and recovery
The backend owns business authorization, data integrity, and external effects. Session state can record which server connection is active. Operation state records whether a specific write started, completed, failed, or needs reconciliation.
Do not use chat history as the only operation ledger. A summarized tool result is not enough to decide whether a timed-out payment or deployment should repeat.
Telemetry and evaluations
One trace should connect the user request, model choice, tool call, policy decision, backend request, and final effect. Record stable tenant, user, agent, session, tool-call, and operation IDs. Exclude tokens, credentials, and sensitive payloads.
An evaluation suite should include tool-selection collisions, invalid inputs, forbidden resources, approval paths, retries, and interrupted responses. A tool that works in isolation can still fail when twenty similar tools are visible.
Review one complete tool path
Choose the MCP tool with the broadest effect. Follow it past the handler into identity, policy, credentials, backend state, and telemetry. If any step relies on a prompt instruction or a human reading logs, mark it as missing infrastructure.
The prompt below performs that trace without calling the tool.