Follow Discord
Sweep 29 Sep 2026 · 18:10Z Build v2.1.285 506 read Stable v2.1.280 Latest v2.1.285 Next v2.1.285 Feeds RSS JSON llms.txt llms-full.txt Unofficial
HomeDocsModel Context Protocol
One capture · mcp

One read of Model Context Protocolmcp-20260928T220720Z

173 pages moved out of 349 read.

Pages moved 173 significant first
Pages read 349 in this capture
Captured 22:07 UTC
Corpus hash 719057065235 corpus-hash

What this read moved

26-50 of 173, page 2 of 7

This capture is too large to show at once. Changes 26-50 of 173 are below, significant first; the rest are on the following screens.

community/working-groups/transports Changed · +11 / -11 lines

from line 85
8585 
8686## Authority & Decision Rights
8787 
88| Decision Type | Authority Level |
89| ----------------------------------- | ------------------------------------------------------ |
90| Meeting logistics & scheduling | WG Leads (autonomous) |
91| Proposal prioritization within WG | WG Leads (autonomous) |
92| SEP triage & closure (in scope) | WG Leads (autonomous, with documented rationale) |
93| Technical design within scope | WG consensus |
94| Spec changes (additive) | WG consensus → Core Maintainer approval |
88| Decision Type | Authority Level |
89| - | - |
90| Meeting logistics & scheduling | WG Leads (autonomous) |
91| Proposal prioritization within WG | WG Leads (autonomous) |
92| SEP triage & closure (in scope) | WG Leads (autonomous, with documented rationale) |
93| Technical design within scope | WG consensus |
94| Spec changes (additive) | WG consensus → Core Maintainer approval |
9595| Spec changes (breaking/fundamental) | WG consensus → Core Maintainer approval + wider review |
96| Scope expansion | Core Maintainer approval required |
97| WG Member approval | WG Member sponsors |
96| Scope expansion | Core Maintainer approval required |
97| WG Member approval | WG Member sponsors |
9898 
9999## Membership
100100 
from line 145
145145 
146146## Changelog
147147 
148| Date | Change |
149| ---------- | --------------- |
148| Date | Change |
149| - | - |
150150| 2026-08-23 | Initial charter |
151151 

community/working-groups/triggers-events Changed · +22 / -22 lines

