One read of Model Context Protocolmcp-20261022T203719Z
295 pages moved out of 357 read.
Pages moved
295
significant first
Pages read
357
in this capture
Captured
20:37 UTC
Corpus hash
3ef457b31340
full-sweep
What this read moved
201-225 of 295, page 9 of 12This capture is too large to show at once. Changes 201-225 of 295 are below, significant first; the rest are on the following screens.
specification/draft/client/sampling Changed · +4 / -4 lines
from line 5
55> **Deprecated**: The Sampling feature is deprecated as of protocol version
66> `2026-07-28`
77> ([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577)).
8> Under the [feature lifecycle policy](/community/feature-lifecycle), it remains
8> Under the [feature lifecycle policy](/community/feature-lifecycle.md), it remains
99> in the specification for at least twelve months after this revision's release
1010> before it becomes eligible for removal. New implementations **SHOULD NOT**
1111> adopt it; existing implementations **SHOULD** migrate to integrating directly
1212> with LLM provider APIs. See the [deprecated features
13> registry](/specification/draft/deprecated).
13> registry](/specification/draft/deprecated.md).
1414
1515The Model Context Protocol (MCP) provides a standardized way for servers to request LLM
1616sampling ("completions" or "generations") from language models via clients. This flow
from line 94
9494>
9595> The `includeContext` parameter values `"thisServer"` and `"allServers"` are
9696> deprecated under the [feature lifecycle
97> policy](/community/feature-lifecycle#deprecating-a-feature)
97> policy](/community/feature-lifecycle.md#deprecating-a-feature)
9898> ([SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596));
9999> they will be removed no later than the Sampling feature itself. Servers
100100> **SHOULD** avoid using these values (e.g. can just omit `includeContext` since
101101> it defaults to `"none"`), and **SHOULD NOT** use them unless the client
102102> declares `sampling.context` capability. See the [deprecated features
103> registry](/specification/draft/deprecated).
103> registry](/specification/draft/deprecated.md).
104104
105105## Protocol Messages
106106
specification/draft/deprecated Changed · +8 / -8 lines
from line 2
22
33This page is the registry of specification features that are currently in the
44**Deprecated** state under the
5[feature lifecycle and deprecation policy](/community/feature-lifecycle)
5[feature lifecycle and deprecation policy](/community/feature-lifecycle.md)
66([SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596)).
77
88A Deprecated feature remains part of the specification but is scheduled for
from line 19
1919
2020| Feature | Deprecation SEP | Deprecated in | Migration path | Earliest removal |
2121| - | - | - | - | - |
22| [Roots](/specification/draft/client/roots) | [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) | `2026-07-28` | Pass directories or files via tool parameters, resource URIs, or server configuration | First revision released on or after 2027-07-28 |
23| [Sampling](/specification/draft/client/sampling) | [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) | `2026-07-28` | Integrate directly with LLM provider APIs | First revision released on or after 2027-07-28 |
24| [Logging](/specification/draft/server/utilities/logging) | [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) | `2026-07-28` | Log to `stderr` for stdio transports; use [OpenTelemetry](https://opentelemetry.io/) for observability | First revision released on or after 2027-07-28 |
25| [Dynamic Client Registration](/specification/draft/basic/authorization/client-registration#dynamic-client-registration) | [PR #2858](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2858) | `2026-07-28` | [Client ID Metadata Documents](/specification/draft/basic/authorization/client-registration#client-id-metadata-documents) | First revision released on or after 2027-07-28 |
26| `includeContext: "thisServer"` / `"allServers"` ([Sampling](/specification/draft/client/sampling#capabilities)) | [SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596) | `2025-11-25` | Omit the field or use `"none"` | Follows Sampling ([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577)) |
27| [HTTP+SSE transport](/specification/2024-11-05/basic/transports#http-with-sse) | [SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596) | `2025-03-26` | [Streamable HTTP](/specification/draft/basic/transports/streamable-http) | Three months after SEP-2596 reaches Final |
22| [Roots](/specification/draft/client/roots.md) | [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) | `2026-07-28` | Pass directories or files via tool parameters, resource URIs, or server configuration | First revision released on or after 2027-07-28 |
23| [Sampling](/specification/draft/client/sampling.md) | [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) | `2026-07-28` | Integrate directly with LLM provider APIs | First revision released on or after 2027-07-28 |
24| [Logging](/specification/draft/server/utilities/logging.md) | [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) | `2026-07-28` | Log to `stderr` for stdio transports; use [OpenTelemetry](https://opentelemetry.io/) for observability | First revision released on or after 2027-07-28 |
25| [Dynamic Client Registration](/specification/draft/basic/authorization/client-registration.md#dynamic-client-registration) | [PR #2858](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2858) | `2026-07-28` | [Client ID Metadata Documents](/specification/draft/basic/authorization/client-registration.md#client-id-metadata-documents) | First revision released on or after 2027-07-28 |
26| `includeContext: "thisServer"` / `"allServers"` ([Sampling](/specification/draft/client/sampling.md#capabilities)) | [SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596) | `2025-11-25` | Omit the field or use `"none"` | Follows Sampling ([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577)) |
27| [HTTP+SSE transport](/specification/2024-11-05/basic/transports.md#http-with-sse) | [SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596) | `2025-03-26` | [Streamable HTTP](/specification/draft/basic/transports/streamable-http.md) | Three months after SEP-2596 reaches Final |
2828
2929The HTTP+SSE transport and the `includeContext` values were already described
3030as deprecated before the lifecycle policy existed; SEP-2596 reclassifies them
31as Deprecated under its [transition provisions](/community/feature-lifecycle).
31as Deprecated under its [transition provisions](/community/feature-lifecycle.md).
3232
3333## Removed
3434
specification/draft/index Changed · +8 / -8 lines
from line 70
7070
7171### Extensions
7272
73Beyond the core protocol, MCP defines optional [extensions](/extensions/overview)
73Beyond the core protocol, MCP defines optional [extensions](/extensions/overview.md)
7474that add modular, specialized, or experimental functionality. Extensions
7575are always opt-in and require explicit support from both client and server, negotiated
7676during initialization. Notable extensions include:
7777
78* **[Tasks](/extensions/tasks/overview)**: Asynchronous execution of long-running
78* **[Tasks](/extensions/tasks/overview.md)**: Asynchronous execution of long-running
7979 operations, with polling, mid-flight input, and durable handles
80* **[Skills over MCP](/community/working-groups/skills-over-mcp)**: Rich, structured
80* **[Skills over MCP](/community/working-groups/skills-over-mcp.md)**: Rich, structured
8181 instructions for agent workflows, discovered and consumed through MCP
82* **[MCP Apps](/extensions/apps/overview)**: Interactive UI elements (charts, forms,
82* **[MCP Apps](/extensions/apps/overview.md)**: Interactive UI elements (charts, forms,
8383 video players) rendered inline within conversations
8484
8585## Security and Trust & Safety
from line 123
123123
124124Explore the detailed specification for each protocol component:
125125
126> **[Architecture](/specification/draft/architecture)**
126> **[Architecture](/specification/draft/architecture.md)**
127127
128> **[Base Protocol](/specification/draft/basic)**
128> **[Base Protocol](/specification/draft/basic.md)**
129129
130> **[Server Features](/specification/draft/server)**
130> **[Server Features](/specification/draft/server.md)**
131131
132132> **[Client Features](/specification/draft/client)**
133133
134> **[Contributing](/community/contributing)**
134> **[Contributing](/community/contributing.md)**
135135
specification/draft/server/discover Changed · +4 / -4 lines
from line 29
2929## Response
3030
3131The server replies with its supported protocol versions, capabilities, and
32identity. This operation supports [caching](/specification/draft/server/utilities/caching).
32identity. This operation supports [caching](/specification/draft/server/utilities/caching.md).
3333
3434```json theme={null}
3535{
from line 73
7373 HTTP status code to drive fallback. A client that supports both modern
7474 (per-request `_meta`) and legacy (`initialize` handshake) servers **SHOULD**
7575 send `server/discover` first; see
76 [stdio: Backward Compatibility](/specification/draft/basic/transports/stdio#backward-compatibility)
76 [stdio: Backward Compatibility](/specification/draft/basic/transports/stdio.md#backward-compatibility)
7777 for the fallback rules.
7878
79See [Protocol Version Negotiation](/specification/draft/basic/versioning#protocol-version-negotiation)
79See [Protocol Version Negotiation](/specification/draft/basic/versioning.md#protocol-version-negotiation)
8080for the full version-selection flow. For HTTP-specific status codes returned for
81unknown methods, see the [Protocol Version Header](/specification/draft/basic/transports/streamable-http#protocol-version-header)
81unknown methods, see the [Protocol Version Header](/specification/draft/basic/transports/streamable-http.md#protocol-version-header)
8282section in Transports.
8383
8484## Data Types
specification/draft/server/index Changed · +3 / -3 lines
from line 20
2020
2121Explore these key primitives in more detail below:
2222
23> **[Prompts](/specification/draft/server/prompts)**
23> **[Prompts](/specification/draft/server/prompts.md)**
2424
25> **[Resources](/specification/draft/server/resources)**
25> **[Resources](/specification/draft/server/resources.md)**
2626
27> **[Tools](/specification/draft/server/tools)**
27> **[Tools](/specification/draft/server/tools.md)**
2828
specification/draft/server/prompts Changed · +6 / -6 lines
from line 64
6464### Listing Prompts
6565
6666To retrieve available prompts, clients send a `prompts/list` request. This operation
67supports [pagination](/specification/draft/server/utilities/pagination) and [caching](/specification/draft/server/utilities/caching).
67supports [pagination](/specification/draft/server/utilities/pagination.md) and [caching](/specification/draft/server/utilities/caching.md).
6868
6969**Request:**
7070
from line 118
118118### Getting a Prompt
119119
120120To retrieve a specific prompt, clients send a `prompts/get` request. Arguments may be
121auto-completed through [the completion API](/specification/draft/server/utilities/completion).
121auto-completed through [the completion API](/specification/draft/server/utilities/completion.md).
122122
123123**Request:**
124124
from line 158
158158}
159159```
160160
161Servers **MAY** also respond to `prompts/get` with an [`InputRequiredResult`](/specification/draft/basic/patterns/mrtr#inputrequiredresult) to indicate that additional input is needed before the prompt can be resolved. This follows the [multi round-trip requests](/specification/draft/basic/patterns/mrtr#multi-round-trip-requests) mechanism. When retrying the request, clients include `inputResponses` and, if provided by the server, `requestState` in the request parameters.
161Servers **MAY** also respond to `prompts/get` with an [`InputRequiredResult`](/specification/draft/basic/patterns/mrtr#inputrequiredresult) to indicate that additional input is needed before the prompt can be resolved. This follows the [multi round-trip requests](/specification/draft/basic/patterns/mrtr.md#multi-round-trip-requests) mechanism. When retrying the request, clients include `inputResponses` and, if provided by the server, `requestState` in the request parameters.
162162
163163### List Changed Notification
164164
from line 221
221221> [!NOTE]
222222>
223223> All content types in prompt messages support optional
224> [annotations](/specification/draft/server/resources#annotations) for metadata
224> [annotations](/specification/draft/server/resources.md#annotations) for metadata
225225> about audience, priority, and modification times.
226226
227227#### Text Content
from line 270
270270#### Resource Links
271271
272272Prompt messages **MAY** include links to
273[Resources](/specification/draft/server/resources), to provide additional context or
273[Resources](/specification/draft/server/resources.md), to provide additional context or
274274data without embedding the resource contents directly. In this case, the prompt message
275275returns a URI that can be fetched by the client:
276276
from line 284
284284}
285285```
286286
287Resource links support the same [Resource annotations](/specification/draft/server/resources#annotations)
287Resource links support the same [Resource annotations](/specification/draft/server/resources.md#annotations)
288288as regular resources to help clients understand how to use them.
289289
290290#### Embedded Resources
specification/draft/server/resources Changed · +8 / -8 lines
from line 81
8181### Listing Resources
8282
8383To discover available resources, clients send a `resources/list` request. This operation
84supports [pagination](/specification/draft/server/utilities/pagination) and [caching](/specification/draft/server/utilities/caching).
84supports [pagination](/specification/draft/server/utilities/pagination.md) and [caching](/specification/draft/server/utilities/caching.md).
8585
8686**Request:**
8787
from line 130
130130### Reading Resources
131131
132132To retrieve resource contents, clients send a `resources/read` request. This operation
133supports [caching](/specification/draft/server/utilities/caching).
133supports [caching](/specification/draft/server/utilities/caching.md).
134134
135135**Request:**
136136
from line 170
170170`resources/read` request. For example, a server could return the contents of
171171several files when a directory resource is read.
172172
173Servers **MAY** also respond to `resources/read` with an [`InputRequiredResult`](/specification/draft/basic/patterns/mrtr#inputrequiredresult) to indicate that additional input is needed before the resource can be read. This follows the [multi round-trip requests](/specification/draft/basic/patterns/mrtr#multi-round-trip-requests) mechanism. When retrying the request, clients include `inputResponses` and, if provided by the server, `requestState` in the request parameters.
173Servers **MAY** also respond to `resources/read` with an [`InputRequiredResult`](/specification/draft/basic/patterns/mrtr#inputrequiredresult) to indicate that additional input is needed before the resource can be read. This follows the [multi round-trip requests](/specification/draft/basic/patterns/mrtr.md#multi-round-trip-requests) mechanism. When retrying the request, clients include `inputResponses` and, if provided by the server, `requestState` in the request parameters.
174174
175175Alternatively, if the scheme of `uri` is `https://`, clients may fetch the resource directly from the web. See the [Common URI Schemes section](#https%3A%2F%2F) for more information.
176176
from line 178
178178
179179Resource templates allow servers to expose parameterized resources using
180180[URI templates](https://datatracker.ietf.org/doc/html/rfc6570). Arguments may be
181auto-completed through [the completion API](/specification/draft/server/utilities/completion).
182This operation supports [pagination](/specification/draft/server/utilities/pagination) and [caching](/specification/draft/server/utilities/caching).
181auto-completed through [the completion API](/specification/draft/server/utilities/completion.md).
182This operation supports [pagination](/specification/draft/server/utilities/pagination.md) and [caching](/specification/draft/server/utilities/caching.md).
183183
184184**Request:**
185185
from line 259
259259See [Subscriptions][subscriptions] for the full protocol mechanics (acknowledgment,
260260`subscriptionId` correlation, and cancellation).
261261
262[subscriptions-listen]: /specification/draft/schema#subscriptionslistenrequest
262[subscriptions-listen]: /specification/draft/schema.md#subscriptionslistenrequest
263263
264[subscriptions]: /specification/draft/basic/patterns/subscriptions
264[subscriptions]: /specification/draft/basic/patterns/subscriptions.md
265265
266266## Message Flow
267267
specification/draft/server/tools Changed · +13 / -13 lines
from line 72
7272### Listing Tools
7373
7474To discover available tools, clients send a `tools/list` request. This operation supports
75[pagination](/specification/draft/server/utilities/pagination) and [caching](/specification/draft/server/utilities/caching).
75[pagination](/specification/draft/server/utilities/pagination.md) and [caching](/specification/draft/server/utilities/caching.md).
7676
7777**Request:**
7878
from line 167
167167
168168### Input Required Tool Results
169169
170Servers **MAY** respond to `tools/call` with an [`InputRequiredResult`](/specification/draft/basic/patterns/mrtr#inputrequiredresult) to indicate that additional input is needed before the tool call can be completed. This follows the [multi round-trip requests](/specification/draft/basic/patterns/mrtr#multi-round-trip-requests) mechanism.
170Servers **MAY** respond to `tools/call` with an [`InputRequiredResult`](/specification/draft/basic/patterns/mrtr#inputrequiredresult) to indicate that additional input is needed before the tool call can be completed. This follows the [multi round-trip requests](/specification/draft/basic/patterns/mrtr.md#multi-round-trip-requests) mechanism.
171171
172172When retrying the request with input responses, clients include `inputResponses` and, if provided by the server, `requestState` in the request parameters:
173173
from line 282
282282* `description`: Human-readable description of functionality
283283* `icons`: Optional array of icons for display in user interfaces
284284* `inputSchema`: JSON Schema defining expected parameters
285 * Follows the [JSON Schema usage guidelines](/specification/draft/basic#json-schema-usage)
285 * Follows the [JSON Schema usage guidelines](/specification/draft/basic.md#json-schema-usage)
286286 * Defaults to 2020-12 if no `$schema` field is present
287287 * **MUST** be a valid JSON Schema object (not `null`)
288288 * For tools with no parameters, use one of these valid approaches:
from line 291
291291 * Properties **MAY** include an [`x-mcp-header`](#x-mcp-header) annotation to expose
292292 parameter values as HTTP headers
293293* `outputSchema`: Optional JSON Schema defining expected output structure
294 * Follows the [JSON Schema usage guidelines](/specification/draft/basic#json-schema-usage)
294 * Follows the [JSON Schema usage guidelines](/specification/draft/basic.md#json-schema-usage)
295295 * Defaults to 2020-12 if no `$schema` field is present
296296* `annotations`: Optional properties describing tool behavior
297297
from line 327
327327
328328The `x-mcp-header` extension property allows servers to designate specific tool
329329parameters to be mirrored into HTTP headers when using the
330[Streamable HTTP transport](/specification/draft/basic/transports/streamable-http#custom-headers-from-tool-parameters).
330[Streamable HTTP transport](/specification/draft/basic/transports/streamable-http.md#custom-headers-from-tool-parameters).
331331This enables network intermediaries (load balancers, proxies, WAFs) to route and process
332332requests based on parameter values without parsing the request body.
333333
from line 348
348348 safe range for integers represented using IEEE754 double-precision floating point numbers (−2<sup>53</sup>+1 to 2<sup>53</sup>−1)
349349* **MUST** only be applied to properties that are *statically reachable* from the schema
350350 root, as defined in
351 [Custom Headers from Tool Parameters](/specification/draft/basic/transports/streamable-http#custom-headers-from-tool-parameters),
351 [Custom Headers from Tool Parameters](/specification/draft/basic/transports/streamable-http.md#custom-headers-from-tool-parameters),
352352 which also defines how header values are extracted from call arguments
353353
354354Clients using the Streamable HTTP transport **MUST** reject tool definitions where any
from line 401
401401>
402402> All content types (text, image, audio, resource links, and embedded resources)
403403> support optional
404> [annotations](/specification/draft/server/resources#annotations) that provide
404> [annotations](/specification/draft/server/resources.md#annotations) that provide
405405> metadata about audience, priority, and modification times. This is the same
406406> annotation format used by resources and prompts.
407407
from line 440
440440
441441#### Resource Links
442442
443A tool **MAY** return links to [Resources](/specification/draft/server/resources), to provide additional context
443A tool **MAY** return links to [Resources](/specification/draft/server/resources.md), to provide additional context
444444or data. In this case, the tool will return a URI that can be subscribed to or fetched by the client:
445445
446446```json theme={null}
from line 453
453453}
454454```
455455
456Resource links support the same [Resource annotations](/specification/draft/server/resources#annotations) as regular resources to help clients understand how to use them.
456Resource links support the same [Resource annotations](/specification/draft/server/resources.md#annotations) as regular resources to help clients understand how to use them.
457457
458458> [!NOTE]
459459>
from line 462
462462
463463#### Embedded Resources
464464
465[Resources](/specification/draft/server/resources) **MAY** be embedded to provide additional context
466or data using a suitable [URI scheme](./resources#common-uri-schemes). Servers that use embedded resources **SHOULD** implement the `resources` capability:
465[Resources](/specification/draft/server/resources.md) **MAY** be embedded to provide additional context
466or data using a suitable [URI scheme](/specification/draft/server/resources.md#common-uri-schemes). Servers that use embedded resources **SHOULD** implement the `resources` capability:
467467
468468```json theme={null}
469469{
from line 481
481481}
482482```
483483
484Embedded resources support the same [Resource annotations](/specification/draft/server/resources#annotations) as regular resources to help clients understand how to use them.
484Embedded resources support the same [Resource annotations](/specification/draft/server/resources.md#annotations) as regular resources to help clients understand how to use them.
485485
486486#### Structured Content
487487
from line 728
7287281. **Protocol Errors** indicate issues with the request structure itself that models are less likely to be able to fix:
729729
730730 * Unknown tool
731 * Malformed requests (requests that fail to satisfy [CallToolRequest schema](/specification/draft/schema#calltoolrequest))
731 * Malformed requests (requests that fail to satisfy [CallToolRequest schema](/specification/draft/schema.md#calltoolrequest))
732732 * Server errors
733733
734734 They are returned as standard JSON-RPC errors:
specification/draft/server/utilities/caching Changed · +3 / -3 lines
from line 17
1717* `resources/read`
1818
1919Interim results with `resultType: "input_required"` (see
20[multi round-trip requests](/specification/draft/basic/patterns/mrtr)) are not cacheable
20[multi round-trip requests](/specification/draft/basic/patterns/mrtr.md)) are not cacheable
2121and carry no caching hints.
2222
2323## Cache Key
from line 28
2828a request whose method or parameters differ from the request that produced it.
2929
3030Results produced by retrying a request through the
31[multi round-trip requests](/specification/draft/basic/patterns/mrtr) mechanism—that
31[multi round-trip requests](/specification/draft/basic/patterns/mrtr.md) mechanism—that
3232is, requests carrying `inputResponses` or `requestState`—**MUST NOT** be cached,
3333as they depend on inputs that are not part of the cache key.
3434
from line 142
142142
143143## Interaction with Pagination
144144
145When a list result is [paginated](/specification/draft/server/utilities/pagination), each
145When a list result is [paginated](/specification/draft/server/utilities/pagination.md), each
146146page is an independently cacheable response—consistent with how HTTP
147147`Cache-Control` treats paginated resources.
148148
community/charter-template Changed · +1 / -1 lines
from line 4
44
55Every MCP Working Group and Interest Group must maintain a charter document following this structure. Charters are stored at `docs/community/working-groups/<group-name>.mdx` or `docs/community/interest-groups/<group-name>.mdx` in the [modelcontextprotocol repository](https://github.com/modelcontextprotocol/modelcontextprotocol) and added to `docs/docs.json`.
66
7The charter captures information specific to your group. Governance rules — leadership requirements, decision-making process, meeting requirements, escalation paths — are defined in the [Working and Interest Groups](/community/working-interest-groups) documentation and apply automatically. Do not repeat them here.
7The charter captures information specific to your group. Governance rules — leadership requirements, decision-making process, meeting requirements, escalation paths — are defined in the [Working and Interest Groups](/community/working-interest-groups.md) documentation and apply automatically. Do not repeat them here.
88
99Sections marked **(WG only)** are required for Working Groups and optional for Interest Groups.
1010
community/interest-groups/agents Changed · +2 / -2 lines
from line 48
4848
4949### Related Groups
5050
51* **[Transports WG](/community/working-groups/transports)** -
51* **[Transports WG](/community/working-groups/transports.md)** -
5252 Task polling, multi-round-trip requests, stateless operation, and request
5353 association depend on transport and message-flow semantics.
54* **[Tasks and Events WG](/community/working-groups/tasks-events)** -
54* **[Tasks and Events WG](/community/working-groups/tasks-events.md)** -
5555 Tasks and proactive task-status and completion notifications are owned by that
5656 group. The IG provides use cases and requirements as input.
5757
community/interest-groups/tool-annotations Changed · +1 / -1 lines
from line 30
3030### Related Groups
3131
3232* **Security IG** - Trust and sensitivity annotations ([SEP-1913](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913)) span both groups' interests
33* **[Skills Over MCP WG](/community/working-groups/skills-over-mcp)** - Skill-level metadata may interact with tool annotations for discovery and filtering
33* **[Skills Over MCP WG](/community/working-groups/skills-over-mcp.md)** - Skill-level metadata may interact with tool annotations for discovery and filtering
3434
3535## Leadership
3636
community/security Changed · +1 / -1 lines
from line 61
6161
6262## Security Interest Group
6363
64The [Security Interest Group](/community/interest-groups/security) is the venue for
64The [Security Interest Group](/community/interest-groups/security.md) is the venue for
6565discussing MCP-specific threats, reviewing security-relevant proposals, and routing
6666disclosure questions that don't fit a single repository.
6767
community/working-groups/filesystems Changed · +2 / -2 lines
from line 47
4747
4848* **File Uploads WG.** Both groups transfer content to a server. Coordination needed on where an upload-oriented flow
4949 ends and a resource write operation begins.
50* **[Skills Over MCP WG](/community/working-groups/skills-over-mcp).** The published
51 [Skills extension](/extensions/skills/overview) uses Resources for file reads and defines optional directory reading.
50* **[Skills Over MCP WG](/community/working-groups/skills-over-mcp.md).** The published
51 [Skills extension](/extensions/skills/overview.md) uses Resources for file reads and defines optional directory reading.
5252 It does not depend on filesystem write operations; coordinate on future resource operations that affect skills.
5353* **Agents IG.** Multi-agent and job orchestration systems are the motivating consumers of a shared write path.
5454
community/working-groups/infrastructure Changed · +1 / -1 lines
from line 76
7676
7777Coordination starts in the Infrastructure Working Group discussion on MCP's Discord. Links to the Infrastructure WG channel and meeting notes will be added once confirmed. Meetings will be published at [meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io).
7878
79The [Working and Interest Groups governance rules](/community/working-interest-groups) apply.
79The [Working and Interest Groups governance rules](/community/working-interest-groups.md) apply.
8080
8181## Deliverables & Success Metrics
8282
community/working-groups/interceptors Changed · +1 / -1 lines
from line 27
2727
2828### Related Groups
2929
30* **[Transports WG](/community/working-groups/transports)** — interceptors operate on MCP message flows whose delivery behavior depends on the transport; coordination needed on transport-level interception points.
30* **[Transports WG](/community/working-groups/transports.md)** — interceptors operate on MCP message flows whose delivery behavior depends on the transport; coordination needed on transport-level interception points.
3131* **Gateways IG** — gateways are a key deployment model for interceptors; coordination needed on gateway-based interceptor patterns and shared concerns around routing, policy, and observability.
3232
3333## Leadership
docs/2024-11-05/develop/build-client Changed · +2 / -2 lines
from line 4
44
55In this tutorial, you'll learn how to build an LLM-powered chatbot client that connects to MCP servers.
66
7Before you begin, it helps to have gone through our [Build an MCP Server](/docs/2024-11-05/develop/build-server) tutorial so you can understand how clients and servers communicate.
7Before you begin, it helps to have gone through our [Build an MCP Server](/docs/2024-11-05/develop/build-server.md) tutorial so you can understand how clients and servers communicate.
88
99**Python**
1010
from line 2489
24892489
24902490## Next steps
24912491
2492> **[Example servers](/examples)**
2492> **[Example servers](/examples.md)**
24932493>
24942494> Check out our gallery of official MCP servers and implementations
24952495
docs/2024-11-05/develop/clients/client-best-practices Changed · +2 / -2 lines
from line 122
122122 Host-->>Model: Server disconnected, context freed
123123```
124124
125This works especially well for general-purpose agents, where the user's intent isn't known upfront. The agent starts with a minimal set of always-on servers and connects others as needed. Combined with [agent skills](/docs/2024-11-05/develop/build-with-agent-skills), a skill file can declare which MCP servers it needs, and the host connects them only when that skill is invoked.
125This works especially well for general-purpose agents, where the user's intent isn't known upfront. The agent starts with a minimal set of always-on servers and connects others as needed. Combined with [agent skills](/docs/2024-11-05/develop/build-with-agent-skills.md), a skill file can declare which MCP servers it needs, and the host connects them only when that skill is invoked.
126126
127127### Implementation Guidelines
128128
from line 271
271271
272272Programmatic tool calling introduces a code execution surface that requires careful sandboxing:
273273
274* **Per-call authorization**: The broker is still the MCP host for spec purposes. Apply the same human-in-the-loop confirmation policy to sandbox-originated calls that you apply to direct calls (see [Tools: Security](/specification/2024-11-05/server/tools#security-considerations)). Approving the script does not grant blanket approval for every tool call it makes at runtime; hosts may grant categorical approval (for example, "allow `ticketing_createIssue` for this script run") rather than prompting per iteration, but the broker must still evaluate each call against that grant.
274* **Per-call authorization**: The broker is still the MCP host for spec purposes. Apply the same human-in-the-loop confirmation policy to sandbox-originated calls that you apply to direct calls (see [Tools: Security](/specification/2024-11-05/server/tools.md#security-considerations)). Approving the script does not grant blanket approval for every tool call it makes at runtime; hosts may grant categorical approval (for example, "allow `ticketing_createIssue` for this script run") rather than prompting per iteration, but the broker must still evaluate each call against that grant.
275275* **Cross-server data flow**: Tool results from one server are untrusted input to another. The broker should apply the same input-review policy to brokered calls as to direct ones; output truncation alone does not prevent exfiltration.
276276* **Network isolation**: The sandbox should have no direct network access. All external communication flows through the host broker, which enforces authorization and access control.
277277* **No credential exposure**: API keys and tokens are held by the host. The generated code calls typed functions; the host adds authentication when forwarding to servers.
docs/2025-03-26/develop/build-client Changed · +2 / -2 lines
from line 4
44
55In this tutorial, you'll learn how to build an LLM-powered chatbot client that connects to MCP servers.
66
7Before you begin, it helps to have gone through our [Build an MCP Server](/docs/2025-03-26/develop/build-server) tutorial so you can understand how clients and servers communicate.
7Before you begin, it helps to have gone through our [Build an MCP Server](/docs/2025-03-26/develop/build-server.md) tutorial so you can understand how clients and servers communicate.
88
99**Python**
1010
from line 2489
24892489
24902490## Next steps
24912491
2492> **[Example servers](/examples)**
2492> **[Example servers](/examples.md)**
24932493>
24942494> Check out our gallery of official MCP servers and implementations
24952495
docs/2025-03-26/develop/clients/client-best-practices Changed · +2 / -2 lines
from line 122
122122 Host-->>Model: Server disconnected, context freed
123123```
124124
125This works especially well for general-purpose agents, where the user's intent isn't known upfront. The agent starts with a minimal set of always-on servers and connects others as needed. Combined with [agent skills](/docs/2025-03-26/develop/build-with-agent-skills), a skill file can declare which MCP servers it needs, and the host connects them only when that skill is invoked.
125This works especially well for general-purpose agents, where the user's intent isn't known upfront. The agent starts with a minimal set of always-on servers and connects others as needed. Combined with [agent skills](/docs/2025-03-26/develop/build-with-agent-skills.md), a skill file can declare which MCP servers it needs, and the host connects them only when that skill is invoked.
126126
127127### Implementation Guidelines
128128
from line 271
271271
272272Programmatic tool calling introduces a code execution surface that requires careful sandboxing:
273273
274* **Per-call authorization**: The broker is still the MCP host for spec purposes. Apply the same human-in-the-loop confirmation policy to sandbox-originated calls that you apply to direct calls (see [Tools: Security](/specification/2025-03-26/server/tools#security-considerations)). Approving the script does not grant blanket approval for every tool call it makes at runtime; hosts may grant categorical approval (for example, "allow `ticketing_createIssue` for this script run") rather than prompting per iteration, but the broker must still evaluate each call against that grant.
274* **Per-call authorization**: The broker is still the MCP host for spec purposes. Apply the same human-in-the-loop confirmation policy to sandbox-originated calls that you apply to direct calls (see [Tools: Security](/specification/2025-03-26/server/tools.md#security-considerations)). Approving the script does not grant blanket approval for every tool call it makes at runtime; hosts may grant categorical approval (for example, "allow `ticketing_createIssue` for this script run") rather than prompting per iteration, but the broker must still evaluate each call against that grant.
275275* **Cross-server data flow**: Tool results from one server are untrusted input to another. The broker should apply the same input-review policy to brokered calls as to direct ones; output truncation alone does not prevent exfiltration.
276276* **Network isolation**: The sandbox should have no direct network access. All external communication flows through the host broker, which enforces authorization and access control.
277277* **No credential exposure**: API keys and tokens are held by the host. The generated code calls typed functions; the host adds authentication when forwarding to servers.
docs/2025-06-18/develop/build-client Changed · +2 / -2 lines
from line 4
44
55In this tutorial, you'll learn how to build an LLM-powered chatbot client that connects to MCP servers.
66
7Before you begin, it helps to have gone through our [Build an MCP Server](/docs/2025-06-18/develop/build-server) tutorial so you can understand how clients and servers communicate.
7Before you begin, it helps to have gone through our [Build an MCP Server](/docs/2025-06-18/develop/build-server.md) tutorial so you can understand how clients and servers communicate.
88
99**Python**
1010
from line 2489
24892489
24902490## Next steps
24912491
2492> **[Example servers](/examples)**
2492> **[Example servers](/examples.md)**
24932493>
24942494> Check out our gallery of official MCP servers and implementations
24952495
docs/2025-06-18/develop/clients/client-best-practices Changed · +2 / -2 lines
from line 122
122122 Host-->>Model: Server disconnected, context freed
123123```
124124
125This works especially well for general-purpose agents, where the user's intent isn't known upfront. The agent starts with a minimal set of always-on servers and connects others as needed. Combined with [agent skills](/docs/2025-06-18/develop/build-with-agent-skills), a skill file can declare which MCP servers it needs, and the host connects them only when that skill is invoked.
125This works especially well for general-purpose agents, where the user's intent isn't known upfront. The agent starts with a minimal set of always-on servers and connects others as needed. Combined with [agent skills](/docs/2025-06-18/develop/build-with-agent-skills.md), a skill file can declare which MCP servers it needs, and the host connects them only when that skill is invoked.
126126
127127### Implementation Guidelines
128128
from line 271
271271
272272Programmatic tool calling introduces a code execution surface that requires careful sandboxing:
273273
274* **Per-call authorization**: The broker is still the MCP host for spec purposes. Apply the same human-in-the-loop confirmation policy to sandbox-originated calls that you apply to direct calls (see [Tools: Security](/specification/2025-06-18/server/tools#security-considerations)). Approving the script does not grant blanket approval for every tool call it makes at runtime; hosts may grant categorical approval (for example, "allow `ticketing_createIssue` for this script run") rather than prompting per iteration, but the broker must still evaluate each call against that grant.
274* **Per-call authorization**: The broker is still the MCP host for spec purposes. Apply the same human-in-the-loop confirmation policy to sandbox-originated calls that you apply to direct calls (see [Tools: Security](/specification/2025-06-18/server/tools.md#security-considerations)). Approving the script does not grant blanket approval for every tool call it makes at runtime; hosts may grant categorical approval (for example, "allow `ticketing_createIssue` for this script run") rather than prompting per iteration, but the broker must still evaluate each call against that grant.
275275* **Cross-server data flow**: Tool results from one server are untrusted input to another. The broker should apply the same input-review policy to brokered calls as to direct ones; output truncation alone does not prevent exfiltration.
276276* **Network isolation**: The sandbox should have no direct network access. All external communication flows through the host broker, which enforces authorization and access control.
277277* **No credential exposure**: API keys and tokens are held by the host. The generated code calls typed functions; the host adds authentication when forwarding to servers.
docs/2025-11-25/develop/clients/client-best-practices Changed · +2 / -2 lines
from line 122
122122 Host-->>Model: Server disconnected, context freed
123123```
124124
125This works especially well for general-purpose agents, where the user's intent isn't known upfront. The agent starts with a minimal set of always-on servers and connects others as needed. Combined with [agent skills](/docs/2025-11-25/develop/build-with-agent-skills), a skill file can declare which MCP servers it needs, and the host connects them only when that skill is invoked.
125This works especially well for general-purpose agents, where the user's intent isn't known upfront. The agent starts with a minimal set of always-on servers and connects others as needed. Combined with [agent skills](/docs/2025-11-25/develop/build-with-agent-skills.md), a skill file can declare which MCP servers it needs, and the host connects them only when that skill is invoked.
126126
127127### Implementation Guidelines
128128
from line 271
271271
272272Programmatic tool calling introduces a code execution surface that requires careful sandboxing:
273273
274* **Per-call authorization**: The broker is still the MCP host for spec purposes. Apply the same human-in-the-loop confirmation policy to sandbox-originated calls that you apply to direct calls (see [Tools: Security](/specification/2025-11-25/server/tools#security-considerations)). Approving the script does not grant blanket approval for every tool call it makes at runtime; hosts may grant categorical approval (for example, "allow `ticketing_createIssue` for this script run") rather than prompting per iteration, but the broker must still evaluate each call against that grant.
274* **Per-call authorization**: The broker is still the MCP host for spec purposes. Apply the same human-in-the-loop confirmation policy to sandbox-originated calls that you apply to direct calls (see [Tools: Security](/specification/2025-11-25/server/tools.md#security-considerations)). Approving the script does not grant blanket approval for every tool call it makes at runtime; hosts may grant categorical approval (for example, "allow `ticketing_createIssue` for this script run") rather than prompting per iteration, but the broker must still evaluate each call against that grant.
275275* **Cross-server data flow**: Tool results from one server are untrusted input to another. The broker should apply the same input-review policy to brokered calls as to direct ones; output truncation alone does not prevent exfiltration.
276276* **Network isolation**: The sandbox should have no direct network access. All external communication flows through the host broker, which enforces authorization and access control.
277277* **No credential exposure**: API keys and tokens are held by the host. The generated code calls typed functions; the host adds authentication when forwarding to servers.
extensions/auth/oauth-client-credentials Changed · +1 / -1 lines
from line 384
384384>
385385> Support for this extension varies by client. Extensions are opt-in and never active by default.
386386
387Check the [client matrix](/extensions/client-matrix) for current implementation status across MCP clients.
387Check the [client matrix](/extensions/client-matrix.md) for current implementation status across MCP clients.
388388
389389## Related resources
390390
registry/github-actions Changed · +1 / -1 lines
from line 211
211211| Error Message | Action |
212212| - | - |
213213| "Authentication failed" | Ensure `id-token: write` permission is set for OIDC, or check secrets. |
214| "Package validation failed" | Verify your package successfully published to the package registry (e.g., npm, PyPI), and that your package has the [necessary verification information](./package-types). |
214| "Package validation failed" | Verify your package successfully published to the package registry (e.g., npm, PyPI), and that your package has the [necessary verification information](/registry/package-types.md). |
215215