Anthropic introduces the Model Context Protocol

Source record: an open protocol for connected context

On November 25, 2024, Anthropic introduced the Model Context Protocol as an open standard for connecting AI applications with data sources, business tools, and development environments. The announcement described three launch components: a specification and SDKs, local MCP server support in Claude Desktop, and an open-source repository of MCP servers. It also named pre-built servers for systems including Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer. The release frames MCP as a common connection layer that replaces separate custom integrations with a shared client-server protocol.

Engineering guidance: model the client-server boundary

An MCP design starts with a precise inventory of clients, servers, transports, tools, resources, prompts, identities, and data classes. Each server should have an owner, version, purpose, input schema, output schema, and network destination. Each client connection should record its authenticated principal, allowed server list, granted scopes, and session lifetime. This inventory turns an abstract integration diagram into a reviewable system boundary. It also makes it possible to answer operational questions quickly: which client called a tool, which server received the request, what data crossed the connection, and which policy applied.

Tool contracts should be narrow and inspectable

Treat an MCP tool as an API contract rather than an extension of a conversational prompt. Define input types, permitted value ranges, response shape, error categories, timeout behavior, and side-effect class before a client can invoke it. A read-only document lookup and a state-changing ticket update deserve different scopes, approval paths, and audit fields. Resource and prompt surfaces also need provenance: record the source, revision, classification, and retrieval time of material exposed to the model. Narrow contracts reduce accidental coupling and give evaluators a stable target for malformed-input, authorization, and retry tests.

Hypothetical implementation: an approved-document research client

Consider a hypothetical research client connected to one document server. The client accepts a question, a project identifier, and a requested output format. The server accepts only the project identifier after it verifies membership, then returns document excerpts with stable source identifiers and revisions. The client can summarize those excerpts into a draft briefing, while publishing, email, and record-update tools remain outside the connection. Every request receives a correlation identifier, and the final briefing carries the source identifiers used to assemble it. This example shows an MCP connection as a bounded research surface with explicit inputs, outputs, and ownership.

Authentication and authorization belong at every hop

Transport security and server authentication establish who is connected; authorization establishes which action that connection may perform. Apply authorization at the server for every tool or resource request, using the current principal, requested operation, target object, and relevant policy. Avoid translating a broad client session into unrestricted downstream credentials. Prefer short-lived, scoped credentials and server-side checks over client-side declarations of intent. For tools that initiate consequential work, require an explicit authorization record tied to the exact request payload and preserve the server result. This keeps technical connectivity, data access, and permission to act as separate reviewable decisions.

Evaluation and operational readiness

Validate an MCP integration with fixtures that cover authorized reads, denied reads, unavailable servers, malformed arguments, stale credentials, duplicate requests, and untrusted content returned by a tool. Capture server version, client version, declared tools, policy revision, request identifier, latency, result category, and retained evidence for each case. Run the same suite when a server image, SDK, transport, authentication method, or tool schema changes. Production readiness is demonstrated by reproducible behavior across the declared boundary: the expected resources are available, unavailable resources stay closed, failures remain visible, and operators can identify the owner responsible for remediation.

Connection lifecycle deserves the same discipline as API lifecycle. Define onboarding steps for a new server, including owner approval, schema review, credential provisioning, fixture setup, and an initial policy revision. Define offboarding steps that disable the client connection, revoke downstream credentials, remove the server from discovery, preserve required audit evidence, and verify that no alternate route still reaches the service. Test protocol upgrades with a compatibility matrix that records client version, server version, transport, authentication flow, and exposed capability set. This turns protocol evolution into a controlled change rather than a client-by-client compatibility surprise.

Publish a machine-readable capability snapshot at onboarding and after every approved change. Include server identity, supported protocol revision, tool and resource names, schemas, scope requirements, transport endpoints, and deprecation date where relevant. Compare snapshots in review so removed tools, broadened schemas, and changed transports are visible before clients receive them. This reduces configuration drift across teams that consume the same server.

Related capabilities

• MCP integration and interoperability