Follow Discord
Sweep 22 Oct 2026 · 21:04Z Build v2.1.309 528 read Stable v2.1.308 Latest v2.1.309 Next v2.1.309 Feeds RSS JSON llms.txt llms-full.txt Unofficial
One change · mcp

Architecture overview changeddocs/2026-07-28/learn/architecture

Nearest release: v2.1.305, published under an hour before upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.

Upstream edited this page at 20 Oct 2026 20:02 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 22 Oct 2026 20:37 UTC.

Upstream edited
Recorded here
Lines+13added
Lines−13removed
From line 4 where the diff opens
First seen 14 Aug 2026 this site's first read of the page
Recorded edits3to this page, all time

The whole hunk

from line 4, old and new numbered
/
lines
from line 4
44 
55Because MCP SDKs abstract away many concerns, most developers will likely find the [data layer protocol](#data-layer-protocol) section to be the most useful. It discusses how MCP servers can provide context to an AI application.
66 
7For specific implementation details, please refer to the documentation for your [language-specific SDK](/docs/2026-07-28/sdk).
7For specific implementation details, please refer to the documentation for your [language-specific SDK](/docs/2026-07-28/sdk.md).
88 
99## Scope
1010 
1111The Model Context Protocol includes the following projects:
1212 
13* [MCP Specification](https://modelcontextprotocol.io/specification/latest): A specification of MCP that outlines the implementation requirements for clients and servers.
14* [MCP SDKs](/docs/2026-07-28/sdk): SDKs for different programming languages that implement MCP.
13* [MCP Specification](https://modelcontextprotocol.io/specification/latest.md): A specification of MCP that outlines the implementation requirements for clients and servers.
14* [MCP SDKs](/docs/2026-07-28/sdk.md): SDKs for different programming languages that implement MCP.
1515* **MCP Development Tools**: Tools for developing MCP servers and clients, including the [MCP Inspector](https://github.com/modelcontextprotocol/inspector)
1616* [MCP Reference Server Implementations](https://github.com/modelcontextprotocol/servers): Reference implementations of MCP servers.
1717 
from line 82
8282 
8383* **Discovery**: Lets clients query a server's supported protocol versions, capabilities, and identity through the `server/discover` request
8484* **Server features**: Enables servers to provide core functionality including tools for AI actions, resources for context data, and prompts for interaction templates from and to the client
85* **Client features**: Enables servers to elicit input from the user. Sampling is [deprecated](/specification/2026-07-28/deprecated) as of protocol version `2026-07-28`.
85* **Client features**: Enables servers to elicit input from the user. Sampling is [deprecated](/specification/2026-07-28/deprecated.md) as of protocol version `2026-07-28`.
8686* **Utility features**: Supports additional capabilities like notifications for real-time updates and progress tracking for long-running operations
8787 
8888#### Transport layer
from line 104
104104 
105105#### Statelessness and discovery
106106 
107MCP is a stateless protocol (Every request contains all the information needed to process it, so servers infer nothing from previous requests). Every request carries the protocol version and the capabilities (Features and operations that a client or server supports, such as tools, resources, or prompts) relevant to that request in its `_meta` field, so the server can process each request on its own. Clients should also identify themselves in the same field unless configured not to. Servers advertise their supported versions and capabilities through the mandatory [`server/discover`](/specification/2026-07-28/server/discover) request, which clients may send before any other request. Detailed information can be found in the [specification](/specification/2026-07-28/basic/index#statelessness), and the [example](#example) showcases the per-request metadata and the discovery sequence.
107MCP is a stateless protocol (Every request contains all the information needed to process it, so servers infer nothing from previous requests). Every request carries the protocol version and the capabilities (Features and operations that a client or server supports, such as tools, resources, or prompts) relevant to that request in its `_meta` field, so the server can process each request on its own. Clients should also identify themselves in the same field unless configured not to. Servers advertise their supported versions and capabilities through the mandatory [`server/discover`](/specification/2026-07-28/server/discover) request, which clients may send before any other request. Detailed information can be found in the [specification](/specification/2026-07-28/basic/index.md#statelessness), and the [example](#example) showcases the per-request metadata and the discovery sequence.
108108 
109109#### Primitives
110110 
from line 121
121121 
122122As a concrete example, consider an MCP server that provides context about a database. It can expose tools for querying the database, a resource that contains the schema of the database, and a prompt that includes few-shot examples for interacting with the tools.
123123 
124For more details about server primitives see [server concepts](./server-concepts).
124For more details about server primitives see [server concepts](/docs/2026-07-28/learn/server-concepts.md).
125125 
126126MCP also defines primitives that *clients* can expose. These primitives allow MCP server authors to build richer interactions.
127127 
128128* **Elicitation**: Allows servers to request additional information from users. This is useful when server authors want to get more information from the user, or ask for confirmation of an action. Servers request user input with the `elicitation/create` method.
129129 
130Elicitation requests are delivered through the [Multi Round-Trip Requests](/specification/2026-07-28/basic/patterns/mrtr) pattern, explained in the [elicitation overview](/docs/2026-07-28/learn/client-concepts#elicitation).
130Elicitation requests are delivered through the [Multi Round-Trip Requests](/specification/2026-07-28/basic/patterns/mrtr.md) pattern, explained in the [elicitation overview](/docs/2026-07-28/learn/client-concepts.md#elicitation).
131131 
132132**Deprecated**: The following client primitives are deprecated as of protocol version `2026-07-28`.
133133 
from line 134
134134* **Sampling**: Allows servers to request language model completions from the client's AI application. This is useful when server authors want access to a language model, but want to stay model-independent and not include a language model SDK in their MCP server. Servers request completions with the `sampling/createMessage` method, also delivered through the Multi Round-Trip Requests pattern. New implementations should integrate directly with LLM provider APIs.
135135* **Logging**: Enables servers to send log messages to clients for debugging and monitoring purposes. New implementations should log to `stderr` (stdio transport) or use OpenTelemetry.
136136 
137For more details about client primitives see [client concepts](./client-concepts).
137For more details about client primitives see [client concepts](/docs/2026-07-28/learn/client-concepts.md).
138138 
139Besides server and client primitives, the protocol supports optional [extensions](/extensions/overview) that build on the core protocol. For example, the [Tasks extension](/extensions/tasks/overview) lets servers return a durable handle for long-running requests, so clients can poll for status and retrieve the result later.
139Besides server and client primitives, the protocol supports optional [extensions](/extensions/overview.md) that build on the core protocol. For example, the [Tasks extension](/extensions/tasks/overview.md) lets servers return a durable handle for long-running requests, so clients can poll for status and retrieve the result later.
140140 
141141#### Notifications
142142 
from line 308
308308 
309309#### Understanding the Tool Discovery Request
310310 
311The `tools/list` request requires no parameters beyond the standard `_meta` fields that accompany every MCP request. It also accepts an optional `cursor` parameter for [pagination](/specification/2026-07-28/server/utilities/pagination), which the example above omits.
311The `tools/list` request requires no parameters beyond the standard `_meta` fields that accompany every MCP request. It also accepts an optional `cursor` parameter for [pagination](/specification/2026-07-28/server/utilities/pagination.md), which the example above omits.
312312 
313313#### Understanding the Tool Discovery Response
314314 
from line 321
321321* **`description`**: Detailed explanation of what the tool does and when to use it
322322* **`inputSchema`**: A JSON Schema that defines the expected input parameters, enabling type validation and providing clear documentation about required and optional parameters
323323 
324The result is marked `"resultType": "complete"` and carries two caching fields. `ttlMs` is a freshness hint in milliseconds, so this tool list can be cached for five minutes. `cacheScope` indicates who may reuse the response. The specification's [caching utility](/specification/2026-07-28/server/utilities/caching) defines the full rules.
324The result is marked `"resultType": "complete"` and carries two caching fields. `ttlMs` is a freshness hint in milliseconds, so this tool list can be cached for five minutes. `cacheScope` indicates who may reuse the response. The specification's [caching utility](/specification/2026-07-28/server/utilities/caching.md) defines the full rules.
325325 
326326#### How This Works in AI Applications
327327 
from line 336
336336conversation.register_available_tools(available_tools)
337337```
338338 
339Clients that federate many servers can use [progressive tool discovery](/docs/2026-07-28/develop/clients/client-best-practices#progressive-tool-discovery) rather than loading every tool upfront.
339Clients that federate many servers can use [progressive tool discovery](/docs/2026-07-28/develop/clients/client-best-practices.md#progressive-tool-discovery) rather than loading every tool upfront.
340340 
341341**3. Tool Execution (Primitives)**
342342 
Feedback