MCP launch article: turning model connectivity into an open protocol

Original source

Anthropic, 2024-11-25: Introducing the Model Context Protocol. This guide treats it as a historical launch article; current wire-level details come from the latest MCP specification.

This is an original learning guide, not a reproduction. Copyright and the complete article remain with the original source.

Current protocol verification scope

The “current protocol supplement” was checked against the MCP 2026-07-28 specification and the official release post, The 2026-07-28 Specification, on 2026-08-09. Historical launch claims and current wire behavior are kept separate.

What you should be able to do after this guide

By the end, you should be able to:

1. Draw the boundaries among the model, Host, Client, Server, and underlying business system and explain each responsibility.
2. Distinguish Resources, Prompts, and Tools by data shape, typical controller, and possible side effects.
3. Trace a current MCP operation from capability discovery through context retrieval, tool invocation, and result handling.
4. Explain how MCP and model tool calling occupy different layers rather than competing as alternative syntaxes.
5. Explain why protocol compatibility does not imply authorization, safety, correctness, or trustworthy data, and identify the gates an implementation still owns.
6. State the historical contribution of the 2024 article and why the legacy stateful initialize lifecycle must not be taught as the current 2026-07-28 protocol.

The launch problem: why connection work grows out of control

Suppose three AI applications—a chat assistant, an IDE, and a data-analysis agent—all need GitHub, Postgres, Google Drive, and an internal business system. If every application writes a bespoke integration for every system, the work approaches number of applications × number of systems:

• Every integration redefines capability descriptions, parameters, and result formats.
• Authentication, authorization, and error handling drift across implementations.
• A service field change must be repaired in several clients.
• Model context, read-only data, and side-effecting operations are often mixed behind an unclear interface.

The 2024 launch article reframed this as an open-protocol problem. Data and capability providers implement MCP Servers; AI applications implement MCP Clients; both communicate through a common protocol. The launch also included a specification and SDKs, local Claude Desktop support, and an open-source collection of example Servers.

Its historical importance is not simply that Anthropic offered another tool-call format. It attempted to move external connectivity from proprietary adapters in one product to an ecosystem boundary that different clients and servers can implement.

Separate the five roles first

Role	Responsibility	Responsibility it must not silently take over
User	State goals, select context, approve sensitive operations, and accept results	The user must not be assumed to consent to all data sharing and execution
Model	Generate responses or propose tool calls from provided context	It should not directly possess network, file, or production credentials
Host	Own UI, model calls, MCP Clients, permission UX, and overall policy	It must not treat a Server’s claims as trusted facts and skip gates
Client	Act as the connector inside a Host for one Server, sending requests and receiving results	It does not decide whether the business system ultimately authorizes an operation
Server	Wrap an external system as protocol capabilities such as Resources, Prompts, and Tools	It does not automatically become the security authority for every underlying datum and action

One Host may create multiple Clients, each connected to a corresponding Server. A Server may wrap local files, a Git repository, a database, or a remote SaaS API. The model normally sees only the capability descriptions and results that the Host chooses to place in context; the model does not itself “speak MCP.”

flowchart LR
    U["User: goals, selection, and approval"] --> H["Host: UI, model, policy, and permissions"]
    H --> M["LLM: understand context and propose calls"]
    H --> C1["MCP Client A"]
    H --> C2["MCP Client B"]
    C1 <--> S1["MCP Server: code repository"]
    C2 <--> S2["MCP Server: business system"]
    S1 <--> D1["Git / Files"]
    S2 <--> D2["Database / API"]

The critical boundary is: the model proposes an action; the Host decides whether it may proceed and sends it through a Client; the Server then executes or rejects it according to caller identity and business policy.

The three core capability types exposed by a Server

Under the 2026-07-28 specification, Servers may expose Resources, Prompts, and Tools. They are not interchangeable names for the same JSON container.

Resources: context and data that can be read

A Resource has a unique URI and may contain text or binary content: files, database schemas, project documentation, or application-specific information. A Client may call resources/list and then resources/read for a selected URI, or use parameterized Resource Templates.

The specification describes Resources as application-driven. The Host decides how to display, search, filter, or automatically include them in context. A model may help select them, but the protocol does not impose one UI pattern.

A Resource answers, “What data can become context, and how is it read?” Reading may still disclose sensitive information, so “read-only” does not mean “risk-free.”

Prompts: reusable message templates supplied by a Server

A Prompt is a named structured message template with a description and optional arguments. A Client discovers it with prompts/list and retrieves a concrete, parameterized message with prompts/get.

The specification describes Prompts as user-controlled: the intended pattern is for the user to choose when to invoke one, perhaps through a UI command. “User-controlled” describes who selects it, not who authored it. The template still comes from the Server and remains external input that the Host must treat accordingly.

A Prompt answers, “Is there a reusable interaction entry point or workflow template?” It does not by itself execute an external action.

Tools: functions that a model may propose invoking

A Tool has a name, description, input schema, and optionally an output schema. A Client obtains the catalog through tools/list and invokes a selected tool with tools/call. The Server can return text, structured content, resource links, or errors.