from line 32
3232 
3333## Leadership
3434 
35| Role | Name | Organization | GitHub | Term |
36| ---- | --------------- | ------------------- | ------------------------------------------------ | ------- |
37| Lead | Clare Liguori | Amazon Web Services | [@clareliguori](https://github.com/clareliguori) | Initial |
38| Lead | Peter Alexander | Anthropic | [@pja-ant](https://github.com/pja-ant) | Initial |
35| Role | Name | Organization | GitHub | Term |
36| - | - | - | - | - |
37| Lead | Clare Liguori | Amazon Web Services | [@clareliguori](https://github.com/clareliguori) | Initial |
38| Lead | Peter Alexander | Anthropic | [@pja-ant](https://github.com/pja-ant) | Initial |
3939 
4040## Authority & Decision Rights
4141 
42| Decision Type | Authority Level |
43| ----------------------------------- | ------------------------------------------------------ |
44| Meeting logistics & scheduling | WG Leads (autonomous) |
45| Proposal prioritization within WG | WG Leads (autonomous) |
46| SEP triage & closure (in scope) | WG Leads (autonomous, with documented rationale) |
47| Technical design within scope | WG consensus |
48| Spec changes (additive) | WG consensus → Core Maintainer approval |
42| Decision Type | Authority Level |
43| - | - |
44| Meeting logistics & scheduling | WG Leads (autonomous) |
45| Proposal prioritization within WG | WG Leads (autonomous) |
46| SEP triage & closure (in scope) | WG Leads (autonomous, with documented rationale) |
47| Technical design within scope | WG consensus |
48| Spec changes (additive) | WG consensus → Core Maintainer approval |
4949| Spec changes (breaking/fundamental) | WG consensus → Core Maintainer approval + wider review |
50| Scope expansion | Core Maintainer approval required |
51| WG Member approval | WG Member sponsors |
50| Scope expansion | Core Maintainer approval required |
51| WG Member approval | WG Member sponsors |
5252 
5353## Operations
5454 
55| Meeting | Frequency | Duration | Purpose |
56| --------------- | --------- | -------- | ------------------------------------- |
57| Working Session | Weekly | 30 min | Technical discussion, proposal review |
55| Meeting | Frequency | Duration | Purpose |
56| - | - | - | - |
57| Working Session | Weekly | 30 min | Technical discussion, proposal review |
5858 
5959## Resources
6060 
from line 64
6464 
6565### Active Work Items
6666 
67| Item | Status | Target Date | Champion |
68| --------------------------------------- | -------- | ----------- | -------- |
69| SEP: Events in MCP v1 RFC | Ideating | End April | TBD |
70| Reference implementation in Tier-1 SDKs | — | End April | TBD |
67| Item | Status | Target Date | Champion |
68| - | - | - | - |
69| SEP: Events in MCP v1 RFC | Ideating | End April | TBD |
70| Reference implementation in Tier-1 SDKs | — | End April | TBD |
7171 
7272### Success Criteria
7373 
from line 77
7777 
7878## Changelog
7979 
80| Date | Change |
81| ---------- | --------------- |
80| Date | Change |
81| - | - |
8282| 2026-03-24 | Initial charter |
8383 

community/working-interest-groups Changed · +19 / -19 lines

from line 6
66 
77## Quick Reference
88 
9| | Interest Group (IG) | Working Group (WG) |
10| -------------- | -------------------------------------------------- | ------------------------------------------------------ |
11| **Purpose** | Identify and discuss problems | Build concrete solutions |
12| **Output** | Problem statements, use cases, recommendations | SEPs, implementations, code |
13| **Commitment** | Active contribution expected | Active contribution expected |
14| **Duration** | Ongoing as long as topic is relevant | Until deliverables complete |
15| **Leadership** | Facilitator(s) | Lead(s) |
16| **Decisions** | Rough consensus, non-binding | Binding (lazy consensus → vote → escalation) |
17| **Example** | "Security in MCP" — discussing security challenges | "Server Identity" — implementing identity verification |
9| | Interest Group (IG) | Working Group (WG) |
10| - | - | - |
11| **Purpose** | Identify and discuss problems | Build concrete solutions |
12| **Output** | Problem statements, use cases, recommendations | SEPs, implementations, code |
13| **Commitment** | Active contribution expected | Active contribution expected |
14| **Duration** | Ongoing as long as topic is relevant | Until deliverables complete |
15| **Leadership** | Facilitator(s) | Lead(s) |
16| **Decisions** | Rough consensus, non-binding | Binding (lazy consensus → vote → escalation) |
17| **Example** | "Security in MCP" — discussing security challenges | "Server Identity" — implementing identity verification |
1818 
1919## When to Use Which
2020 
from line 113
113113 
114114All groups use the following participation tiers. Note that **WG Member** is a group-specific participation level distinct from the org-wide **Member** role — an individual may be a WG Member in a specific group without holding org-wide Member status, and vice versa.
115115 
116| Level | Description | Privileges |
117| -------------------- | ------------------------------------------------- | ------------------------------------------------------------------ |
118| **Observer** | Anyone interested in following the group's work | Read access, may attend meetings, limited discussion participation |
119| **Participant** | Active contributor to group discussions | Can propose agenda items, participate in async votes |
120| **WG Member** | Sustained contributor with demonstrated expertise | Counted for quorum (WGs only) |
121| **Lead/Facilitator** | Operational leadership of the group | Sets agenda, facilitates, escalates |
116| Level | Description | Privileges |
117| - | - | - |
118| **Observer** | Anyone interested in following the group's work | Read access, may attend meetings, limited discussion participation |
119| **Participant** | Active contributor to group discussions | Can propose agenda items, participate in async votes |
120| **WG Member** | Sustained contributor with demonstrated expertise | Counted for quorum (WGs only) |
121| **Lead/Facilitator** | Operational leadership of the group | Sets agenda, facilitates, escalates |
122122 
123123Interest Groups primarily operate with Observers, Participants, and Facilitators. IGs may adopt the WG Member tier if their work warrants formal decision-making, but are not required to.
124124 
from line 202
202202 
203203All groups use the following channels:
204204 
205| Channel | Purpose | Response Expectation |
206| ------------------------------------ | ------------------------------ | -------------------- |
207| Discord `#{name}-wg` or `#{name}-ig` | Quick questions, coordination | Best effort |
208| GitHub Discussions | Long-form technical discussion | Weekly triage |
205| Channel | Purpose | Response Expectation |
206| - | - | - |
207| Discord `#{name}-wg` or `#{name}-ig` | Quick questions, coordination | Best effort |
208| GitHub Discussions | Long-form technical discussion | Weekly triage |
209209 
210210In addition to Discord, groups can establish a discussion category in [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/). Leads will be granted the appropriate roles to manage and moderate discussions.
211211 

docs/2024-11-05/develop/build-with-agent-skills Changed · +4 / -4 lines

from line 13
1313[`mcp-server-dev` plugin](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/mcp-server-dev).
1414It provides three composing skills:
1515 
16| Skill | Purpose |
17| ------------------ | ----------------------------------------------------------------------------------------------------------------------- |
16| Skill | Purpose |
17| - | - |
1818| `build-mcp-server` | Entry point. Interrogates the use case, picks a deployment model and tool-design pattern, routes to specialized skills. |
19| `build-mcp-app` | Adds interactive UI widgets (forms, pickers, dashboards) rendered inline in chat. |
20| `build-mcpb` | Packages a local stdio server with its runtime so users can install it without Node or Python. |
19| `build-mcp-app` | Adds interactive UI widgets (forms, pickers, dashboards) rendered inline in chat. |
20| `build-mcpb` | Packages a local stdio server with its runtime so users can install it without Node or Python. |
2121 
2222Each skill ships a `SKILL.md` file plus a `references/` folder of supporting
2323material (auth flows, tool-design patterns, widget templates, manifest schemas)

docs/2024-11-05/develop/clients/client-best-practices Changed · +12 / -12 lines

from line 128
128128 
129129When implementing progressive discovery:
130130 
131| Guideline | Rationale |
132| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
133| **Offer multiple detail levels** | Let the model choose between name-only, name-and-description, or full-schema responses. |
134| **Cache tool definitions** | Once fetched from a server, memoize the definition host-side so re-injecting it later doesn't need another `tools/list` round trip. This is separate from what's currently in the model's context. |
135| **Refresh on `list_changed`** | Re-index the search catalog when a server sends `notifications/tools/list_changed`. |
136| **Group tools by server** | Present tools organized by their source server so the model can reason about related capabilities. |
131| Guideline | Rationale |
132| - | - |
133| **Offer multiple detail levels** | Let the model choose between name-only, name-and-description, or full-schema responses. |
134| **Cache tool definitions** | Once fetched from a server, memoize the definition host-side so re-injecting it later doesn't need another `tools/list` round trip. This is separate from what's currently in the model's context. |
135| **Refresh on `list_changed`** | Re-index the search catalog when a server sends `notifications/tools/list_changed`. |
136| **Group tools by server** | Present tools organized by their source server so the model can reason about related capabilities. |
137137 
138138### Interaction with Prompt Caching
139139 
from line 234
234234 
235235The right sandbox depends on the language you want the model to write, your host application's language, and how much isolation you need. The table lists example runtimes rather than endorsements; evaluate maturity for your use case:
236236 
237| Sandboxed language | Runtime / Library | Host language | Approach |
238| ------------------ | ------------------------------------------------------------- | ----------------- | ----------------------------------------------------------------------------------------------- |
239| **JavaScript** | [Deno](https://github.com/denoland/deno), `isolated-vm` | Rust / Node / CLI | V8-based runtimes with fine-grained permissions. Can disable all permissions for full lockdown. |
240| **Python** | [Monty](https://github.com/pydantic/monty) *(experimental)* | Rust | Minimal Python interpreter built for AI use cases. No I/O by default. |
241| **TypeScript** | [pctx](https://github.com/portofcontext/pctx) *(early-stage)* | Python / Rust | Incorporates code mode concepts as a library, with low-level Rust support. |
242| **Any (via Wasm)** | [Wasmtime](https://github.com/bytecodealliance/wasmtime) | Rust / C / Go | Compile any language to Wasm and run it with capability-based security. |
237| Sandboxed language | Runtime / Library | Host language | Approach |
238| - | - | - | - |
239| **JavaScript** | [Deno](https://github.com/denoland/deno), `isolated-vm` | Rust / Node / CLI | V8-based runtimes with fine-grained permissions. Can disable all permissions for full lockdown. |
240| **Python** | [Monty](https://github.com/pydantic/monty) *(experimental)* | Rust | Minimal Python interpreter built for AI use cases. No I/O by default. |
241| **TypeScript** | [pctx](https://github.com/portofcontext/pctx) *(early-stage)* | Python / Rust | Incorporates code mode concepts as a library, with low-level Rust support. |
242| **Any (via Wasm)** | [Wasmtime](https://github.com/bytecodealliance/wasmtime) | Rust / C / Go | Compile any language to Wasm and run it with capability-based security. |
243243 
244244Regardless of sandbox, the integration pattern is the same: the host injects function stubs, intercepts calls over an in-process or stdio channel (so network permissions can stay fully denied), and dispatches them as `tools/call` requests to MCP servers.
245245 

docs/2024-11-05/learn/client-concepts Changed · +3 / -3 lines

from line 8
88 
99In addition to making use of context provided by servers, clients may provide several features to servers. These client features allow server authors to build richer interactions.
1010 
11| Feature | Explanation | Example |
12| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
13| **Roots** | Roots allow clients to specify which directories servers should focus on, communicating intended scope through a coordination mechanism. | A server for booking travel may be given access to a specific directory, from which it can read a user's calendar. |
11| Feature | Explanation | Example |
12| - | - | - |
13| **Roots** | Roots allow clients to specify which directories servers should focus on, communicating intended scope through a coordination mechanism. | A server for booking travel may be given access to a specific directory, from which it can read a user's calendar. |
1414| **Sampling** | Sampling allows servers to request LLM completions through the client, enabling an agentic workflow. This approach puts the client in complete control of user permissions and security measures. | A server for booking travel may send a list of flights to an LLM and request that the LLM pick the best flight for the user. |
1515 
1616### Roots

docs/2024-11-05/learn/server-concepts Changed · +18 / -18 lines

from line 8
88 
99Servers provide functionality through three building blocks:
1010 
11| Feature | Explanation | Examples | Who controls it |
12| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | --------------- |
13| **Tools** | Functions that your LLM can actively call, and decides when to use them based on user requests. Tools can write to databases, call external APIs, modify files, or trigger other logic. | Search flights<br />Send messages<br />Create calendar events | Model |
14| **Resources** | Passive data sources that provide read-only access to information for context, such as file contents, database schemas, or API documentation. | Retrieve documents<br />Access knowledge bases<br />Read calendars | Application |
15| **Prompts** | Pre-built instruction templates that tell the model to work with specific tools and resources. | Plan a vacation<br />Summarize my meetings<br />Draft an email | User |
11| Feature | Explanation | Examples | Who controls it |
12| - | - | - | - |
13| **Tools** | Functions that your LLM can actively call, and decides when to use them based on user requests. Tools can write to databases, call external APIs, modify files, or trigger other logic. | Search flights<br />Send messages<br />Create calendar events | Model |
14| **Resources** | Passive data sources that provide read-only access to information for context, such as file contents, database schemas, or API documentation. | Retrieve documents<br />Access knowledge bases<br />Read calendars | Application |
15| **Prompts** | Pre-built instruction templates that tell the model to work with specific tools and resources. | Plan a vacation<br />Summarize my meetings<br />Draft an email | User |
1616 
1717We will use a hypothetical scenario to demonstrate the role of each of these features, and show how they can work together.
1818 
from line 26
2626 
2727**Protocol operations:**
2828 
29| Method | Purpose | Returns |
30| ------------ | ------------------------ | -------------------------------------- |
29| Method | Purpose | Returns |
30| - | - | - |
3131| `tools/list` | Discover available tools | Array of tool definitions with schemas |
32| `tools/call` | Execute a specific tool | Tool execution result |
32| `tools/call` | Execute a specific tool | Tool execution result |
3333 
3434**Example tool definition:**
3535 
from line 109
109109 
110110**Protocol operations:**
111111 
112| Method | Purpose | Returns |
113| -------------------------- | ------------------------------- | -------------------------------------- |
114| `resources/list` | List available direct resources | Array of resource descriptors |
115| `resources/templates/list` | Discover resource templates | Array of resource template definitions |
116| `resources/read` | Retrieve resource contents | Resource data with metadata |
117| `resources/subscribe` | Monitor resource changes | Subscription confirmation |
112| Method | Purpose | Returns |
113| - | - | - |
114| `resources/list` | List available direct resources | Array of resource descriptors |
115| `resources/templates/list` | Discover resource templates | Array of resource template definitions |
116| `resources/read` | Retrieve resource contents | Resource data with metadata |
117| `resources/subscribe` | Monitor resource changes | Subscription confirmation |
118118 
119119#### Example: Getting Travel Planning Context
120120 
from line 180
180180 
181181**Protocol operations:**
182182 
183| Method | Purpose | Returns |
184| -------------- | -------------------------- | ------------------------------------- |
185| `prompts/list` | Discover available prompts | Array of prompt descriptors |
186| `prompts/get` | Retrieve prompt details | Full prompt definition with arguments |
183| Method | Purpose | Returns |
184| - | - | - |
185| `prompts/list` | Discover available prompts | Array of prompt descriptors |
186| `prompts/get` | Retrieve prompt details | Full prompt definition with arguments |
187187 
188188#### Example: Streamlined Workflows
189189 

docs/2024-11-05/sdk Changed · +12 / -12 lines

from line 6
66 
77## Available SDKs
88 
9| SDK | Repository | Tier |
10| :----------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | ------------------------------------------------: |
11| <Icon icon="square-js" size={24} />   [TypeScript](https://ts.sdk.modelcontextprotocol.io) | [modelcontextprotocol/typescript-sdk](https://github.com/modelcontextprotocol/typescript-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
12| <Icon icon="python" size={24} />   [Python](https://py.sdk.modelcontextprotocol.io) | [modelcontextprotocol/python-sdk](https://github.com/modelcontextprotocol/python-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
13| <Icon icon="square-c" size={24} />   [C#](https://csharp.sdk.modelcontextprotocol.io) | [modelcontextprotocol/csharp-sdk](https://github.com/modelcontextprotocol/csharp-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
14| <Icon icon="golang" size={24} />   [Go](https://go.sdk.modelcontextprotocol.io) | [modelcontextprotocol/go-sdk](https://github.com/modelcontextprotocol/go-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
15| <Icon icon="java" size={24} />   [Java](https://java.sdk.modelcontextprotocol.io) | [modelcontextprotocol/java-sdk](https://github.com/modelcontextprotocol/java-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
16| <Icon icon="rust" size={24} />   [Rust](https://rust.sdk.modelcontextprotocol.io) | [modelcontextprotocol/rust-sdk](https://github.com/modelcontextprotocol/rust-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
17| <Icon icon="swift" size={24} />   Swift | [modelcontextprotocol/swift-sdk](https://github.com/modelcontextprotocol/swift-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
18| <Icon icon="gem" size={24} />   [Ruby](https://ruby.sdk.modelcontextprotocol.io) | [modelcontextprotocol/ruby-sdk](https://github.com/modelcontextprotocol/ruby-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
19| <Icon icon="php" size={24} />   [PHP](https://php.sdk.modelcontextprotocol.io) | [modelcontextprotocol/php-sdk](https://github.com/modelcontextprotocol/php-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
20| <Icon icon="square-k" size={24} />   [Kotlin](https://kotlin.sdk.modelcontextprotocol.io) | [modelcontextprotocol/kotlin-sdk](https://github.com/modelcontextprotocol/kotlin-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
9| SDK | Repository | Tier |
10| :- | :- | -: |
11| <Icon icon="square-js" size={24} />   [TypeScript](https://ts.sdk.modelcontextprotocol.io) | [modelcontextprotocol/typescript-sdk](https://github.com/modelcontextprotocol/typescript-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
12| <Icon icon="python" size={24} />   [Python](https://py.sdk.modelcontextprotocol.io) | [modelcontextprotocol/python-sdk](https://github.com/modelcontextprotocol/python-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
13| <Icon icon="square-c" size={24} />   [C#](https://csharp.sdk.modelcontextprotocol.io) | [modelcontextprotocol/csharp-sdk](https://github.com/modelcontextprotocol/csharp-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
14| <Icon icon="golang" size={24} />   [Go](https://go.sdk.modelcontextprotocol.io) | [modelcontextprotocol/go-sdk](https://github.com/modelcontextprotocol/go-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
15| <Icon icon="java" size={24} />   [Java](https://java.sdk.modelcontextprotocol.io) | [modelcontextprotocol/java-sdk](https://github.com/modelcontextprotocol/java-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
16| <Icon icon="rust" size={24} />   [Rust](https://rust.sdk.modelcontextprotocol.io) | [modelcontextprotocol/rust-sdk](https://github.com/modelcontextprotocol/rust-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
17| <Icon icon="swift" size={24} />   Swift | [modelcontextprotocol/swift-sdk](https://github.com/modelcontextprotocol/swift-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
18| <Icon icon="gem" size={24} />   [Ruby](https://ruby.sdk.modelcontextprotocol.io) | [modelcontextprotocol/ruby-sdk](https://github.com/modelcontextprotocol/ruby-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
19| <Icon icon="php" size={24} />   [PHP](https://php.sdk.modelcontextprotocol.io) | [modelcontextprotocol/php-sdk](https://github.com/modelcontextprotocol/php-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
20| <Icon icon="square-k" size={24} />   [Kotlin](https://kotlin.sdk.modelcontextprotocol.io) | [modelcontextprotocol/kotlin-sdk](https://github.com/modelcontextprotocol/kotlin-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
2121 
2222See [SDK Tiering System](/community/sdk-tiers) for details on what each tier means.
2323 

docs/2025-03-26/develop/build-with-agent-skills Changed · +4 / -4 lines

from line 13
1313[`mcp-server-dev` plugin](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/mcp-server-dev).
1414It provides three composing skills:
1515 
16| Skill | Purpose |
17| ------------------ | ----------------------------------------------------------------------------------------------------------------------- |
16| Skill | Purpose |
17| - | - |
1818| `build-mcp-server` | Entry point. Interrogates the use case, picks a deployment model and tool-design pattern, routes to specialized skills. |
19| `build-mcp-app` | Adds interactive UI widgets (forms, pickers, dashboards) rendered inline in chat. |
20| `build-mcpb` | Packages a local stdio server with its runtime so users can install it without Node or Python. |
19| `build-mcp-app` | Adds interactive UI widgets (forms, pickers, dashboards) rendered inline in chat. |
20| `build-mcpb` | Packages a local stdio server with its runtime so users can install it without Node or Python. |
2121 
2222Each skill ships a `SKILL.md` file plus a `references/` folder of supporting
2323material (auth flows, tool-design patterns, widget templates, manifest schemas)

docs/2025-03-26/develop/clients/client-best-practices Changed · +12 / -12 lines

from line 128
128128 
129129When implementing progressive discovery:
130130 
131| Guideline | Rationale |
132| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
133| **Offer multiple detail levels** | Let the model choose between name-only, name-and-description, or full-schema responses. |
134| **Cache tool definitions** | Once fetched from a server, memoize the definition host-side so re-injecting it later doesn't need another `tools/list` round trip. This is separate from what's currently in the model's context. |
135| **Refresh on `list_changed`** | Re-index the search catalog when a server sends `notifications/tools/list_changed`. |
136| **Group tools by server** | Present tools organized by their source server so the model can reason about related capabilities. |
131| Guideline | Rationale |
132| - | - |
133| **Offer multiple detail levels** | Let the model choose between name-only, name-and-description, or full-schema responses. |
134| **Cache tool definitions** | Once fetched from a server, memoize the definition host-side so re-injecting it later doesn't need another `tools/list` round trip. This is separate from what's currently in the model's context. |
135| **Refresh on `list_changed`** | Re-index the search catalog when a server sends `notifications/tools/list_changed`. |
136| **Group tools by server** | Present tools organized by their source server so the model can reason about related capabilities. |
137137 
138138### Interaction with Prompt Caching
139139 
from line 234
234234 
235235The right sandbox depends on the language you want the model to write, your host application's language, and how much isolation you need. The table lists example runtimes rather than endorsements; evaluate maturity for your use case:
236236 
237| Sandboxed language | Runtime / Library | Host language | Approach |
238| ------------------ | ------------------------------------------------------------- | ----------------- | ----------------------------------------------------------------------------------------------- |
239| **JavaScript** | [Deno](https://github.com/denoland/deno), `isolated-vm` | Rust / Node / CLI | V8-based runtimes with fine-grained permissions. Can disable all permissions for full lockdown. |
240| **Python** | [Monty](https://github.com/pydantic/monty) *(experimental)* | Rust | Minimal Python interpreter built for AI use cases. No I/O by default. |
241| **TypeScript** | [pctx](https://github.com/portofcontext/pctx) *(early-stage)* | Python / Rust | Incorporates code mode concepts as a library, with low-level Rust support. |
242| **Any (via Wasm)** | [Wasmtime](https://github.com/bytecodealliance/wasmtime) | Rust / C / Go | Compile any language to Wasm and run it with capability-based security. |
237| Sandboxed language | Runtime / Library | Host language | Approach |
238| - | - | - | - |
239| **JavaScript** | [Deno](https://github.com/denoland/deno), `isolated-vm` | Rust / Node / CLI | V8-based runtimes with fine-grained permissions. Can disable all permissions for full lockdown. |
240| **Python** | [Monty](https://github.com/pydantic/monty) *(experimental)* | Rust | Minimal Python interpreter built for AI use cases. No I/O by default. |
241| **TypeScript** | [pctx](https://github.com/portofcontext/pctx) *(early-stage)* | Python / Rust | Incorporates code mode concepts as a library, with low-level Rust support. |
242| **Any (via Wasm)** | [Wasmtime](https://github.com/bytecodealliance/wasmtime) | Rust / C / Go | Compile any language to Wasm and run it with capability-based security. |
243243 
244244Regardless of sandbox, the integration pattern is the same: the host injects function stubs, intercepts calls over an in-process or stdio channel (so network permissions can stay fully denied), and dispatches them as `tools/call` requests to MCP servers.
245245 

docs/2025-03-26/learn/client-concepts Changed · +3 / -3 lines

from line 8
88 
99In addition to making use of context provided by servers, clients may provide several features to servers. These client features allow server authors to build richer interactions.
1010 
11| Feature | Explanation | Example |
12| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
13| **Roots** | Roots allow clients to specify which directories servers should focus on, communicating intended scope through a coordination mechanism. | A server for booking travel may be given access to a specific directory, from which it can read a user's calendar. |
11| Feature | Explanation | Example |
12| - | - | - |
13| **Roots** | Roots allow clients to specify which directories servers should focus on, communicating intended scope through a coordination mechanism. | A server for booking travel may be given access to a specific directory, from which it can read a user's calendar. |
1414| **Sampling** | Sampling allows servers to request LLM completions through the client, enabling an agentic workflow. This approach puts the client in complete control of user permissions and security measures. | A server for booking travel may send a list of flights to an LLM and request that the LLM pick the best flight for the user. |
1515 
1616### Roots

docs/2025-03-26/learn/server-concepts Changed · +18 / -18 lines

from line 8
88 
99Servers provide functionality through three building blocks:
1010 
11| Feature | Explanation | Examples | Who controls it |
12| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | --------------- |
13| **Tools** | Functions that your LLM can actively call, and decides when to use them based on user requests. Tools can write to databases, call external APIs, modify files, or trigger other logic. | Search flights<br />Send messages<br />Create calendar events | Model |
14| **Resources** | Passive data sources that provide read-only access to information for context, such as file contents, database schemas, or API documentation. | Retrieve documents<br />Access knowledge bases<br />Read calendars | Application |
15| **Prompts** | Pre-built instruction templates that tell the model to work with specific tools and resources. | Plan a vacation<br />Summarize my meetings<br />Draft an email | User |
11| Feature | Explanation | Examples | Who controls it |
12| - | - | - | - |
13| **Tools** | Functions that your LLM can actively call, and decides when to use them based on user requests. Tools can write to databases, call external APIs, modify files, or trigger other logic. | Search flights<br />Send messages<br />Create calendar events | Model |
14| **Resources** | Passive data sources that provide read-only access to information for context, such as file contents, database schemas, or API documentation. | Retrieve documents<br />Access knowledge bases<br />Read calendars | Application |
15| **Prompts** | Pre-built instruction templates that tell the model to work with specific tools and resources. | Plan a vacation<br />Summarize my meetings<br />Draft an email | User |
1616 
1717We will use a hypothetical scenario to demonstrate the role of each of these features, and show how they can work together.
1818 
from line 26
2626 
2727**Protocol operations:**
2828 
29| Method | Purpose | Returns |
30| ------------ | ------------------------ | -------------------------------------- |
29| Method | Purpose | Returns |
30| - | - | - |
3131| `tools/list` | Discover available tools | Array of tool definitions with schemas |
32| `tools/call` | Execute a specific tool | Tool execution result |
32| `tools/call` | Execute a specific tool | Tool execution result |
3333 
3434**Example tool definition:**
3535 
from line 109
109109 
110110**Protocol operations:**
111111 
112| Method | Purpose | Returns |
113| -------------------------- | ------------------------------- | -------------------------------------- |
114| `resources/list` | List available direct resources | Array of resource descriptors |
115| `resources/templates/list` | Discover resource templates | Array of resource template definitions |
116| `resources/read` | Retrieve resource contents | Resource data with metadata |
117| `resources/subscribe` | Monitor resource changes | Subscription confirmation |
112| Method | Purpose | Returns |
113| - | - | - |
114| `resources/list` | List available direct resources | Array of resource descriptors |
115| `resources/templates/list` | Discover resource templates | Array of resource template definitions |
116| `resources/read` | Retrieve resource contents | Resource data with metadata |
117| `resources/subscribe` | Monitor resource changes | Subscription confirmation |
118118 
119119#### Example: Getting Travel Planning Context
120120 
from line 180
180180 
181181**Protocol operations:**
182182 
183| Method | Purpose | Returns |
184| -------------- | -------------------------- | ------------------------------------- |
185| `prompts/list` | Discover available prompts | Array of prompt descriptors |
186| `prompts/get` | Retrieve prompt details | Full prompt definition with arguments |
183| Method | Purpose | Returns |
184| - | - | - |
185| `prompts/list` | Discover available prompts | Array of prompt descriptors |
186| `prompts/get` | Retrieve prompt details | Full prompt definition with arguments |
187187 
188188#### Example: Streamlined Workflows
189189 

docs/2025-03-26/sdk Changed · +12 / -12 lines

from line 6
66 
77## Available SDKs
88 
9| SDK | Repository | Tier |
10| :----------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | ------------------------------------------------: |
11| <Icon icon="square-js" size={24} />   [TypeScript](https://ts.sdk.modelcontextprotocol.io) | [modelcontextprotocol/typescript-sdk](https://github.com/modelcontextprotocol/typescript-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
12| <Icon icon="python" size={24} />   [Python](https://py.sdk.modelcontextprotocol.io) | [modelcontextprotocol/python-sdk](https://github.com/modelcontextprotocol/python-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
13| <Icon icon="square-c" size={24} />   [C#](https://csharp.sdk.modelcontextprotocol.io) | [modelcontextprotocol/csharp-sdk](https://github.com/modelcontextprotocol/csharp-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
14| <Icon icon="golang" size={24} />   [Go](https://go.sdk.modelcontextprotocol.io) | [modelcontextprotocol/go-sdk](https://github.com/modelcontextprotocol/go-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
15| <Icon icon="java" size={24} />   [Java](https://java.sdk.modelcontextprotocol.io) | [modelcontextprotocol/java-sdk](https://github.com/modelcontextprotocol/java-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
16| <Icon icon="rust" size={24} />   [Rust](https://rust.sdk.modelcontextprotocol.io) | [modelcontextprotocol/rust-sdk](https://github.com/modelcontextprotocol/rust-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
17| <Icon icon="swift" size={24} />   Swift | [modelcontextprotocol/swift-sdk](https://github.com/modelcontextprotocol/swift-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
18| <Icon icon="gem" size={24} />   [Ruby](https://ruby.sdk.modelcontextprotocol.io) | [modelcontextprotocol/ruby-sdk](https://github.com/modelcontextprotocol/ruby-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
19| <Icon icon="php" size={24} />   [PHP](https://php.sdk.modelcontextprotocol.io) | [modelcontextprotocol/php-sdk](https://github.com/modelcontextprotocol/php-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
20| <Icon icon="square-k" size={24} />   [Kotlin](https://kotlin.sdk.modelcontextprotocol.io) | [modelcontextprotocol/kotlin-sdk](https://github.com/modelcontextprotocol/kotlin-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
9| SDK | Repository | Tier |
10| :- | :- | -: |
11| <Icon icon="square-js" size={24} />   [TypeScript](https://ts.sdk.modelcontextprotocol.io) | [modelcontextprotocol/typescript-sdk](https://github.com/modelcontextprotocol/typescript-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
12| <Icon icon="python" size={24} />   [Python](https://py.sdk.modelcontextprotocol.io) | [modelcontextprotocol/python-sdk](https://github.com/modelcontextprotocol/python-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
13| <Icon icon="square-c" size={24} />   [C#](https://csharp.sdk.modelcontextprotocol.io) | [modelcontextprotocol/csharp-sdk](https://github.com/modelcontextprotocol/csharp-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
14| <Icon icon="golang" size={24} />   [Go](https://go.sdk.modelcontextprotocol.io) | [modelcontextprotocol/go-sdk](https://github.com/modelcontextprotocol/go-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
15| <Icon icon="java" size={24} />   [Java](https://java.sdk.modelcontextprotocol.io) | [modelcontextprotocol/java-sdk](https://github.com/modelcontextprotocol/java-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
16| <Icon icon="rust" size={24} />   [Rust](https://rust.sdk.modelcontextprotocol.io) | [modelcontextprotocol/rust-sdk](https://github.com/modelcontextprotocol/rust-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
17| <Icon icon="swift" size={24} />   Swift | [modelcontextprotocol/swift-sdk](https://github.com/modelcontextprotocol/swift-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
18| <Icon icon="gem" size={24} />   [Ruby](https://ruby.sdk.modelcontextprotocol.io) | [modelcontextprotocol/ruby-sdk](https://github.com/modelcontextprotocol/ruby-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
19| <Icon icon="php" size={24} />   [PHP](https://php.sdk.modelcontextprotocol.io) | [modelcontextprotocol/php-sdk](https://github.com/modelcontextprotocol/php-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
20| <Icon icon="square-k" size={24} />   [Kotlin](https://kotlin.sdk.modelcontextprotocol.io) | [modelcontextprotocol/kotlin-sdk](https://github.com/modelcontextprotocol/kotlin-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
2121 
2222See [SDK Tiering System](/community/sdk-tiers) for details on what each tier means.
2323 

docs/2025-06-18/develop/build-with-agent-skills Changed · +4 / -4 lines

from line 13
1313[`mcp-server-dev` plugin](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/mcp-server-dev).
1414It provides three composing skills:
1515 
16| Skill | Purpose |
17| ------------------ | ----------------------------------------------------------------------------------------------------------------------- |
16| Skill | Purpose |
17| - | - |
1818| `build-mcp-server` | Entry point. Interrogates the use case, picks a deployment model and tool-design pattern, routes to specialized skills. |
19| `build-mcp-app` | Adds interactive UI widgets (forms, pickers, dashboards) rendered inline in chat. |
20| `build-mcpb` | Packages a local stdio server with its runtime so users can install it without Node or Python. |
19| `build-mcp-app` | Adds interactive UI widgets (forms, pickers, dashboards) rendered inline in chat. |
20| `build-mcpb` | Packages a local stdio server with its runtime so users can install it without Node or Python. |
2121 
2222Each skill ships a `SKILL.md` file plus a `references/` folder of supporting
2323material (auth flows, tool-design patterns, widget templates, manifest schemas)

docs/2025-06-18/develop/clients/client-best-practices Changed · +12 / -12 lines

from line 128
128128 
129129When implementing progressive discovery:
130130 
131| Guideline | Rationale |
132| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
133| **Offer multiple detail levels** | Let the model choose between name-only, name-and-description, or full-schema responses. |
134| **Cache tool definitions** | Once fetched from a server, memoize the definition host-side so re-injecting it later doesn't need another `tools/list` round trip. This is separate from what's currently in the model's context. |
135| **Refresh on `list_changed`** | Re-index the search catalog when a server sends `notifications/tools/list_changed`. |
136| **Group tools by server** | Present tools organized by their source server so the model can reason about related capabilities. |
131| Guideline | Rationale |
132| - | - |
133| **Offer multiple detail levels** | Let the model choose between name-only, name-and-description, or full-schema responses. |
134| **Cache tool definitions** | Once fetched from a server, memoize the definition host-side so re-injecting it later doesn't need another `tools/list` round trip. This is separate from what's currently in the model's context. |
135| **Refresh on `list_changed`** | Re-index the search catalog when a server sends `notifications/tools/list_changed`. |
136| **Group tools by server** | Present tools organized by their source server so the model can reason about related capabilities. |
137137 
138138### Interaction with Prompt Caching
139139 
from line 234
234234 
235235The right sandbox depends on the language you want the model to write, your host application's language, and how much isolation you need. The table lists example runtimes rather than endorsements; evaluate maturity for your use case:
236236 
237| Sandboxed language | Runtime / Library | Host language | Approach |
238| ------------------ | ------------------------------------------------------------- | ----------------- | ----------------------------------------------------------------------------------------------- |
239| **JavaScript** | [Deno](https://github.com/denoland/deno), `isolated-vm` | Rust / Node / CLI | V8-based runtimes with fine-grained permissions. Can disable all permissions for full lockdown. |
240| **Python** | [Monty](https://github.com/pydantic/monty) *(experimental)* | Rust | Minimal Python interpreter built for AI use cases. No I/O by default. |
241| **TypeScript** | [pctx](https://github.com/portofcontext/pctx) *(early-stage)* | Python / Rust | Incorporates code mode concepts as a library, with low-level Rust support. |
242| **Any (via Wasm)** | [Wasmtime](https://github.com/bytecodealliance/wasmtime) | Rust / C / Go | Compile any language to Wasm and run it with capability-based security. |
237| Sandboxed language | Runtime / Library | Host language | Approach |
238| - | - | - | - |
239| **JavaScript** | [Deno](https://github.com/denoland/deno), `isolated-vm` | Rust / Node / CLI | V8-based runtimes with fine-grained permissions. Can disable all permissions for full lockdown. |
240| **Python** | [Monty](https://github.com/pydantic/monty) *(experimental)* | Rust | Minimal Python interpreter built for AI use cases. No I/O by default. |
241| **TypeScript** | [pctx](https://github.com/portofcontext/pctx) *(early-stage)* | Python / Rust | Incorporates code mode concepts as a library, with low-level Rust support. |
242| **Any (via Wasm)** | [Wasmtime](https://github.com/bytecodealliance/wasmtime) | Rust / C / Go | Compile any language to Wasm and run it with capability-based security. |
243243 
244244Regardless of sandbox, the integration pattern is the same: the host injects function stubs, intercepts calls over an in-process or stdio channel (so network permissions can stay fully denied), and dispatches them as `tools/call` requests to MCP servers.
245245 

docs/2025-06-18/learn/client-concepts Changed · +5 / -5 lines

from line 8
88 
99In addition to making use of context provided by servers, clients may provide several features to servers. These client features allow server authors to build richer interactions.
1010 
11| Feature | Explanation | Example |
12| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
13| **Elicitation** | Elicitation enables servers to request specific information from users during interactions, providing a structured way for servers to gather information on demand. | A server booking travel may ask for the user's preferences on airplane seats, room type or their contact number to finalise a booking. |
14| **Roots** | Roots allow clients to specify which directories servers should focus on, communicating intended scope through a coordination mechanism. | A server for booking travel may be given access to a specific directory, from which it can read a user's calendar. |
15| **Sampling** | Sampling allows servers to request LLM completions through the client, enabling an agentic workflow. This approach puts the client in complete control of user permissions and security measures. | A server for booking travel may send a list of flights to an LLM and request that the LLM pick the best flight for the user. |
11| Feature | Explanation | Example |
12| - | - | - |
13| **Elicitation** | Elicitation enables servers to request specific information from users during interactions, providing a structured way for servers to gather information on demand. | A server booking travel may ask for the user's preferences on airplane seats, room type or their contact number to finalise a booking. |
14| **Roots** | Roots allow clients to specify which directories servers should focus on, communicating intended scope through a coordination mechanism. | A server for booking travel may be given access to a specific directory, from which it can read a user's calendar. |
15| **Sampling** | Sampling allows servers to request LLM completions through the client, enabling an agentic workflow. This approach puts the client in complete control of user permissions and security measures. | A server for booking travel may send a list of flights to an LLM and request that the LLM pick the best flight for the user. |
1616 
1717### Elicitation
1818 

docs/2025-06-18/learn/server-concepts Changed · +18 / -18 lines

from line 8
88 
99Servers provide functionality through three building blocks:
1010 
11| Feature | Explanation | Examples | Who controls it |
12| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | --------------- |
13| **Tools** | Functions that your LLM can actively call, and decides when to use them based on user requests. Tools can write to databases, call external APIs, modify files, or trigger other logic. | Search flights<br />Send messages<br />Create calendar events | Model |
14| **Resources** | Passive data sources that provide read-only access to information for context, such as file contents, database schemas, or API documentation. | Retrieve documents<br />Access knowledge bases<br />Read calendars | Application |
15| **Prompts** | Pre-built instruction templates that tell the model to work with specific tools and resources. | Plan a vacation<br />Summarize my meetings<br />Draft an email | User |
11| Feature | Explanation | Examples | Who controls it |
12| - | - | - | - |
13| **Tools** | Functions that your LLM can actively call, and decides when to use them based on user requests. Tools can write to databases, call external APIs, modify files, or trigger other logic. | Search flights<br />Send messages<br />Create calendar events | Model |
14| **Resources** | Passive data sources that provide read-only access to information for context, such as file contents, database schemas, or API documentation. | Retrieve documents<br />Access knowledge bases<br />Read calendars | Application |
15| **Prompts** | Pre-built instruction templates that tell the model to work with specific tools and resources. | Plan a vacation<br />Summarize my meetings<br />Draft an email | User |
1616 
1717We will use a hypothetical scenario to demonstrate the role of each of these features, and show how they can work together.
1818 
from line 26
2626 
2727**Protocol operations:**
2828 
29| Method | Purpose | Returns |
30| ------------ | ------------------------ | -------------------------------------- |
29| Method | Purpose | Returns |
30| - | - | - |
3131| `tools/list` | Discover available tools | Array of tool definitions with schemas |
32| `tools/call` | Execute a specific tool | Tool execution result |
32| `tools/call` | Execute a specific tool | Tool execution result |
3333 
3434**Example tool definition:**
3535 
from line 109
109109 
110110**Protocol operations:**
111111 
112| Method | Purpose | Returns |
113| -------------------------- | ------------------------------- | -------------------------------------- |
114| `resources/list` | List available direct resources | Array of resource descriptors |
115| `resources/templates/list` | Discover resource templates | Array of resource template definitions |
116| `resources/read` | Retrieve resource contents | Resource data with metadata |
117| `resources/subscribe` | Monitor resource changes | Subscription confirmation |
112| Method | Purpose | Returns |
113| - | - | - |
114| `resources/list` | List available direct resources | Array of resource descriptors |
115| `resources/templates/list` | Discover resource templates | Array of resource template definitions |
116| `resources/read` | Retrieve resource contents | Resource data with metadata |
117| `resources/subscribe` | Monitor resource changes | Subscription confirmation |
118118 
119119#### Example: Getting Travel Planning Context
120120 
from line 180
180180 
181181**Protocol operations:**
182182 
183| Method | Purpose | Returns |
184| -------------- | -------------------------- | ------------------------------------- |
185| `prompts/list` | Discover available prompts | Array of prompt descriptors |
186| `prompts/get` | Retrieve prompt details | Full prompt definition with arguments |
183| Method | Purpose | Returns |
184| - | - | - |
185| `prompts/list` | Discover available prompts | Array of prompt descriptors |
186| `prompts/get` | Retrieve prompt details | Full prompt definition with arguments |
187187 
188188#### Example: Streamlined Workflows
189189 

docs/2025-06-18/sdk Changed · +12 / -12 lines

from line 6
66 
77## Available SDKs
88 
9| SDK | Repository | Tier |
10| :----------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | ------------------------------------------------: |
11| <Icon icon="square-js" size={24} />   [TypeScript](https://ts.sdk.modelcontextprotocol.io) | [modelcontextprotocol/typescript-sdk](https://github.com/modelcontextprotocol/typescript-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
12| <Icon icon="python" size={24} />   [Python](https://py.sdk.modelcontextprotocol.io) | [modelcontextprotocol/python-sdk](https://github.com/modelcontextprotocol/python-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
13| <Icon icon="square-c" size={24} />   [C#](https://csharp.sdk.modelcontextprotocol.io) | [modelcontextprotocol/csharp-sdk](https://github.com/modelcontextprotocol/csharp-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
14| <Icon icon="golang" size={24} />   [Go](https://go.sdk.modelcontextprotocol.io) | [modelcontextprotocol/go-sdk](https://github.com/modelcontextprotocol/go-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
15| <Icon icon="java" size={24} />   [Java](https://java.sdk.modelcontextprotocol.io) | [modelcontextprotocol/java-sdk](https://github.com/modelcontextprotocol/java-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
16| <Icon icon="rust" size={24} />   [Rust](https://rust.sdk.modelcontextprotocol.io) | [modelcontextprotocol/rust-sdk](https://github.com/modelcontextprotocol/rust-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
17| <Icon icon="swift" size={24} />   Swift | [modelcontextprotocol/swift-sdk](https://github.com/modelcontextprotocol/swift-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
18| <Icon icon="gem" size={24} />   [Ruby](https://ruby.sdk.modelcontextprotocol.io) | [modelcontextprotocol/ruby-sdk](https://github.com/modelcontextprotocol/ruby-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
19| <Icon icon="php" size={24} />   [PHP](https://php.sdk.modelcontextprotocol.io) | [modelcontextprotocol/php-sdk](https://github.com/modelcontextprotocol/php-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
20| <Icon icon="square-k" size={24} />   [Kotlin](https://kotlin.sdk.modelcontextprotocol.io) | [modelcontextprotocol/kotlin-sdk](https://github.com/modelcontextprotocol/kotlin-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
9| SDK | Repository | Tier |
10| :- | :- | -: |
11| <Icon icon="square-js" size={24} />   [TypeScript](https://ts.sdk.modelcontextprotocol.io) | [modelcontextprotocol/typescript-sdk](https://github.com/modelcontextprotocol/typescript-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
12| <Icon icon="python" size={24} />   [Python](https://py.sdk.modelcontextprotocol.io) | [modelcontextprotocol/python-sdk](https://github.com/modelcontextprotocol/python-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
13| <Icon icon="square-c" size={24} />   [C#](https://csharp.sdk.modelcontextprotocol.io) | [modelcontextprotocol/csharp-sdk](https://github.com/modelcontextprotocol/csharp-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
14| <Icon icon="golang" size={24} />   [Go](https://go.sdk.modelcontextprotocol.io) | [modelcontextprotocol/go-sdk](https://github.com/modelcontextprotocol/go-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
15| <Icon icon="java" size={24} />   [Java](https://java.sdk.modelcontextprotocol.io) | [modelcontextprotocol/java-sdk](https://github.com/modelcontextprotocol/java-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
16| <Icon icon="rust" size={24} />   [Rust](https://rust.sdk.modelcontextprotocol.io) | [modelcontextprotocol/rust-sdk](https://github.com/modelcontextprotocol/rust-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
17| <Icon icon="swift" size={24} />   Swift | [modelcontextprotocol/swift-sdk](https://github.com/modelcontextprotocol/swift-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
18| <Icon icon="gem" size={24} />   [Ruby](https://ruby.sdk.modelcontextprotocol.io) | [modelcontextprotocol/ruby-sdk](https://github.com/modelcontextprotocol/ruby-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
19| <Icon icon="php" size={24} />   [PHP](https://php.sdk.modelcontextprotocol.io) | [modelcontextprotocol/php-sdk](https://github.com/modelcontextprotocol/php-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
20| <Icon icon="square-k" size={24} />   [Kotlin](https://kotlin.sdk.modelcontextprotocol.io) | [modelcontextprotocol/kotlin-sdk](https://github.com/modelcontextprotocol/kotlin-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
2121 
2222See [SDK Tiering System](/community/sdk-tiers) for details on what each tier means.
2323 

docs/2025-11-25/develop/build-with-agent-skills Changed · +4 / -4 lines

from line 13
1313[`mcp-server-dev` plugin](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/mcp-server-dev).
1414It provides three composing skills:
1515 
16| Skill | Purpose |
17| ------------------ | ----------------------------------------------------------------------------------------------------------------------- |
16| Skill | Purpose |
17| - | - |
1818| `build-mcp-server` | Entry point. Interrogates the use case, picks a deployment model and tool-design pattern, routes to specialized skills. |
19| `build-mcp-app` | Adds interactive UI widgets (forms, pickers, dashboards) rendered inline in chat. |
20| `build-mcpb` | Packages a local stdio server with its runtime so users can install it without Node or Python. |
19| `build-mcp-app` | Adds interactive UI widgets (forms, pickers, dashboards) rendered inline in chat. |
20| `build-mcpb` | Packages a local stdio server with its runtime so users can install it without Node or Python. |
2121 
2222Each skill ships a `SKILL.md` file plus a `references/` folder of supporting
2323material (auth flows, tool-design patterns, widget templates, manifest schemas)

docs/2025-11-25/develop/clients/client-best-practices Changed · +12 / -12 lines

from line 128
128128 
129129When implementing progressive discovery:
130130 
131| Guideline | Rationale |
132| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
133| **Offer multiple detail levels** | Let the model choose between name-only, name-and-description, or full-schema responses. |
134| **Cache tool definitions** | Once fetched from a server, memoize the definition host-side so re-injecting it later doesn't need another `tools/list` round trip. This is separate from what's currently in the model's context. |
135| **Refresh on `list_changed`** | Re-index the search catalog when a server sends `notifications/tools/list_changed`. |
136| **Group tools by server** | Present tools organized by their source server so the model can reason about related capabilities. |
131| Guideline | Rationale |
132| - | - |
133| **Offer multiple detail levels** | Let the model choose between name-only, name-and-description, or full-schema responses. |
134| **Cache tool definitions** | Once fetched from a server, memoize the definition host-side so re-injecting it later doesn't need another `tools/list` round trip. This is separate from what's currently in the model's context. |
135| **Refresh on `list_changed`** | Re-index the search catalog when a server sends `notifications/tools/list_changed`. |
136| **Group tools by server** | Present tools organized by their source server so the model can reason about related capabilities. |
137137 
138138### Interaction with Prompt Caching
139139 
from line 234
234234 
235235The right sandbox depends on the language you want the model to write, your host application's language, and how much isolation you need. The table lists example runtimes rather than endorsements; evaluate maturity for your use case:
236236 
237| Sandboxed language | Runtime / Library | Host language | Approach |
238| ------------------ | ------------------------------------------------------------- | ----------------- | ----------------------------------------------------------------------------------------------- |
239| **JavaScript** | [Deno](https://github.com/denoland/deno), `isolated-vm` | Rust / Node / CLI | V8-based runtimes with fine-grained permissions. Can disable all permissions for full lockdown. |
240| **Python** | [Monty](https://github.com/pydantic/monty) *(experimental)* | Rust | Minimal Python interpreter built for AI use cases. No I/O by default. |
241| **TypeScript** | [pctx](https://github.com/portofcontext/pctx) *(early-stage)* | Python / Rust | Incorporates code mode concepts as a library, with low-level Rust support. |
242| **Any (via Wasm)** | [Wasmtime](https://github.com/bytecodealliance/wasmtime) | Rust / C / Go | Compile any language to Wasm and run it with capability-based security. |
237| Sandboxed language | Runtime / Library | Host language | Approach |
238| - | - | - | - |
239| **JavaScript** | [Deno](https://github.com/denoland/deno), `isolated-vm` | Rust / Node / CLI | V8-based runtimes with fine-grained permissions. Can disable all permissions for full lockdown. |
240| **Python** | [Monty](https://github.com/pydantic/monty) *(experimental)* | Rust | Minimal Python interpreter built for AI use cases. No I/O by default. |
241| **TypeScript** | [pctx](https://github.com/portofcontext/pctx) *(early-stage)* | Python / Rust | Incorporates code mode concepts as a library, with low-level Rust support. |
242| **Any (via Wasm)** | [Wasmtime](https://github.com/bytecodealliance/wasmtime) | Rust / C / Go | Compile any language to Wasm and run it with capability-based security. |
243243 
244244Regardless of sandbox, the integration pattern is the same: the host injects function stubs, intercepts calls over an in-process or stdio channel (so network permissions can stay fully denied), and dispatches them as `tools/call` requests to MCP servers.
245245 

docs/2025-11-25/learn/client-concepts Changed · +5 / -5 lines

from line 8
88 
99In addition to making use of context provided by servers, clients may provide several features to servers. These client features allow server authors to build richer interactions.
1010 
11| Feature | Explanation | Example |
12| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
13| **Elicitation** | Elicitation enables servers to request specific information from users during interactions, providing a structured way for servers to gather information on demand. | A server booking travel may ask for the user's preferences on airplane seats, room type or their contact number to finalise a booking. |
14| **Roots** | Roots allow clients to specify which directories servers should focus on, communicating intended scope through a coordination mechanism. | A server for booking travel may be given access to a specific directory, from which it can read a user's calendar. |
15| **Sampling** | Sampling allows servers to request LLM completions through the client, enabling an agentic workflow. This approach puts the client in complete control of user permissions and security measures. | A server for booking travel may send a list of flights to an LLM and request that the LLM pick the best flight for the user. |
11| Feature | Explanation | Example |
12| - | - | - |
13| **Elicitation** | Elicitation enables servers to request specific information from users during interactions, providing a structured way for servers to gather information on demand. | A server booking travel may ask for the user's preferences on airplane seats, room type or their contact number to finalise a booking. |
14| **Roots** | Roots allow clients to specify which directories servers should focus on, communicating intended scope through a coordination mechanism. | A server for booking travel may be given access to a specific directory, from which it can read a user's calendar. |
15| **Sampling** | Sampling allows servers to request LLM completions through the client, enabling an agentic workflow. This approach puts the client in complete control of user permissions and security measures. | A server for booking travel may send a list of flights to an LLM and request that the LLM pick the best flight for the user. |
1616 
1717### Elicitation
1818 

docs/2025-11-25/learn/server-concepts Changed · +18 / -18 lines

from line 8
88 
99Servers provide functionality through three building blocks:
1010 
11| Feature | Explanation | Examples | Who controls it |
12| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | --------------- |
13| **Tools** | Functions that your LLM can actively call, and decides when to use them based on user requests. Tools can write to databases, call external APIs, modify files, or trigger other logic. | Search flights<br />Send messages<br />Create calendar events | Model |
14| **Resources** | Passive data sources that provide read-only access to information for context, such as file contents, database schemas, or API documentation. | Retrieve documents<br />Access knowledge bases<br />Read calendars | Application |
15| **Prompts** | Pre-built instruction templates that tell the model to work with specific tools and resources. | Plan a vacation<br />Summarize my meetings<br />Draft an email | User |
11| Feature | Explanation | Examples | Who controls it |
12| - | - | - | - |
13| **Tools** | Functions that your LLM can actively call, and decides when to use them based on user requests. Tools can write to databases, call external APIs, modify files, or trigger other logic. | Search flights<br />Send messages<br />Create calendar events | Model |
14| **Resources** | Passive data sources that provide read-only access to information for context, such as file contents, database schemas, or API documentation. | Retrieve documents<br />Access knowledge bases<br />Read calendars | Application |
15| **Prompts** | Pre-built instruction templates that tell the model to work with specific tools and resources. | Plan a vacation<br />Summarize my meetings<br />Draft an email | User |
1616 
1717We will use a hypothetical scenario to demonstrate the role of each of these features, and show how they can work together.
1818 
from line 26
2626 
2727**Protocol operations:**
2828 
29| Method | Purpose | Returns |
30| ------------ | ------------------------ | -------------------------------------- |
29| Method | Purpose | Returns |
30| - | - | - |
3131| `tools/list` | Discover available tools | Array of tool definitions with schemas |
32| `tools/call` | Execute a specific tool | Tool execution result |
32| `tools/call` | Execute a specific tool | Tool execution result |
3333 
3434**Example tool definition:**
3535 
from line 109
109109 
110110**Protocol operations:**
111111 
112| Method | Purpose | Returns |
113| -------------------------- | ------------------------------- | -------------------------------------- |
114| `resources/list` | List available direct resources | Array of resource descriptors |
115| `resources/templates/list` | Discover resource templates | Array of resource template definitions |
116| `resources/read` | Retrieve resource contents | Resource data with metadata |
117| `resources/subscribe` | Monitor resource changes | Subscription confirmation |
112| Method | Purpose | Returns |
113| - | - | - |
114| `resources/list` | List available direct resources | Array of resource descriptors |
115| `resources/templates/list` | Discover resource templates | Array of resource template definitions |
116| `resources/read` | Retrieve resource contents | Resource data with metadata |
117| `resources/subscribe` | Monitor resource changes | Subscription confirmation |
118118 
119119#### Example: Getting Travel Planning Context
120120 
from line 180
180180 
181181**Protocol operations:**
182182 
183| Method | Purpose | Returns |
184| -------------- | -------------------------- | ------------------------------------- |
185| `prompts/list` | Discover available prompts | Array of prompt descriptors |
186| `prompts/get` | Retrieve prompt details | Full prompt definition with arguments |
183| Method | Purpose | Returns |
184| - | - | - |
185| `prompts/list` | Discover available prompts | Array of prompt descriptors |
186| `prompts/get` | Retrieve prompt details | Full prompt definition with arguments |
187187 
188188#### Example: Streamlined Workflows
189189 

docs/2025-11-25/sdk Changed · +12 / -12 lines

from line 6
66 
77## Available SDKs
88 
9| SDK | Repository | Tier |
10| :----------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | ------------------------------------------------: |
11| <Icon icon="square-js" size={24} />   [TypeScript](https://ts.sdk.modelcontextprotocol.io) | [modelcontextprotocol/typescript-sdk](https://github.com/modelcontextprotocol/typescript-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
12| <Icon icon="python" size={24} />   [Python](https://py.sdk.modelcontextprotocol.io) | [modelcontextprotocol/python-sdk](https://github.com/modelcontextprotocol/python-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
13| <Icon icon="square-c" size={24} />   [C#](https://csharp.sdk.modelcontextprotocol.io) | [modelcontextprotocol/csharp-sdk](https://github.com/modelcontextprotocol/csharp-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
14| <Icon icon="golang" size={24} />   [Go](https://go.sdk.modelcontextprotocol.io) | [modelcontextprotocol/go-sdk](https://github.com/modelcontextprotocol/go-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
15| <Icon icon="java" size={24} />   [Java](https://java.sdk.modelcontextprotocol.io) | [modelcontextprotocol/java-sdk](https://github.com/modelcontextprotocol/java-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
16| <Icon icon="rust" size={24} />   [Rust](https://rust.sdk.modelcontextprotocol.io) | [modelcontextprotocol/rust-sdk](https://github.com/modelcontextprotocol/rust-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
17| <Icon icon="swift" size={24} />   Swift | [modelcontextprotocol/swift-sdk](https://github.com/modelcontextprotocol/swift-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
18| <Icon icon="gem" size={24} />   [Ruby](https://ruby.sdk.modelcontextprotocol.io) | [modelcontextprotocol/ruby-sdk](https://github.com/modelcontextprotocol/ruby-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
19| <Icon icon="php" size={24} />   [PHP](https://php.sdk.modelcontextprotocol.io) | [modelcontextprotocol/php-sdk](https://github.com/modelcontextprotocol/php-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
20| <Icon icon="square-k" size={24} />   [Kotlin](https://kotlin.sdk.modelcontextprotocol.io) | [modelcontextprotocol/kotlin-sdk](https://github.com/modelcontextprotocol/kotlin-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
9| SDK | Repository | Tier |
10| :- | :- | -: |
11| <Icon icon="square-js" size={24} />   [TypeScript](https://ts.sdk.modelcontextprotocol.io) | [modelcontextprotocol/typescript-sdk](https://github.com/modelcontextprotocol/typescript-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
12| <Icon icon="python" size={24} />   [Python](https://py.sdk.modelcontextprotocol.io) | [modelcontextprotocol/python-sdk](https://github.com/modelcontextprotocol/python-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
13| <Icon icon="square-c" size={24} />   [C#](https://csharp.sdk.modelcontextprotocol.io) | [modelcontextprotocol/csharp-sdk](https://github.com/modelcontextprotocol/csharp-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
14| <Icon icon="golang" size={24} />   [Go](https://go.sdk.modelcontextprotocol.io) | [modelcontextprotocol/go-sdk](https://github.com/modelcontextprotocol/go-sdk) | <Badge color="blue" shape="pill">Tier 1</Badge> |
15| <Icon icon="java" size={24} />   [Java](https://java.sdk.modelcontextprotocol.io) | [modelcontextprotocol/java-sdk](https://github.com/modelcontextprotocol/java-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
16| <Icon icon="rust" size={24} />   [Rust](https://rust.sdk.modelcontextprotocol.io) | [modelcontextprotocol/rust-sdk](https://github.com/modelcontextprotocol/rust-sdk) | <Badge color="purple" shape="pill">Tier 2</Badge> |
17| <Icon icon="swift" size={24} />   Swift | [modelcontextprotocol/swift-sdk](https://github.com/modelcontextprotocol/swift-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
18| <Icon icon="gem" size={24} />   [Ruby](https://ruby.sdk.modelcontextprotocol.io) | [modelcontextprotocol/ruby-sdk](https://github.com/modelcontextprotocol/ruby-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
19| <Icon icon="php" size={24} />   [PHP](https://php.sdk.modelcontextprotocol.io) | [modelcontextprotocol/php-sdk](https://github.com/modelcontextprotocol/php-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
20| <Icon icon="square-k" size={24} />   [Kotlin](https://kotlin.sdk.modelcontextprotocol.io) | [modelcontextprotocol/kotlin-sdk](https://github.com/modelcontextprotocol/kotlin-sdk) | <Badge color="orange" shape="pill">Tier 3</Badge> |
2121 
2222See [SDK Tiering System](/community/sdk-tiers) for details on what each tier means.
2323 

docs/2026-07-28/develop/build-with-agent-skills Changed · +4 / -4 lines

from line 13
1313[`mcp-server-dev` plugin](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/mcp-server-dev).
1414It provides three composing skills:
1515 
16| Skill | Purpose |
17| ------------------ | ----------------------------------------------------------------------------------------------------------------------- |
16| Skill | Purpose |
17| - | - |
1818| `build-mcp-server` | Entry point. Interrogates the use case, picks a deployment model and tool-design pattern, routes to specialized skills. |
19| `build-mcp-app` | Adds interactive UI widgets (forms, pickers, dashboards) rendered inline in chat. |
20| `build-mcpb` | Packages a local stdio server with its runtime so users can install it without Node or Python. |
19| `build-mcp-app` | Adds interactive UI widgets (forms, pickers, dashboards) rendered inline in chat. |
20| `build-mcpb` | Packages a local stdio server with its runtime so users can install it without Node or Python. |
2121 
2222Each skill ships a `SKILL.md` file plus a `references/` folder of supporting
2323material (auth flows, tool-design patterns, widget templates, manifest schemas)

docs/2026-07-28/develop/clients/client-best-practices Changed · +12 / -12 lines

from line 129
129129 
130130When implementing progressive discovery:
131131 
132| Guideline | Rationale |
133| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
134| **Offer multiple detail levels** | Let the model choose between name-only, name-and-description, or full-schema responses. |
135| **Cache tool definitions** | Once fetched from a server, memoize the definition host-side so re-injecting it later doesn't need another `tools/list` round trip. This is separate from what's currently in the model's context. |
136| **Refresh on `list_changed`** | Re-index the search catalog when a server sends `notifications/tools/list_changed`. |
137| **Group tools by server** | Present tools organized by their source server so the model can reason about related capabilities. |
132| Guideline | Rationale |
133| - | - |
134| **Offer multiple detail levels** | Let the model choose between name-only, name-and-description, or full-schema responses. |
135| **Cache tool definitions** | Once fetched from a server, memoize the definition host-side so re-injecting it later doesn't need another `tools/list` round trip. This is separate from what's currently in the model's context. |
136| **Refresh on `list_changed`** | Re-index the search catalog when a server sends `notifications/tools/list_changed`. |
137| **Group tools by server** | Present tools organized by their source server so the model can reason about related capabilities. |
138138 
139139### Caching
140140 
from line 243
243243 
244244The right sandbox depends on the language you want the model to write, your host application's language, and how much isolation you need. The table lists example runtimes rather than endorsements; evaluate maturity for your use case:
245245 
246| Sandboxed language | Runtime / Library | Host language | Approach |
247| ------------------ | ------------------------------------------------------------- | ----------------- | ----------------------------------------------------------------------------------------------- |
248| **JavaScript** | [Deno](https://github.com/denoland/deno), `isolated-vm` | Rust / Node / CLI | V8-based runtimes with fine-grained permissions. Can disable all permissions for full lockdown. |
249| **Python** | [Monty](https://github.com/pydantic/monty) *(experimental)* | Rust | Minimal Python interpreter built for AI use cases. No I/O by default. |
250| **TypeScript** | [pctx](https://github.com/portofcontext/pctx) *(early-stage)* | Python / Rust | Incorporates code mode concepts as a library, with low-level Rust support. |
251| **Any (via Wasm)** | [Wasmtime](https://github.com/bytecodealliance/wasmtime) | Rust / C / Go | Compile any language to Wasm and run it with capability-based security. |
246| Sandboxed language | Runtime / Library | Host language | Approach |
247| - | - | - | - |
248| **JavaScript** | [Deno](https://github.com/denoland/deno), `isolated-vm` | Rust / Node / CLI | V8-based runtimes with fine-grained permissions. Can disable all permissions for full lockdown. |
249| **Python** | [Monty](https://github.com/pydantic/monty) *(experimental)* | Rust | Minimal Python interpreter built for AI use cases. No I/O by default. |
250| **TypeScript** | [pctx](https://github.com/portofcontext/pctx) *(early-stage)* | Python / Rust | Incorporates code mode concepts as a library, with low-level Rust support. |
251| **Any (via Wasm)** | [Wasmtime](https://github.com/bytecodealliance/wasmtime) | Rust / C / Go | Compile any language to Wasm and run it with capability-based security. |
252252 
253253Regardless of sandbox, the integration pattern is the same: the host injects function stubs, intercepts calls over an in-process or stdio channel (so network permissions can stay fully denied), and dispatches them as `tools/call` requests to MCP servers.
254254 
Feedback