The specification describes Tools as model-controlled, meaning that a model can discover and propose calls automatically from context. It does not mean the model receives final authorization. The specification also requires implementations to make exposed tools and invocations visible and to preserve a user’s ability to deny operations.

A Tool answers, “Which calculations or actions may the external system perform?” Because Tools may modify files, call APIs, or execute code, they usually carry more risk than Resource reads.

Capability	Typical content	Typical decision maker	Possible side effects?
Resource	File content, schemas, business data, URI templates	Host/application selects context	Usually reads, but still creates disclosure risk
Prompt	Parameterized messages or workflow templates	User explicitly selects	Usually no direct execution, but content remains untrusted
Tool	Queries, computation, creation, modification, or external operations	Model may propose; Host/user should authorize	Yes; model the real action and its consequences

Inputs, outputs, and state for one operation

Part	Contents	Responsibility boundary
Input	Protocol version, Client identity/capabilities, method, capability name, arguments, and authorization	Client constructs it; Host applies policy before sending
Capability catalog	Server Resources, Prompts, Tools, and schemas	Server describes; Client validates; Host decides what reaches the model
Request state	One JSON-RPC request and any explicit business handle	The 2026-07-28 core has no implicit protocol session
Output	Complete result, input-required result, or protocol/tool error	Client must distinguish data, errors, and confirmation requirements
Feedback	Returned content re-enters the Host and may guide the next model decision	Host filters, preserves provenance, and manages context
Stop condition	Host task completes, user denies, policy blocks, error occurs, or budget expires	MCP carries messages; it does not define business completion for the application

End-to-end example: let a coding assistant read a repository and run tests

Suppose the user asks, “Read the contribution guide and check whether this patch passes the relevant tests.” The Host is connected to a repository MCP Server. Under the 2026-07-28 specification, the flow may be:

1. Choose a protocol version. The Client intends to use 2026-07-28. It may first make the optional server/discover call to retrieve supported versions, Server identity, and capabilities, or it may call a concrete RPC directly and handle an unsupported-version error.
2. Discover context capabilities. The Client calls resources/list. The Server returns descriptions for the contribution guide and repository files. The Host selects only task-relevant entries the user may access.
3. Read context. The Client uses resources/read to fetch the contribution guide. The Host marks it as Server-supplied content before adding it to model context.
4. Discover action capabilities. The Client calls tools/list and receives, for example, run_tests with its argument schema and description. The Host decides whether to expose this Tool to the model.
5. Model proposes a call. From the patch and guide, the model emits a structured intent to call run_tests on an allowed test path.
6. Host gate. The Host validates path scope, resource budget, and side effects and asks for user approval where needed. The Client sends tools/call only after the gate passes.
7. Server execution. The Server independently checks caller authorization and arguments, runs controlled tests, and returns status, log summary, and structured results. Failures should be explicit errors.
8. Model explains the result. The Host labels the response as tool output and gives it to the model, which explains the patch status from real logs.
9. Application acceptance. The Host stops according to test status and user requirements—not merely because the MCP request returned successfully.

sequenceDiagram
    participant U as User
    participant H as Host + LLM
    participant C as MCP Client
    participant S as Repository Server
    U->>H: Request patch review
    H->>C: Obtain allowed resources and tools
    C->>S: server/discover (optional) / resources/list / tools/list
    S-->>C: Versions, capabilities, and schemas
    H->>C: Read contribution guide
    C->>S: resources/read
    S-->>C: Document content
    H->>U: Show proposed tests and impact and ask if needed
    U-->>H: Approve
    H->>C: Invoke run_tests
    C->>S: tools/call
    S-->>C: Structured status and logs
    C-->>H: Tool result with provenance
    H-->>U: Conclusion grounded in test evidence

Why MCP is not another spelling of tool calling

Question	Model tool calling	MCP
Main boundary	Model output ↔ Host tool executor	Client inside a Host ↔ external Server
Main job	Let a model propose a structured function name and arguments	Standardize discovery, data reads, prompt retrieval, tool requests, and results
Who supplies tool definitions to the model?	Host or model API	MCP Server supplies them through a Client; Host decides what to expose
Does it define model reasoning?	No	No
Does it authorize execution automatically?	No	No

They can be chained. An MCP Server exposes a schema through tools/list. The Host places an allowed definition in model context. The model uses tool calling to produce a name and arguments. After approval, the Host sends tools/call through the MCP Client. Tool calling says how the model expresses what it wants to invoke. MCP says how the application discovers and carries that invocation across an external provider boundary.

Current protocol supplement: 2026-07-28 no longer uses the legacy handshake lifecycle

Latest mechanism as checked on 2026-08-09

MCP 2026-07-28 has a stateless, per-request core. Do not draw the legacy initialize → initialized → persistent Mcp-Session-Id sequence as the current standard flow.

The current revision changes the mechanism in several important ways:

• The core removes the initialize / initialized exchange and the Mcp-Session-Id protocol session.
• Every request is self-describing and carries protocol version, Client identity, and Client capabilities in _meta; HTTP also carries the relevant protocol and routing headers.
• Servers must implement server/discover, but Clients are not required to call it first. A Client may invoke an RPC directly and handle an unsupported-version error.
• If business state must survive across calls, a Server should return an explicit handle such as basket_id, and later tool calls pass it back as a normal argument. A handle is not a protocol session and never bypasses per-request authorization.
• If a Tool needs more user information or confirmation mid-operation, it can return input_required; Multi Round-Trip Requests let the Client retry the original request with the requested inputs.

The distinction is essential: a stateless protocol core does not require a stateless business application. State moves from a hidden connection session into explicit business handles that the model, Host, and Server can observe and govern.

Security problems the protocol does not solve for you

MCP defines communication shapes, not trust. Implementations still need at least:

1. User consent. The user must understand which data goes to which Server and which operation is about to run.
2. Identity and authorization. A Server should validate access to each resource or handle on every request. Capability discovery is not permission.
3. Least privilege. The Host exposes only Servers, Resources, and Tools needed for the task; the Server grants only necessary scopes.
4. Input and output validation. Tool schemas, paths, URLs, results, and Server descriptions can all be untrusted.
5. Prompt-injection defenses. Resources and Prompts are external data. Text saying “ignore your rules” must not be promoted to a system instruction.
6. Side-effect confirmation and idempotency. Deletion, payment, and publishing require explicit confirmation, retry semantics, and audit records.
7. Result truthfulness. Protocol success means message exchange succeeded. A Tool can still fail, data can be stale, and a Server can misrepresent reality.

“The Server description says it is safe” is not security evidence

Tool names, descriptions, and annotations come from the Server. The Host must combine Server trust, actual arguments, authorization scope, and observable side effects rather than treating prose as verified policy.

Common failure modes and a useful debugging order

Symptom	Likely cause	First check
Model cannot see a Tool	Server did not expose it, Client did not discover it, Host policy filtered it, or versions differ	Follow the catalog Server → Client → Host → model
Same-named Tool reaches the wrong service	Naming collision or lost provenance across Servers	Preserve Server identity and namespaces, not only a bare Tool name
Protocol request succeeds but business operation fails	JSON-RPC success was treated as action success	Inspect isError, structured results, and business acceptance state
Upgraded implementation still waits for initialization	It assumes a legacy stateful lifecycle	Check the version; use per-request metadata and optional discovery for 2026-07-28
Explicit handle gives unauthorized access	Handle is mistaken for an authorization credential	Revalidate caller identity and resource access on every Server call
Resource triggers prompt injection	External data is mixed with system instructions	Preserve provenance, isolate instruction layers, filter content, and restrict Tools

Historical contribution versus today’s engineering interpretation

The direct historical claim of the 2024 launch article was that an open Client–Server standard could replace fragmented data-source integrations: providers implement Servers, AI applications implement Clients, and the launch supplied a specification, SDKs, local-client support, and example Servers.

Today’s engineering interpretation must be tied to a named specification revision. Host/Client/Server and Resources/Prompts/Tools remain the core boundaries, while transport, version agreement, authorization, and extensions evolve. In particular, the stateless 2026-07-28 core changed the legacy lifecycle, so a guide must name dates rather than present an old example as current wire behavior.

The protocol’s lasting value is reduced integration duplication, replaceable implementations, and a shared ecosystem. It does not guarantee that a particular Server is trustworthy or decide which capabilities a product should expose.

How it relates to nearby landmarks

Toolformer studies how a model acquires tool-use behavior from training data. AutoGen studies how roles inside an application collaborate through messages. MCP studies how a Host and external capability provider exchange resources, prompts, and tool calls through a common protocol. They occupy model-behavior, application-orchestration, and external-connectivity layers respectively.

Check your understanding

1. What are the responsibilities of the model, Host, Client, and Server? Why should the model not directly hold business-system credentials?
2. Classify a “database schema,” a “code-review template,” and “create a ticket” as Resource, Prompt, or Tool and justify each choice.
3. How do MCP and tool calling chain together? Which one describes model output, and which one defines the external protocol boundary?
4. Under 2026-07-28, must a Client call server/discover first? Why must the old initialize session diagram not be used?
5. Why can a task still fail after tools/call receives a successful JSON-RPC response?

Answer key and reasoning cues

1. The model proposes content and calls; the Host owns UX, model integration, policy, and permissions; a Client carries protocol requests to one Server; the Server wraps capabilities and enforces service-side authorization. Credentials belong in controlled boundaries, not generative text context where they may leak.
2. A schema is readable context, so Resource. A review template is a user-selected structured message, so Prompt. Creating a ticket changes external state, so Tool.
3. The Host can supply an MCP-discovered Tool schema to the model. The model uses tool calling to propose a name and arguments. After approval, the Host sends tools/call through the MCP Client.
4. No. Servers must support discovery, but a Client may call an RPC directly and handle version errors. The current core carries version, identity, and capabilities per request and removed the legacy handshake and protocol session.
5. A protocol response proves that a reply arrived. The Tool may still report a business error, wrong data, or incomplete output. The Host must parse status, run assertions, and accept against the user’s goal.

Previous: AutoGen · Next: SWE-bench · Back to the landmark reading index