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
1-25 of 295, page 1 of 12This capture is too large to show at once. Changes 1-25 of 295 are below, significant first; the rest are on the following screens.
community/communication Changed · +5 / -5 lines
from line 27
2727**Primary use cases:**
2828
2929* SDK and tooling development (e.g., `#typescript-sdk-dev`, `#inspector-dev`)
30* [Working Group and Interest Group](/community/working-interest-groups) discussions (e.g., `#auth-wg`, `#security-ig`)
30* [Working Group and Interest Group](/community/working-interest-groups.md) discussions (e.g., `#auth-wg`, `#security-ig`)
3131* Community onboarding and contribution guidance
3232* Community feedback and collaborative brainstorming
3333* Public office hours and maintainer availability
from line 79
7979* CI/CD problems and infrastructure issues
8080* Release tasks and milestone tracking
8181
82**Note:** SEP proposals are submitted as pull requests to the [`seps/` directory](https://github.com/modelcontextprotocol/modelcontextprotocol/tree/main/seps), not as GitHub Issues. See the [SEP Guidelines](/community/sep-guidelines).
82**Note:** SEP proposals are submitted as pull requests to the [`seps/` directory](https://github.com/modelcontextprotocol/modelcontextprotocol/tree/main/seps), not as GitHub Issues. See the [SEP Guidelines](/community/sep-guidelines.md).
8383
8484## Security Issues
8585
from line 86
8686**Do not post security issues publicly.**
8787
88881. Use the private security reporting process in [SECURITY.md](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SECURITY.md)
892. Contact Lead or [Core Maintainers](/community/governance#current-core-maintainers) directly
892. Contact Lead or [Core Maintainers](/community/governance.md#current-core-maintainers) directly
90903. Follow responsible disclosure guidelines
9191
9292## Decision Records
from line 96
9696| Type | Location |
9797| - | - |
9898| Technical decisions | [GitHub Issues](https://github.com/modelcontextprotocol/modelcontextprotocol/issues) and SEPs |
99| Specification changes | [Changelog](https://modelcontextprotocol.io/specification/draft/changelog) |
100| Process changes | [Community documentation](https://modelcontextprotocol.io/community/governance) |
99| Specification changes | [Changelog](https://modelcontextprotocol.io/specification/draft/changelog.md) |
100| Process changes | [Community documentation](https://modelcontextprotocol.io/community/governance.md) |
101101| Governance decisions | [GitHub Issues](https://github.com/modelcontextprotocol/modelcontextprotocol/issues) and SEPs |
102102
103103When documenting decisions, we retain as much context as possible:
community/contributing Changed · +17 / -17 lines
from line 12
1212You don't need to have a change ready to get involved. Join the
1313[MCP Contributor Discord](https://discord.gg/6CSzBmMkjX) to connect with contributors and
1414maintainers, ask questions, and find out where help is needed. See the
15[Contributor Communication](/community/communication) guide for all channels - including
15[Contributor Communication](/community/communication.md) guide for all channels - including
1616[live calls](https://meet.modelcontextprotocol.io/) and GitHub Discussions - and when to use
1717each one, or jump to [Getting Help](#getting-help) below.
1818
from line 62
6262
6363Throughout this guide, **specification repository** refers to
6464`modelcontextprotocol/modelcontextprotocol`, which contains the protocol spec, this documentation
65site, and [Spec Enhancement Proposals (SEPs)](/community/sep-guidelines).
65site, and [Spec Enhancement Proposals (SEPs)](/community/sep-guidelines.md).
6666
6767### Project Roles
6868
69MCP follows a [governance model](/community/governance) with different levels of responsibility:
69MCP follows a [governance model](/community/governance.md) with different levels of responsibility:
7070
7171* **Contributors** - Anyone who files issues, submits PRs, or participates in discussions (that's
7272 you!)
7373* **Maintainers** - Steward specific areas like SDKs, documentation, or
74 [Working Groups](/community/working-interest-groups)
74 [Working Groups](/community/working-interest-groups.md)
7575* **Core Maintainers** - Guide overall project direction, review SEPs, and oversee the specification
7676
7777You can find the current list of maintainers in the
from line 222
222222> [!TIP]
223223>
224224> Not sure which category your change falls into? Ask in the [MCP Contributor
225> Discord](/community/communication#discord) before starting any significant
225> Discord](/community/communication.md#discord) before starting any significant
226226> work.
227227
228228### Small Changes (Direct PR)
from line 238
238238### Major Changes (SEP Required)
239239
240240Anything that changes the MCP specification requires following the
241[Specification Enhancement Proposal (SEP)](/community/sep-guidelines) process. This includes, but
241[Specification Enhancement Proposal (SEP)](/community/sep-guidelines.md) process. This includes, but
242242is not limited to:
243243
244244* New protocol features or API methods
from line 325
325325
326326### Major Protocol Changes
327327
328For significant changes, follow the [SEP process](/community/sep-guidelines). Prior to spending a
328For significant changes, follow the [SEP process](/community/sep-guidelines.md). Prior to spending a
329329lot of time on a spec proposal, make sure to follow these best practices.
330330
331331**1. Validate your idea first**
332332
333Discuss in an [Interest Group](/community/working-interest-groups) or on
333Discuss in an [Interest Group](/community/working-interest-groups.md) or on
334334[Discord](https://discord.gg/6CSzBmMkjX).
335335
336336**2. Build a prototype**
from line 346
346346
347347**4. Write the SEP**
348348
349Follow the [SEP Guidelines](/community/sep-guidelines).
349Follow the [SEP Guidelines](/community/sep-guidelines.md).
350350
351351### Finding a Sponsor for SEPs
352352
from line 451
451451
452452Got questions or need guidance? The MCP community is here to help.
453453
454* **[Discord](/community/communication#discord)** - Real-time discussion with contributors and
454* **[Discord](/community/communication.md#discord)** - Real-time discussion with contributors and
455455 maintainers, focused on MCP contributions (not general MCP support)
456456* **[GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions)**
457457 \- Exploration and conversation: **feature requests**, questions, roadmap planning, and proposals
from line 462
462462
463463This separation helps maintainers focus on work that's ready for implementation while giving ideas
464464room to develop. If you're unsure whether something is ready to be an issue, start with a
465discussion. For a complete guide, see our [Contributor Communication](/community/communication)
465discussion. For a complete guide, see our [Contributor Communication](/community/communication.md)
466466documentation.
467467
468For protocol discussions, join [Working Group](/community/working-interest-groups) channels like
468For protocol discussions, join [Working Group](/community/working-interest-groups.md) channels like
469469`#auth-wg` or `#server-identity-wg`. For SDK help, find your language's channel (e.g.,
470470`#typescript-sdk-dev`).
471471
from line 473
473473
474474Sometimes things don't go as planned - that's completely normal! Here are solutions to common
475475issues. If you're still stuck, don't hesitate to ask for help in
476[Discord](/community/communication#discord). The community is friendly and happy to help you get
476[Discord](/community/communication.md#discord). The community is friendly and happy to help you get
477477unstuck.
478478
479479### `npm run check` fails
from line 525
525525Building your own MCP servers, clients, or tools is **not** covered here. For guidance on building
526526with MCP, see our documentation:
527527
528* [Build a Server](/docs/develop/build-server)
529* [Build a Client](/docs/develop/build-client)
530* [Example Servers](/examples)
528* [Build a Server](/docs/develop/build-server.md)
529* [Build a Client](/docs/develop/build-client.md)
530* [Example Servers](/examples.md)
531531
532532If you build something you'd like to share with the community, you can submit it to the
533[MCP Registry](/registry/about).
533[MCP Registry](/registry/about.md).
534534
535535## AI Contributions
536536
community/contributor-ladder Changed · +6 / -6 lines
from line 4
44
55The Model Context Protocol contributor ladder defines roles, responsibilities, and advancement criteria for the project. It shows community members how to grow their involvement from a first contribution to project leadership.
66
7This document implements [SEP-2148](/seps/2148-contributor-ladder). For Working Group and Interest Group governance, see [SEP-2149](/seps/2149-working-group-charter-template).
7This document implements [SEP-2148](/seps/2148-contributor-ladder.md). For Working Group and Interest Group governance, see [SEP-2149](/seps/2149-working-group-charter-template.md).
88
99## Guiding Principles
1010
from line 41
4141
4242**Getting started:**
4343
44* Review the [Contributing Guide](/community/contributing)
44* Review the [Contributing Guide](/community/contributing.md)
4545* Join community channels (Discord, GitHub Discussions)
4646* Look for issues tagged `good-first-issue` or `help-wanted`
4747* Attend working group meetings
from line 168
168168**Privileges:**
169169
170170* Final approval on breaking changes and major spec revisions
171* Voting rights on [SEPs](/community/sep-guidelines)
171* Voting rights on [SEPs](/community/sep-guidelines.md)
172172* Approval of Maintainers
173173* Governance voting rights and expectation of governance participation
174174* Administrative rights to all MCP GitHub repositories
from line 247
247247
248248Working Group (WG) Leads and Interest Group (IG) Facilitators are a form of community leadership that does not require Maintainer status. WG and IG leadership centers on facilitation and coordination rather than merge authority.
249249
250The full governance rules for WGs and IGs are defined in [SEP-2149: MCP Group Governance and Charter Template](/seps/2149-working-group-charter-template). These include participation tiers, decision-making process, meeting requirements, and lifecycle.
250The full governance rules for WGs and IGs are defined in [SEP-2149: MCP Group Governance and Charter Template](/seps/2149-working-group-charter-template.md). These include participation tiers, decision-making process, meeting requirements, and lifecycle.
251251
252252**Requirements:**
253253
from line 308
308308
309309When in doubt, make the decision at your level and document it. Escalate only when blocked, when the decision has project-wide implications, or when process explicitly requires it.
310310
311The detailed escalation procedure for Working Group and Interest Group disputes is defined in [SEP-2149 §1.5](/seps/2149-working-group-charter-template). It includes the designation of a Core Maintainer without shared organizational affiliation to resolve the issue.
311The detailed escalation procedure for Working Group and Interest Group disputes is defined in [SEP-2149 §1.5](/seps/2149-working-group-charter-template.md). It includes the designation of a Core Maintainer without shared organizational affiliation to resolve the issue.
312312
313313### Escalation Matrix
314314
from line 337
337337
338338**Code Contributions.** SDK development (TypeScript, Python, etc.), testing infrastructure, tooling and developer experience.
339339
340**Specification Work.** Drafting or refining spec text, [SEP](/community/sep-guidelines) authorship or co-authorship, protocol design participation, compatibility analysis.
340**Specification Work.** Drafting or refining spec text, [SEP](/community/sep-guidelines.md) authorship or co-authorship, protocol design participation, compatibility analysis.
341341
342342**Documentation.** User guides and tutorials, API documentation, architecture documentation, keeping content current.
343343
community/design-principles Changed · +4 / -4 lines
from line 2
22
33> The core design principles that guide the development of the Model Context Protocol.
44
5These principles guide how we evaluate protocol proposals, weigh tradeoffs, and evolve MCP. They reflect lessons from building and maintaining the project. They are meant as guidance by and for the community when developing [Spec Enhancement Proposals](/community/sep-guidelines) (SEPs) and [extensions](/extensions/overview).
5These principles guide how we evaluate protocol proposals, weigh tradeoffs, and evolve MCP. They reflect lessons from building and maintaining the project. They are meant as guidance by and for the community when developing [Spec Enhancement Proposals](/community/sep-guidelines.md) (SEPs) and [extensions](/extensions/overview.md).
66
77## Convergence over choice
88
99There should be one way to solve a problem in MCP. Rather than supporting multiple approaches that fragment the ecosystem, we choose a single well-designed path — accepting harder decisions upfront to deliver a more cohesive protocol.
1010
11[Extensions](/extensions/overview) are where convergence gets tested; the specification is where it gets committed.
11[Extensions](/extensions/overview.md) are where convergence gets tested; the specification is where it gets committed.
1212
1313## Composability over specificity
1414
1515MCP provides foundational primitives: resources, tools, and prompts. We don't add protocol features for use cases that can be constructed from these existing building blocks. This keeps the surface area small and implementations simple.
1616
17When someone asks why MCP doesn't support a feature directly, the answer is usually that it can be built from what MCP already provides. Extensions like [MCP Apps](/extensions/apps/overview) and [Tasks](/extensions/tasks/overview) capture the patterns that emerge.
17When someone asks why MCP doesn't support a feature directly, the answer is usually that it can be built from what MCP already provides. Extensions like [MCP Apps](/extensions/apps/overview.md) and [Tasks](/extensions/tasks/overview.md) capture the patterns that emerge.
1818
1919## Interoperability over optimization
2020
from line 44
4444
4545MCP standardizes patterns that have already proven valuable. We look for conventions that work across multiple implementations and codify them, rather than inventing new paradigms and hoping they'll be adopted.
4646
47We encourage the use of [MCP extensions](/extensions/overview) as a way to experiment with new patterns that may eventually lead to standardization.
47We encourage the use of [MCP extensions](/extensions/overview.md) as a way to experiment with new patterns that may eventually lead to standardization.
4848
community/feature-lifecycle Changed · +10 / -10 lines
from line 16
1616This policy governs **features** of the MCP core specification: protocol
1717messages, capabilities, transports, schema types, and normative behavioral
1818requirements. The revision lifecycle of the specification document itself
19(Draft, Current, Final) is defined in the [versioning guide](/docs/learn/versioning).
19(Draft, Current, Final) is defined in the [versioning guide](/docs/learn/versioning.md).
2020
2121## Feature States
2222
from line 52
5252* or any other reasons the Core Maintainers deem appropriate.
5353
5454Deprecation is a specification change and therefore requires a SEP per the
55[SEP guidelines](/community/sep-guidelines). The deprecation SEP must:
55[SEP guidelines](/community/sep-guidelines.md). The deprecation SEP must:
5656
57571. Identify the feature by name and link to its definition in `schema.ts`
5858 (where applicable) and the specification prose.
from line 85
8585 removal.
8686
8787The feature becomes Deprecated when the revision carrying these changes is released
88and becomes the new Current revision (see [versioning guide](/docs/learn/versioning)).
88and becomes the new Current revision (see [versioning guide](/docs/learn/versioning.md)).
8989The minimum deprecation window is counted from that release.
9090
9191## The Deprecated Registry
from line 112
112112 logger).
113113
114114A Tier 1 SDK that consistently fails to surface a Deprecated feature is subject to the
115[Tier Relegation Process](/community/sdk-tiers#tier-relegation).
115[Tier Relegation Process](/community/sdk-tiers.md#tier-relegation).
116116
117117## Removing a Feature
118118
from line 132
132132security risk, meaning a vulnerability with a published security advisory or
133133documented in-the-wild exploitation for which no in-place mitigation exists.
134134Shortening the window requires Core Maintainer approval under the
135[governance decision process](/community/governance#decision-process), recorded
135[governance decision process](/community/governance.md#decision-process), recorded
136136in the deprecation SEP or, where the risk surfaces after that SEP is already
137137Final, in a short expedited-removal SEP that references it. The shortened
138138window must still provide at least ninety days between the feature becoming
from line 144
144144| - | - |
145145| Propose deprecation, extension, or restoration | Any contributor, per the SEP process |
146146| Sponsor | A Maintainer or Core Maintainer, per the SEP process |
147| Approve a deprecation SEP | Core Maintainers, per the [governance decision process](/community/governance#decision-process) |
148| Decide a removal during release preparation | Core Maintainers, per the [governance decision process](/community/governance#decision-process) |
149| Approve an extension or restoration SEP | Core Maintainers, per the [governance decision process](/community/governance#decision-process) |
150| Approve expedited removal | Core Maintainers, per the [governance decision process](/community/governance#decision-process) |
147| Approve a deprecation SEP | Core Maintainers, per the [governance decision process](/community/governance.md#decision-process) |
148| Decide a removal during release preparation | Core Maintainers, per the [governance decision process](/community/governance.md#decision-process) |
149| Approve an extension or restoration SEP | Core Maintainers, per the [governance decision process](/community/governance.md#decision-process) |
150| Approve expedited removal | Core Maintainers, per the [governance decision process](/community/governance.md#decision-process) |
151151
152152Lead Maintainers retain veto authority over each of the approvals
153above, per the [governance roles](/community/governance#roles) definition.
153above, per the [governance roles](/community/governance.md#roles) definition.
154154
community/governance Changed · +8 / -8 lines
from line 42
4242
4343### Roles
4444
45The [Contributor Ladder](/community/contributor-ladder) is the canonical definition of each role — its requirements, responsibilities, privileges, advancement process, and inactivity policy. This section gives a conceptual overview of how the roles relate to governance.
45The [Contributor Ladder](/community/contributor-ladder.md) is the canonical definition of each role — its requirements, responsibilities, privileges, advancement process, and inactivity policy. This section gives a conceptual overview of how the roles relate to governance.
4646
47**Maintainers** steward specific areas such as SDKs, documentation, or [Working Groups](/community/working-interest-groups). They make decisions for their area independently and escalate to Core Maintainers when needed. Maintainers have write access to their respective repositories.
47**Maintainers** steward specific areas such as SDKs, documentation, or [Working Groups](/community/working-interest-groups.md). They make decisions for their area independently and escalate to Core Maintainers when needed. Maintainers have write access to their respective repositories.
4848
4949**Core Maintainers** steer the MCP specification and overall project direction. They can veto Maintainer decisions by majority vote, resolve disputes, and appoint or remove Maintainers. Core Maintainers have admin access to all MCP repositories but use the same pull-request workflow as outside contributors.
5050
5151**Lead Maintainers** hold final authority and can veto any decision by Core Maintainers or Maintainers — the role commonly known as Benevolent Dictator for Life (BDFL). Lead Maintainers appoint and remove Core Maintainers, and are administrators on all project infrastructure. They are part of the Core Maintainer group and are expected to publicly articulate their reasoning.
5252
53The [Contributor Ladder](/community/contributor-ladder) also defines the **Member** and **Community Moderator** roles, which sit outside the Steering Group.
53The [Contributor Ladder](/community/contributor-ladder.md) also defines the **Member** and **Community Moderator** roles, which sit outside the Steering Group.
5454
5555### Decision Process
5656
from line 66
6666
6767### Working Groups and Interest Groups
6868
69MCP collaboration and contributions are organized around two structures: [Working Groups and Interest Groups](/community/working-interest-groups).
69MCP collaboration and contributions are organized around two structures: [Working Groups and Interest Groups](/community/working-interest-groups.md).
7070
7171* **Interest Groups** identify and articulate problems that MCP should address through open discussions
7272* **Working Groups** develop concrete solutions by producing deliverables like SEPs or implementations
7373
74For details on how to create, participate in, and facilitate these groups, see the [Working and Interest Groups](/community/working-interest-groups) documentation.
74For details on how to create, participate in, and facilitate these groups, see the [Working and Interest Groups](/community/working-interest-groups.md) documentation.
7575
7676### Specification Enhancement Proposals (SEPs)
7777
78Proposed changes to the specification must be submitted as [Specification Enhancement Proposals (SEPs)](/community/sep-guidelines). SEPs are the primary mechanism for proposing major new features, collecting community input, and documenting design decisions.
78Proposed changes to the specification must be submitted as [Specification Enhancement Proposals (SEPs)](/community/sep-guidelines.md). SEPs are the primary mechanism for proposing major new features, collecting community input, and documenting design decisions.
7979
80For the complete SEP process, format requirements, and status workflow, see the [SEP Guidelines](/community/sep-guidelines).
80For the complete SEP process, format requirements, and status workflow, see the [SEP Guidelines](/community/sep-guidelines.md).
8181
8282### Maintenance Responsibilities
8383
from line 99
9999
100100Membership in maintainer groups is given to **individuals** on a merit basis after demonstrated expertise and alignment with MCP's direction. Membership is associated with the person, not their employer, and has no term limit.
101101
102The nomination process, sponsorship requirements, review timeline, and inactivity criteria for each role are defined in the [Contributor Ladder's Advancement Process](/community/contributor-ladder#advancement-process).
102The nomination process, sponsorship requirements, review timeline, and inactivity criteria for each role are defined in the [Contributor Ladder's Advancement Process](/community/contributor-ladder.md#advancement-process).
103103
104104## Current Lead Maintainers
105105
community/interest-groups/auth Changed · +12 / -12 lines
from line 8
88
99## Mission Statement
1010
11The Authorization Interest Group is the single chartered venue for MCP authorization work. It brings MCP implementers, identity-provider vendors, and security practitioners together to surface real-world authorization problems, decide whether they are worth solving and whether they belong in MCP, and give authors a reliable place to present [SEPs](/community/sep-guidelines), [ext-auth](https://github.com/modelcontextprotocol/ext-auth) drafts, prototypes, and deployment results for cross-topic feedback. The charter defines the scope; discussion and rough consensus happen in one channel and one recurring call, and the work products are drafts and demos rather than new standing groups.
11The Authorization Interest Group is the single chartered venue for MCP authorization work. It brings MCP implementers, identity-provider vendors, and security practitioners together to surface real-world authorization problems, decide whether they are worth solving and whether they belong in MCP, and give authors a reliable place to present [SEPs](/community/sep-guidelines.md), [ext-auth](https://github.com/modelcontextprotocol/ext-auth) drafts, prototypes, and deployment results for cross-topic feedback. The charter defines the scope; discussion and rough consensus happen in one channel and one recurring call, and the work products are drafts and demos rather than new standing groups.
1212
1313## Scope
1414
from line 15
1515### In Scope
1616
1717* **Deployment experience reports**: how implementers have integrated the current authorization spec (OAuth 2.1, [RFC 9728](https://www.rfc-editor.org/rfc/rfc9728) Protected Resource Metadata, [RFC 7591](https://www.rfc-editor.org/rfc/rfc7591) Dynamic Client Registration, Client ID Metadata Documents) with real authorization servers, and where it falls short
18* **Extension interoperability reports**: results of pairing independent implementations of the [ext-auth](https://github.com/modelcontextprotocol/ext-auth) extensions end to end (for example IdP, client, and authorization server through the [Enterprise-Managed Authorization](/extensions/auth/enterprise-managed-authorization) ID-JAG exchange), including IdP capability gaps, workarounds, and conformance scenario input
18* **Extension interoperability reports**: results of pairing independent implementations of the [ext-auth](https://github.com/modelcontextprotocol/ext-auth) extensions end to end (for example IdP, client, and authorization server through the [Enterprise-Managed Authorization](/extensions/auth/enterprise-managed-authorization.md) ID-JAG exchange), including IdP capability gaps, workarounds, and conformance scenario input
1919* **Enterprise identity integration**: requirements and friction points when connecting MCP servers to enterprise IdPs (Okta, Entra ID, Ping, Keycloak, etc.), including SSO, tenant isolation, and admin consent flows
2020* **Delegated and agentic access**: use cases for on-behalf-of token exchange, downstream resource access, audience restriction, and consent when an MCP client acts through chains of agents or tools
2121* **Scope and permission granularity**: whether and how MCP servers should advertise fine-grained scopes (per-tool, per-resource) and how clients should request and present them, and authorization granularity beyond scope strings (Rich Authorization Requests, structured denials, remediation hints)
from line 22
2222* **Credentials for non-HTTP transports**: patterns for stdio, WebSocket, and future transports where the HTTP authorization spec does not directly apply
2323* **Client identity and registration**: operator experience with Dynamic Client Registration, Client ID Metadata Documents, software statements, and pre-registered clients
2424* **Threat modelling input**: cataloguing authorization-related attack surfaces (token confusion, confused-deputy, audience mismatch, redirect handling) to inform Security Best Practices documentation
25* **SEP and draft feedback**: authorization-related SEPs, ext-auth drafts, reference implementations, and demos are presented on the call and in `#auth-ig` threads for feedback before and during the [SEP process](/community/sep-guidelines); the IG's rough consensus is recorded in meeting notes for sponsors and Core Maintainers to draw on
25* **SEP and draft feedback**: authorization-related SEPs, ext-auth drafts, reference implementations, and demos are presented on the call and in `#auth-ig` threads for feedback before and during the [SEP process](/community/sep-guidelines.md); the IG's rough consensus is recorded in meeting notes for sponsors and Core Maintainers to draw on
2626* **Problem statements and requirements**: use-case catalogues and recommendations shared in `#auth-ig` threads and on SEP pull requests for consumption by SEP authors
2727
2828### Out of Scope
2929
30* **Accepting SEPs or extensions**: the IG gives feedback and signals support; sponsorship and acceptance follow the [SEP guidelines](/community/sep-guidelines) and remain with Maintainers and Core Maintainers
30* **Accepting SEPs or extensions**: the IG gives feedback and signals support; sponsorship and acceptance follow the [SEP guidelines](/community/sep-guidelines.md) and remain with Maintainers and Core Maintainers
3131* **Authentication of end users to MCP clients**: how a host application authenticates its own users is a host concern, not a protocol concern
3232* **Transport security (TLS, mTLS, certificate handling)**: belongs to the Transports WG
3333* **Server identity, provenance, and trust signalling**: belongs to the Server Card / Registry efforts
3434* **End-user product configuration walk-throughs**: the IG discusses patterns, not step-by-step setup for individual IdP products. Vendor-reported constraints on what an authorization server or IdP can or cannot implement *are* in scope as deployment experience
35* **Competitively sensitive or non-public business information**, per the [MCP Antitrust Policy](/community/antitrust)
35* **Competitively sensitive or non-public business information**, per the [MCP Antitrust Policy](/community/antitrust.md)
3636
3737### Related Groups
3838
39* **[Security IG](/community/interest-groups/security)**: token-audience confusion, issuer validation, and account-linking risks sit at the boundary between the two groups
40* **[Transports WG](/community/working-groups/transports)**: authorization is currently specified at the HTTP transport level; changes to transports affect where credentials are carried
39* **[Security IG](/community/interest-groups/security.md)**: token-audience confusion, issuer validation, and account-linking risks sit at the boundary between the two groups
40* **[Transports WG](/community/working-groups/transports.md)**: authorization is currently specified at the HTTP transport level; changes to transports affect where credentials are carried
4141* **Agents IG**: delegated/on-behalf-of access and consent for multi-agent chains overlap heavily with agentic use cases
42* **[Server Card WG](/community/working-groups/server-card) / [Registry](/community/working-groups/registry)**: client and server identity, discovery metadata, and trust establishment intersect with how authorization servers and resource servers are located and verified
42* **[Server Card WG](/community/working-groups/server-card.md) / [Registry](/community/working-groups/registry.md)**: client and server identity, discovery metadata, and trust establishment intersect with how authorization servers and resource servers are located and verified
4343* **SDK Maintainers**: SDKs ship the auth client implementations; IG findings should inform cross-SDK auth ergonomics and defaults
4444
4545## Leadership
from line 54
5454
5555Open to anyone; no formal membership or approval step is required to join the channel, attend calls, or contribute. The group particularly seeks identity-provider vendors, MCP client and server implementers shipping authorization support, and operators integrating MCP with enterprise IdPs.
5656
57Join the `#auth-ig` channel on the [MCP Contributors Discord](/community/communication#discord) and start or join a thread for your topic. Calls are open and attendance is optional — async participation in Discord threads is equally valued.
57Join the `#auth-ig` channel on the [MCP Contributors Discord](/community/communication.md#discord) and start or join a thread for your topic. Calls are open and attendance is optional — async participation in Discord threads is equally valued.
5858
5959## Operations
6060
from line 66
6666
6767### One channel, threads per topic
6868
69All authorization discussion happens in `#auth-ig`, with one Discord thread per topic (for example a SEP number, a draft name, or a deployment pairing). There are no per-topic channels. Meeting agendas and notes live in the channel's per-call agenda thread, with a link cross-posted to [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions) as the [group governance rules](/community/working-interest-groups) require.
69All authorization discussion happens in `#auth-ig`, with one Discord thread per topic (for example a SEP number, a draft name, or a deployment pairing). There are no per-topic channels. Meeting agendas and notes live in the channel's per-call agenda thread, with a link cross-posted to [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions) as the [group governance rules](/community/working-interest-groups.md) require.
7070
7171### Agenda-driven calls
7272
from line 85
8585* **Is this a problem worth solving?** Is there real deployment demand, and is the gap in the protocol rather than in one product?
8686* **Does it belong here?** Is the right home the core specification, an official extension in ext-auth, an unofficial extension, or an upstream standards body?
8787
88When the answer to both is yes, the proposer drafts a SEP or ext-auth pull request through the normal [SEP process](/community/sep-guidelines), finds a sponsor, and returns to the call to present progress and demos as the draft matures. The IG does not charter a sub-group, channel, or meeting series per topic. Contributors who already meet separately on a topic are welcome to keep doing so, and bring outcomes back to the call as agenda slots. A separate [Working Group](/community/working-interest-groups) can still be proposed through the standard process when a deliverable genuinely needs its own decision rights, but that is the exception rather than the default path.
88When the answer to both is yes, the proposer drafts a SEP or ext-auth pull request through the normal [SEP process](/community/sep-guidelines.md), finds a sponsor, and returns to the call to present progress and demos as the draft matures. The IG does not charter a sub-group, channel, or meeting series per topic. Contributors who already meet separately on a topic are welcome to keep doing so, and bring outcomes back to the call as agenda slots. A separate [Working Group](/community/working-interest-groups.md) can still be proposed through the standard process when a deliverable genuinely needs its own decision rights, but that is the exception rather than the default path.
8989
9090## Deliverables & Success Metrics
9191
from line 93
9393
9494### Consolidated channels
9595
96The following Discord channels previously hosted authorization sub-groups. They are archived (read-only) as of this re-charter and their topics continue as `#auth-ig` threads and agenda slots. The [Enterprise-Managed Authorization IG](/community/interest-groups/enterprise-managed-authorization) is folded into this group on the same basis: EMA implementers bring interoperability and deployment progress to the call as presentation slots rather than to a standing separate group.
96The following Discord channels previously hosted authorization sub-groups. They are archived (read-only) as of this re-charter and their topics continue as `#auth-ig` threads and agenda slots. The [Enterprise-Managed Authorization IG](/community/interest-groups/enterprise-managed-authorization.md) is folded into this group on the same basis: EMA implementers bring interoperability and deployment progress to the call as presentation slots rather than to a standing separate group.
9797
9898| Former channel | Topic | State at consolidation | Continues as |
9999| - | - | - | - |
community/interest-groups/enterprise-managed-authorization Changed · +7 / -7 lines
from line 5
55> [!NOTE]
66>
77> As of 2026-08-17 this Interest Group is folded into the [Authorization
8> IG](/community/interest-groups/auth). EMA interoperability and deployment
8> IG](/community/interest-groups/auth.md). EMA interoperability and deployment
99> progress is presented as agenda slots on the Auth IG call, discussion
1010> continues in `#auth-ig` threads, and `#enterprise-managed-auth-ig` is
1111> archived. This page is kept for reference.
from line 16
1616
1717## Mission Statement
1818
19The Enterprise-Managed Authorization Interest Group provides a venue for identity-provider vendors, MCP client implementers, and MCP server operators to coordinate on real-world adoption of the [Enterprise-Managed Authorization extension](/extensions/auth/enterprise-managed-authorization) (`io.modelcontextprotocol/enterprise-managed-authorization`). The extension's ID-JAG flow only delivers value when an enterprise IdP, an MCP client, and an MCP server's authorization server all interoperate end to end — this group exists to gather deployment experience, surface compatibility gaps between independent implementations, and feed validated problems back to the [Authorization IG](/community/interest-groups/auth) and the [ext-auth](https://github.com/modelcontextprotocol/ext-auth) specification.
19The Enterprise-Managed Authorization Interest Group provides a venue for identity-provider vendors, MCP client implementers, and MCP server operators to coordinate on real-world adoption of the [Enterprise-Managed Authorization extension](/extensions/auth/enterprise-managed-authorization.md) (`io.modelcontextprotocol/enterprise-managed-authorization`). The extension's ID-JAG flow only delivers value when an enterprise IdP, an MCP client, and an MCP server's authorization server all interoperate end to end — this group exists to gather deployment experience, surface compatibility gaps between independent implementations, and feed validated problems back to the [Authorization IG](/community/interest-groups/auth.md) and the [ext-auth](https://github.com/modelcontextprotocol/ext-auth) specification.
2020
2121## Scope
2222
from line 30
3030
3131### Out of Scope
3232
33* **Other authorization profiles**: Client Credentials, DPoP, Workload Identity Federation, and the core OAuth 2.1 flow belong to the [Authorization IG](/community/interest-groups/auth)
33* **Other authorization profiles**: Client Credentials, DPoP, Workload Identity Federation, and the core OAuth 2.1 flow belong to the [Authorization IG](/community/interest-groups/auth.md)
3434* **General enterprise deployment topics**: networking, packaging, and host-application rollout concerns that are not specific to the ID-JAG flow
3535* **End-user product configuration walk-throughs**: the IG discusses patterns, not step-by-step setup for individual IdP or client products. Vendor-reported constraints on what an IdP can or cannot implement *are* in scope as deployment experience
36* **Competitively sensitive or non-public business information**, per the [MCP Antitrust Policy](/community/antitrust)
36* **Competitively sensitive or non-public business information**, per the [MCP Antitrust Policy](/community/antitrust.md)
3737
3838### Related Groups
3939
40* **[Authorization IG](/community/interest-groups/auth)**: parent group for all MCP authorization work; EMA spec changes are incubated there and this IG's findings feed its agenda
41* **[Security IG](/community/interest-groups/security)**: token-audience confusion, issuer validation, and account-linking risks in the ID-JAG flow sit at the boundary between the two groups
40* **[Authorization IG](/community/interest-groups/auth.md)**: parent group for all MCP authorization work; EMA spec changes are incubated there and this IG's findings feed its agenda
41* **[Security IG](/community/interest-groups/security.md)**: token-audience confusion, issuer validation, and account-linking risks in the ID-JAG flow sit at the boundary between the two groups
4242* **SDK Maintainers**: SDKs ship the EMA client implementation; interop findings inform cross-SDK behaviour and defaults
4343
4444## Leadership
from line 54
5454
5555Open to anyone; no formal membership or approval step is required to join the channel, attend calls, or contribute. The group particularly seeks participants from enterprise IdP vendors, MCP client implementers shipping EMA support, and MCP server operators integrating with an enterprise IdP.
5656
57Join the `#enterprise-managed-auth-ig` channel on the [MCP Contributors Discord](/community/communication#discord) or open a thread in the Authorization category of [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions). Calls are open and attendance is optional — async participation via Discord and GitHub is equally valued.
57Join the `#enterprise-managed-auth-ig` channel on the [MCP Contributors Discord](/community/communication.md#discord) or open a thread in the Authorization category of [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions). Calls are open and attendance is optional — async participation via Discord and GitHub is equally valued.
5858
5959## Operations
6060
community/interest-groups/financial-services Changed · +10 / -10 lines
from line 11
1111The Financial Services Interest Group brings together stakeholders from regulated financial
1212institutions to identify where MCP needs to adapt for compliance, auditability, and risk-controlled
1313deployment. It gathers use cases and requirements from the financial sector, develops and validates
14domain-specific extensions, and scopes problems with broad applicability into [SEPs](/community/sep-guidelines)
14domain-specific extensions, and scopes problems with broad applicability into [SEPs](/community/sep-guidelines.md)
1515or Working Groups so that innovations proven in regulated environments can benefit the wider MCP
1616ecosystem.
1717
from line 44
4444### Out of Scope
4545
4646* **Competitively sensitive or non-public business information**: pricing, costs, margins, customer
47 lists, market segmentation, and competitive strategy, per the [MCP Antitrust Policy](/community/antitrust)
47 lists, market segmentation, and competitive strategy, per the [MCP Antitrust Policy](/community/antitrust.md)
4848* **General security threat modeling**: MCP-wide attack-surface analysis belongs to the
49 [Security IG](/community/interest-groups/security). This group provides financial-sector requirements as
49 [Security IG](/community/interest-groups/security.md). This group provides financial-sector requirements as
5050 input and consumes its threat models
5151* **Authorization protocol mechanics**: OAuth flows, scopes, client registration, and token handling
52 belong to the [Authorization IG](/community/interest-groups/auth)
52 belong to the [Authorization IG](/community/interest-groups/auth.md)
5353* **Product-specific compliance guides**: step-by-step configuration for an individual host
5454 application, cloud platform, or institution is documentation for that product rather than protocol
5555 work
from line 57
5757
5858### Related Groups
5959
60* **[Security IG](/community/interest-groups/security)**: attestation, auditability, and guardrails are
60* **[Security IG](/community/interest-groups/security.md)**: attestation, auditability, and guardrails are
6161 shared concerns; the FSIG supplies regulated-deployment requirements and consumes the IG's threat
6262 models
63* **[Authorization IG](/community/interest-groups/auth)**: identity and access control for sensitive
63* **[Authorization IG](/community/interest-groups/auth.md)**: identity and access control for sensitive
6464 financial data sit at the boundary between the two groups
65* **[Tool Annotations IG](/community/interest-groups/tool-annotations)**: trust and sensitivity annotations
65* **[Tool Annotations IG](/community/interest-groups/tool-annotations.md)**: trust and sensitivity annotations
6666 are directly relevant to financial tool exposure; the FSIG provides requirements as input
67* **[Interceptors WG](/community/working-groups/interceptors)**: interceptors are a primary enforcement point
67* **[Interceptors WG](/community/working-groups/interceptors.md)**: interceptors are a primary enforcement point
6868 for the policy and guardrail requirements surfaced here
69* **[Registry WG](/community/working-groups/registry)**: server provenance and publishing metadata intersect
69* **[Registry WG](/community/working-groups/registry.md)**: server provenance and publishing metadata intersect
7070 with financial supply-chain and admission concerns
7171
7272## Leadership
from line 85
8585| King Yew Choo | True Primary | [@kychooo](https://github.com/kychooo) | kychooo | Participant |
8686
8787Open to anyone. Join the `#financial-services-ig` channel on the
88[MCP Contributors Discord](/community/communication#discord). Calls are open and no approval is
88[MCP Contributors Discord](/community/communication.md#discord). Calls are open and no approval is
8989required to attend or contribute. The group especially welcomes contributors from regulated
9090institutions who can bring real-world deployment constraints and help drive proposals forward.
9191
community/interest-groups/scientific-computing Changed · +7 / -7 lines
from line 40
4040 code, or dataset are valuable inputs to the group's use-case gathering, but building them is not
4141 protocol work
4242* **Authorization and identity mechanics**: OAuth flows, scopes, and token handling belong to the
43 [Authorization IG](/community/interest-groups/auth)
43 [Authorization IG](/community/interest-groups/auth.md)
4444
4545### Related Groups
4646
47* **[Tasks and Events WG](/community/working-groups/tasks-events)**: Tasks are the foundation for the long-running
47* **[Tasks and Events WG](/community/working-groups/tasks-events.md)**: Tasks are the foundation for the long-running
4848 simulation and job-submission workflows for high-performance computing
49* **[Interceptors WG](/community/working-groups/interceptors)**: interceptors are a potential
49* **[Interceptors WG](/community/working-groups/interceptors.md)**: interceptors are a potential
5050 implementation path for validating correctness and normalizing units between clients and servers
51* **[File Uploads WG](/community/working-groups/file-uploads)**: input datasets, mesh and geometry
51* **[File Uploads WG](/community/working-groups/file-uploads.md)**: input datasets, mesh and geometry
5252 files, and other large files must be considered
53* **[Primitive Grouping IG](/community/interest-groups/primitive-grouping)**: scientific servers often
53* **[Primitive Grouping IG](/community/interest-groups/primitive-grouping.md)**: scientific servers often
5454 expose large, hierarchical tool surfaces that motivate organization beyond flat lists
55* **[Registry WG](/community/working-groups/registry)**: publishing and discovering servers for shared
55* **[Registry WG](/community/working-groups/registry.md)**: publishing and discovering servers for shared
5656 scientific software and datasets intersects with registry metadata
5757
5858## Leadership
from line 68
6868| Working Session | TBD | TBD | Use-case sharing, technical discussion |
6969
7070Open to anyone. Join the [#scientific-computing-ig](https://discord.com/channels/1358869848138059966/1540132675174535228) channel on the
71[MCP Contributors Discord](/community/communication#discord).
71[MCP Contributors Discord](/community/communication.md#discord).
7272
7373## Discussion Topics
7474
community/interest-groups/security Changed · +13 / -13 lines
from line 9
99## Mission Statement
1010
1111The Security Interest Group catalogs MCP-specific threats, reviews security-relevant proposals, and
12scopes validated problems into focused Working Groups or [SEPs](/community/sep-guidelines).
12scopes validated problems into focused Working Groups or [SEPs](/community/sep-guidelines.md).
1313
1414## Scope
1515
from line 33
3333 area for stdio and other non-HTTP transports where the HTTP authorization specification does not
3434 apply
3535* **Security Best Practices documentation**: authoring and reviewing entries in the
36 [Security Best Practices](/docs/tutorials/security/security_best_practices) guidance, including
36 [Security Best Practices](/docs/tutorials/security/security_best_practices.md) guidance, including
3737 liaising with external bodies such as OWASP GenAI and CoSAI on MCP-specific content
3838* **Vulnerability disclosure routing**: providing a known point of contact for reporters who have
3939 filed a private security advisory against an MCP repository and need help reaching the right
from line 42
4242### Out of Scope
4343
4444* **Authorization protocol mechanics**: OAuth flows, scopes, client registration, and token handling
45 belong to the [Authorization IG](/community/interest-groups/auth) and its spawned Working Groups
45 belong to the [Authorization IG](/community/interest-groups/auth.md) and its spawned Working Groups
4646* **Transport wire security**: TLS, mTLS, and certificate handling belong to the Transports WG
4747* **Tool annotation design**: the annotation model itself belongs to the
48 [Tool Annotations IG](/community/interest-groups/tool-annotations). This group provides security
48 [Tool Annotations IG](/community/interest-groups/tool-annotations.md). This group provides security
4949 requirements as input
5050* **Registry service operation**: running and securing the hosted Registry service belongs to the
51 [Registry WG](/community/working-groups/registry). This group provides threat input on provenance and
51 [Registry WG](/community/working-groups/registry.md). This group provides threat input on provenance and
5252 publishing
5353* **Product-specific hardening guides**: step-by-step configuration for individual host applications
5454 or cloud platforms is documentation for those products rather than protocol work
5555* **Competitively sensitive or non-public business information**, per the
56 [MCP Antitrust Policy](/community/antitrust)
56 [MCP Antitrust Policy](/community/antitrust.md)
5757
5858### Related Groups
5959
60* **[Authorization IG](/community/interest-groups/auth)**: token confusion, audience mismatch, and SSRF in
60* **[Authorization IG](/community/interest-groups/auth.md)**: token confusion, audience mismatch, and SSRF in
6161 metadata discovery sit at the boundary between the two groups
62* **[Tool Annotations IG](/community/interest-groups/tool-annotations)**: trust and sensitivity annotations
62* **[Tool Annotations IG](/community/interest-groups/tool-annotations.md)**: trust and sensitivity annotations
6363 ([SEP-1913](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913)) span both
6464 groups
65* **[Interceptors WG](/community/working-groups/interceptors)**: interceptors are the primary enforcement
65* **[Interceptors WG](/community/working-groups/interceptors.md)**: interceptors are the primary enforcement
6666 point for runtime security decisions surfaced here
67* **[Server Card WG](/community/working-groups/server-card) / [Registry WG](/community/working-groups/registry)**:
67* **[Server Card WG](/community/working-groups/server-card.md) / [Registry WG](/community/working-groups/registry.md)**:
6868 server identity, provenance, and discovery metadata intersect with admission and supply-chain
6969 concerns
70* **[Transports WG](/community/working-groups/transports)**: stdio process isolation and unauthenticated method surface
70* **[Transports WG](/community/working-groups/transports.md)**: stdio process isolation and unauthenticated method surface
7171* **SDK Maintainers**: coordinated handling of SDK security advisories and cross-SDK security
7272 defaults
7373
from line 88
8888| Stefano Ortolani | Broadcom | [@ostefano](https://github.com/ostefano) | `ostefano.` | Participant |
8989
9090Open to anyone. Join the `#security-ig` channel on the
91[MCP Contributors Discord](/community/communication#discord). Calls are open and active
91[MCP Contributors Discord](/community/communication.md#discord). Calls are open and active
9292participation is highly encouraged. The group is looking for contributors who will engage with
9393proposals and help drive work forward rather than observe.
9494
from line 118
118118| — | Runtime drift: `list_changed` semantics after approval | Open | — |
119119| — | Supply-chain integrity: protocol, registry, or companion standard | Open | — |
120120| — | Tool identity across servers | Open | — |
121| — | Capability declarations: hints or contracts (joint with [Tool Annotations IG](/community/interest-groups/tool-annotations)) | Open | — |
121| — | Capability declarations: hints or contracts (joint with [Tool Annotations IG](/community/interest-groups/tool-annotations.md)) | Open | — |
122122
123123## Changelog
124124
community/sep-guidelines Changed · +10 / -10 lines
from line 8
88
99SEPs are the primary mechanism for proposing major new features, collecting community input on an issue, and documenting the design decisions that have gone into MCP. The SEP author is responsible for building consensus within the community and documenting dissenting opinions.
1010
11When drafting a SEP, authors should review the [MCP design principles](/community/design-principles), which outline the core values and tradeoffs that guide the protocol's evolution.
11When drafting a SEP, authors should review the [MCP design principles](/community/design-principles.md), which outline the core values and tradeoffs that guide the protocol's evolution.
1212
1313SEPs are maintained as markdown files in the [`seps/` directory](https://github.com/modelcontextprotocol/modelcontextprotocol/tree/main/seps) of the specification repository. Their revision history serves as the historical record of the feature proposal.
1414
from line 30
3030* Adding examples to existing features
3131* Minor schema fixes that don't change behavior
3232
33Not sure? Ask in [Discord](/community/communication#discord) before starting significant work.
33Not sure? Ask in [Discord](/community/communication.md#discord) before starting significant work.
3434
3535## SEP Types
3636
from line 39
39391. **Standards Track** - Describes a new feature or implementation for the Model Context Protocol, or an interoperability standard supported outside the core specification.
40402. **Informational** - Describes a design issue or provides guidelines/information to the community without proposing a new feature.
41413. **Process** - Describes a process surrounding MCP or proposes a change to a process (like this document).
424. **Extensions Track** - Describes a protocol extension. Follows the same review and acceptance process as Standards Track SEPs, but indicates that the proposal is for an extension rather than a protocol addition. See [Creating Extensions](/extensions/overview#creating-extensions) for the extension lifecycle.
424. **Extensions Track** - Describes a protocol extension. Follows the same review and acceptance process as Standards Track SEPs, but indicates that the proposal is for an extension rather than a protocol addition. See [Creating Extensions](/extensions/overview.md#creating-extensions) for the extension lifecycle.
4343
4444## SEP Workflow
4545
from line 69
6969
7070### Step-by-Step Process
7171
72**Prior discussion is required.** SEP authors must discuss the idea with the relevant [working or interest group](/community/working-interest-groups) in [Discord](/community/communication#discord) before opening the SEP pull request, and the PR description must link to that discussion (a Discord thread, WG/IG meeting notes, or a GitHub Discussion). A SEP without a linked prior discussion is not accepted. If no relevant group exists, start a conversation in [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions) or the `#general` channel in [Discord](/community/communication#discord) instead. If there is enough interest, it may be worth [creating a new IG or WG](/community/working-interest-groups#creating-an-interest-group). The effort involved in finding sponsors and facilitators is a good signal of whether the idea has sufficient traction.
72**Prior discussion is required.** SEP authors must discuss the idea with the relevant [working or interest group](/community/working-interest-groups.md) in [Discord](/community/communication.md#discord) before opening the SEP pull request, and the PR description must link to that discussion (a Discord thread, WG/IG meeting notes, or a GitHub Discussion). A SEP without a linked prior discussion is not accepted. If no relevant group exists, start a conversation in [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions) or the `#general` channel in [Discord](/community/communication.md#discord) instead. If there is enough interest, it may be worth [creating a new IG or WG](/community/working-interest-groups.md#creating-an-interest-group). The effort involved in finding sponsors and facilitators is a good signal of whether the idea has sufficient traction.
7373
7474> [!NOTE]
7575>
7676> To improve your chances of a SEP being accepted, check alignment with [Core
77> Maintainer](/community/governance#roles) priorities and [design
78> principles](/community/design-principles). Priorities are generally reflected
79> in the [project roadmap](/development/roadmap). Proposals outside current
77> Maintainer](/community/governance.md#roles) priorities and [design
78> principles](/community/design-principles.md). Priorities are generally reflected
79> in the [project roadmap](/development/roadmap.md). Proposals outside current
8080> priorities or that conflict with design principles are more likely to face
8181> delays or additional friction in the review process.
8282
831. **Discuss with the relevant group**: Bring your idea to the matching [working or interest group](/community/working-interest-groups) and refine it there. Keep a link to the discussion (a Discord thread, meeting notes, or a GitHub Discussion) so you can include it in the PR description.
831. **Discuss with the relevant group**: Bring your idea to the matching [working or interest group](/community/working-interest-groups.md) and refine it there. Keep a link to the discussion (a Discord thread, meeting notes, or a GitHub Discussion) so you can include it in the PR description.
8484
85852. **Draft your SEP** as a markdown file named `0000-your-feature-title.md`, using `0000` as a placeholder. Follow the [SEP format](#sep-format) below.
8686
from line 101
101101
1021029. **Resolution**: The SEP may be `accepted`, `rejected`, or returned for revision. The sponsor updates the status.
103103
10410. **Finalization**: Once accepted, the reference implementation must be completed. For Standards Track SEPs with observable protocol behavior, a [conformance test](#conformance-test-requirement) must also be merged. The author adds the specification changes (schema changes, specification text, and a changelog entry) to the SEP's pull request. SDK implementations are not required for a SEP to become `final`. When this work is complete, the sponsor updates the status to `final` and the SEP's PR can be merged. Merged SEPs are published in the [SEP index](/seps/index), and each one is reachable by number at `modelcontextprotocol.io/seps/<number>` (for example, [/seps/1850](/seps/1850)).
10410. **Finalization**: Once accepted, the reference implementation must be completed. For Standards Track SEPs with observable protocol behavior, a [conformance test](#conformance-test-requirement) must also be merged. The author adds the specification changes (schema changes, specification text, and a changelog entry) to the SEP's pull request. SDK implementations are not required for a SEP to become `final`. When this work is complete, the sponsor updates the status to `final` and the SEP's PR can be merged. Merged SEPs are published in the [SEP index](/seps/index.md), and each one is reachable by number at `modelcontextprotocol.io/seps/<number>` (for example, [/seps/1850](/seps/1850.md)).
105105
106106### SEP Statuses
107107
from line 241
241241
242242Writing a conformance scenario during SEP drafting (before Core Maintainer review) is encouraged but not required, since it often surfaces ambiguities in normative language that are cheaper to fix early.
243243
244See [SEP-2484](/seps/2484-conformance-tests-required-for-final-seps) for the full specification including the traceability file format and dispute process.
244See [SEP-2484](/seps/2484-conformance-tests-required-for-final-seps.md) for the full specification including the traceability file format and dispute process.
245245
246246## After Rejection
247247
community/working-groups/governance Changed · +8 / -8 lines
from line 8
88
99## Mission Statement
1010
11The Governance Working Group exists to refine, document, and steward MCP's governance processes and community values, providing a single home for revising the project's governance documentation as the project grows. It also serves as an advisory voice channel — surfacing community concerns to Core Maintainers and stewarding the contribution culture that helps people advance through the [contributor ladder](/community/contributor-ladder). Over time the WG aspires to evolve into a standing consultation forum for contested governance decisions and, longer-term, to support representative community participation in the broader MCP organization.
11The Governance Working Group exists to refine, document, and steward MCP's governance processes and community values, providing a single home for revising the project's governance documentation as the project grows. It also serves as an advisory voice channel — surfacing community concerns to Core Maintainers and stewarding the contribution culture that helps people advance through the [contributor ladder](/community/contributor-ladder.md). Over time the WG aspires to evolve into a standing consultation forum for contested governance decisions and, longer-term, to support representative community participation in the broader MCP organization.
1212
1313## Scope
1414
from line 18
1818* **Decision Recording**: Defining what counts as a project decision, who ratifies it, and how it is recorded across meeting notes, GitHub Discussions, and the SEP record.
1919* **Code of Conduct Stewardship**: Drafting, revising, and maintaining the Code of Conduct text and adjacent reporting/escalation documentation. Content revisions go through WG consensus → Core Maintainer approval.
2020* **Community Values**: Stewardship of MCP's stated community values, including landing the in-progress values workshop as a public artefact under `docs/community/`.
21* **Contribution Culture & Mentorship**: Encouraging mentorship as a culture (not a formal pairings program in v0.1) and stewarding practice for movement across the contributor ladder tiers, in coordination with [SEP-2148](/seps/2148-contributor-ladder).
21* **Contribution Culture & Mentorship**: Encouraging mentorship as a culture (not a formal pairings program in v0.1) and stewarding practice for movement across the contributor ladder tiers, in coordination with [SEP-2148](/seps/2148-contributor-ladder.md).
2222* **Voice Channel**: Surfacing community concerns from contributors and observers to Core Maintainers in an advisory, non-binding capacity. Concerns arrive in `#governance-wg` or at the monthly working session; the Lead carries those needing Core Maintainer attention to the monthly Core Maintainer plus WG/IG leads meeting.
2323* **Cross-Cutting Coordination**: Coordination with other WGs and IGs on governance processes that affect them. The WG sets the framework; per-group operations remain with the groups themselves.
2424
2525### Out of Scope
2626
27* **Specification authorship**: Protocol changes go through the [SEP process](/community/sep-guidelines) and the relevant spec-producing Working Group. The Governance WG never owns spec sections. It may sponsor a SEP that changes a governance process.
27* **Specification authorship**: Protocol changes go through the [SEP process](/community/sep-guidelines.md) and the relevant spec-producing Working Group. The Governance WG never owns spec sections. It may sponsor a SEP that changes a governance process.
2828* **Maintainer selection and succession**: Lead Maintainers appoint Core Maintainers; Core Maintainers approve Maintainers. The WG may recommend process improvements but does not pick people.
2929* **Individual Code of Conduct moderation decisions**: Receipt, investigation, and adjudication of individual incident reports are not within this WG's purview. The WG's near-term goal is to receive aggregated, anonymized trend reports from whoever performs incident handling, to inform policy revision.
30* **Per-SDK governance**: Owned by the [SDK Working Group](/community/working-groups/sdk).
30* **Per-SDK governance**: Owned by the [SDK Working Group](/community/working-groups/sdk.md).
3131* **Per-WG/IG internal operations**: Each group runs its own meetings, prioritisation, and member coordination; the Governance WG sets framework only.
3232* **Maintainer disputes and interpersonal conflict resolution outside the Code of Conduct**: Explicitly out of scope for v0.1. Scoping a possible escalation path is a candidate future deliverable; claiming the role itself is not.
3333
from line 34
3434### Related Groups
3535
3636* **Core Maintainers** — material governance changes, Code of Conduct content revisions, and contributor ladder structural changes require Core Maintainer approval. The Lead represents the WG at the monthly Core Maintainer plus WG/IG leads meeting and surfaces community concerns there in an advisory capacity.
37* **All other Working Groups and Interest Groups** — the WG sets the governance framework that all groups inherit ([charter template](/seps/2149-working-group-charter-template), decision rights, meeting requirements). Per-group operations remain with the groups themselves. Interest groups route governance questions here.
37* **All other Working Groups and Interest Groups** — the WG sets the governance framework that all groups inherit ([charter template](/seps/2149-working-group-charter-template.md), decision rights, meeting requirements). Per-group operations remain with the groups themselves. Interest groups route governance questions here.
3838* **SDK Working Group** — coordination on the boundary between project-wide governance and per-SDK governance, which lives there.
3939* **Future Code of Conduct handling body** — once the CoC reporting/handling path is formalised, the body that handles individual incidents will share aggregated, anonymised trend reports with the WG to inform policy revision.
4040
from line 54
5454
5555* Any WG Member may self-nominate or be nominated by another WG Member.
5656* Candidates must meet the Lead requirements in the
57 [Working and Interest Groups](/community/working-interest-groups) documentation, and the group's
57 [Working and Interest Groups](/community/working-interest-groups.md) documentation, and the group's
5858 leadership must retain sponsorship from at least two Core Maintainers or one Lead Maintainer.
5959* Selection is by WG consensus using the standard decision-making process (lazy consensus, falling
6060 back to a formal vote), then ratified by Core Maintainers as a charter amendment, since the
from line 90
9090
9191## Membership
9292
93Membership eligibility follows the standard WG model defined in the [Working and Interest Groups](/community/working-interest-groups) documentation. To become a WG Member: sustained participation over 3 months, meaningful contributions (for this WG: governance doc drafting, reviews, or discussion facilitation), nomination by an existing WG Member or Lead, and no objections from Leads, Core Maintainers, or Lead Maintainers within 7 days. One additional structural rule applies: **no more than 2 Leads from any single organisation**. This invariant is maintained throughout each term.
93Membership eligibility follows the standard WG model defined in the [Working and Interest Groups](/community/working-interest-groups.md) documentation. To become a WG Member: sustained participation over 3 months, meaningful contributions (for this WG: governance doc drafting, reviews, or discussion facilitation), nomination by an existing WG Member or Lead, and no objections from Leads, Core Maintainers, or Lead Maintainers within 7 days. One additional structural rule applies: **no more than 2 Leads from any single organisation**. This invariant is maintained throughout each term.
9494
9595| Name | Organization | GitHub | Discord | Level |
9696| - | - | - | - | - |
from line 166
166166
167167This charter is a v0.1 document and is expected to be revised as the group coalesces. Updates
168168follow the
169[Charter Amendments](/community/working-interest-groups#charter-amendments) process defined for
169[Charter Amendments](/community/working-interest-groups.md#charter-amendments) process defined for
170170all groups: proposal by a Lead or Core Maintainer, approval by Core Maintainers. Within the WG,
171171amendment proposals are treated like any other substantive governance change — WG consensus
172172first, then Core Maintainer approval. Editorial fixes (typos, broken links, rewordings that do
community/working-groups/progressive-disclosure Changed · +5 / -5 lines
from line 8
88
99## Mission Statement
1010
11The Progressive Disclosure Working Group explores how MCP Primitives (Tools, Resources, Prompts, Tasks) might be organized, beyond the flat lists maintained by the protocol, and how such organization might benefit both MCP servers and clients. The group documents diverse requirements from clients, servers, and gateways, supports reference extensions of varied organization strategies, and feeds recommendations into the [SEP process](/community/sep-guidelines) rather than picking a single canonical pattern early.
11The Progressive Disclosure Working Group explores how MCP Primitives (Tools, Resources, Prompts, Tasks) might be organized, beyond the flat lists maintained by the protocol, and how such organization might benefit both MCP servers and clients. The group documents diverse requirements from clients, servers, and gateways, supports reference extensions of varied organization strategies, and feeds recommendations into the [SEP process](/community/sep-guidelines.md) rather than picking a single canonical pattern early.
1212
1313## Scope
1414
from line 25
2525
2626### Related Groups
2727
28* **[Tool Annotations IG](/community/interest-groups/tool-annotations)** - annotation-based filtering and selection of primitives intersects with how primitives are organized and surfaced
29* **[Skills Over MCP WG](/community/working-groups/skills-over-mcp)** - maintains the published [Skills extension](/extensions/skills/overview); skill discovery and progressive disclosure overlap with grouping
28* **[Tool Annotations IG](/community/interest-groups/tool-annotations.md)** - annotation-based filtering and selection of primitives intersects with how primitives are organized and surfaced
29* **[Skills Over MCP WG](/community/working-groups/skills-over-mcp.md)** - maintains the published [Skills extension](/extensions/skills/overview.md); skill discovery and progressive disclosure overlap with grouping
3030
3131## Problem Statement
3232
from line 41
4141**Beyond Scope**
4242
4343* **Organization for security** - organizing and disclosing primitives to clients based on their privilege level is an important problem but beyond this group's mandate
44* **Organizing MCP servers** - server discovery and registry schema decisions belong to the [Registry WG](/community/working-groups/registry), with skill-distribution requirements contributed by the Skills Over MCP WG
44* **Organizing MCP servers** - server discovery and registry schema decisions belong to the [Registry WG](/community/working-groups/registry.md), with skill-distribution requirements contributed by the Skills Over MCP WG
4545
4646## Goals
4747
from line 87
8787| - | - | - | - |
8888| Discussion | Weekly | TBD | Requirements alignment, approach review, experimental findings |
8989
90Meetings are published at [meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io/tag/progressive-disclosure-wg). Open to anyone. Join the [#progressive-disclosure-wg](https://discord.com/channels/1358869848138059966/1425903819186770064) channel on the [MCP Contributors Discord](/community/communication#discord).
90Meetings are published at [meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io/tag/progressive-disclosure-wg). Open to anyone. Join the [#progressive-disclosure-wg](https://discord.com/channels/1358869848138059966/1425903819186770064) channel on the [MCP Contributors Discord](/community/communication.md#discord).
9191
9292## Discussion Topics
9393
community/working-groups/sdk Changed · +4 / -4 lines
from line 8
88
99## Mission Statement
1010
11The SDK Working Group exists to keep the official MCP SDKs consistent, conformant, and current with the specification. It coordinates implementation of new protocol versions across languages, governs the [SDK Tiering System](/community/sdk-tiers), and establishes shared design patterns where sensible, so that developers get a coherent experience across SDKs while each remains idiomatic to its language.
11The SDK Working Group exists to keep the official MCP SDKs consistent, conformant, and current with the specification. It coordinates implementation of new protocol versions across languages, governs the [SDK Tiering System](/community/sdk-tiers.md), and establishes shared design patterns where sensible, so that developers get a coherent experience across SDKs while each remains idiomatic to its language.
1212
1313## Scope
1414
1515### In Scope
1616
17* **SDK Tiering**: Operating the [SDK Tiering System](/community/sdk-tiers), including reviewing tier advancement requests, applying relegation criteria, and maintaining the published tier assignments.
17* **SDK Tiering**: Operating the [SDK Tiering System](/community/sdk-tiers.md), including reviewing tier advancement requests, applying relegation criteria, and maintaining the published tier assignments.
1818* **Official SDK Roster**: Evaluating proposals to add new official SDKs or retire existing ones.
1919* **Release Coordination**: Aligning Tier-1 SDK release plans with specification version dates so that protocol features land in SDKs on the timelines their tier requires.
2020* **Cross-SDK Design Guidance**: Recommending common patterns for SDK API surface, versioning, deprecation, error handling, and extension packaging, so that SDKs remain recognisably similar across languages while staying idiomatic.
from line 24
2424### Out of Scope
2525
2626* **Per-SDK day-to-day maintenance**: Issue triage, PR review, and releases for an individual SDK remain the responsibility of that SDK's maintainers as listed in [MAINTAINERS.md](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md).
27* **Specification authorship**: Protocol changes are proposed through the [SEP process](/community/sep-guidelines) and owned by the relevant working group or Core Maintainers. The SDK WG implements accepted SEPs; it does not own spec sections.
27* **Specification authorship**: Protocol changes are proposed through the [SEP process](/community/sep-guidelines.md) and owned by the relevant working group or Core Maintainers. The SDK WG implements accepted SEPs; it does not own spec sections.
2828* **Conformance test authoring**: The conformance test suite itself is owned by the [Conformance Testing](https://github.com/modelcontextprotocol/conformance) project.
2929* **Third-party and community SDKs**: SDKs outside the [modelcontextprotocol](https://github.com/modelcontextprotocol) organization are not governed by this group.
3030
3131### Related Groups
3232
33* **[Transports WG](/community/working-groups/transports)**: Transport implementations are a substantial part of every SDK. The SDK WG coordinates with the Transports WG on rollout sequencing when transport SEPs land.
33* **[Transports WG](/community/working-groups/transports.md)**: Transport implementations are a substantial part of every SDK. The SDK WG coordinates with the Transports WG on rollout sequencing when transport SEPs land.
3434* **Conformance Testing**: Tier assignments depend on conformance scores. The SDK WG consumes conformance results and feeds back gaps in test coverage.
3535* **All specification-producing WGs**: The SDK WG is a downstream consumer of accepted SEPs and coordinates reference-implementation timing with the originating group.
3636
community/working-groups/skills-over-mcp Changed · +8 / -8 lines
from line 17
1717implementations, and coordination artifacts because solutions touch the protocol spec,
1818registry schema, SDK implementations, and client behavior.
1919
20[SEP-2640 — Skills Extension](/seps/2640-skills-extension) is Final. The WG maintains
21the official [Skills extension](/extensions/skills/overview)
20[SEP-2640 — Skills Extension](/seps/2640-skills-extension.md) is Final. The WG maintains
21the official [Skills extension](/extensions/skills/overview.md)
2222(`io.modelcontextprotocol/skills`) in
2323[modelcontextprotocol/ext-skills](https://github.com/modelcontextprotocol/ext-skills).
2424Current work focuses on implementation support, interoperability, and evolution
from line 35
3535 skill discovery and consumption patterns
3636* **Cross-Cutting Concerns**: Coordination with Registry WG (skills discovery/distribution,
3737 registry schema changes), Agents IG (skill activation, server metadata consumption),
38 [Progressive Disclosure WG](/community/working-groups/progressive-disclosure) (progressive disclosure patterns), and external projects including
38 [Progressive Disclosure WG](/community/working-groups/progressive-disclosure.md) (progressive disclosure patterns), and external projects including
3939 the [Agent Skills](https://agentskills.io/) spec (content format and well-known URI
4040 discovery), FastMCP, and PydanticAI
4141* **Documentation**: Specification sections and guidance covering skill authoring,
from line 55
5555
5656* **Agents IG** — How agents consume server metadata, skill activation
5757* **Registry WG** — Skills discovery/distribution, registry schema changes
58* **[Progressive Disclosure WG](/community/working-groups/progressive-disclosure)** — Progressive disclosure patterns
58* **[Progressive Disclosure WG](/community/working-groups/progressive-disclosure.md)** — Progressive disclosure patterns
5959
6060## Leadership
6161
from line 115
115115
116116## Resources
117117
118* [Skills extension overview](/extensions/skills/overview) and [Final SEP-2640](/seps/2640-skills-extension)
118* [Skills extension overview](/extensions/skills/overview.md) and [Final SEP-2640](/seps/2640-skills-extension.md)
119119* Specification and WG documents: [modelcontextprotocol/ext-skills](https://github.com/modelcontextprotocol/ext-skills)
120* [Implementations](https://github.com/modelcontextprotocol/ext-skills/blob/main/docs/implementations.md) and [client support](/extensions/client-matrix)
120* [Implementations](https://github.com/modelcontextprotocol/ext-skills/blob/main/docs/implementations.md) and [client support](/extensions/client-matrix.md)
121121* [Decision log](https://github.com/modelcontextprotocol/ext-skills/blob/main/docs/decisions.md) and [archived design work](https://github.com/modelcontextprotocol/ext-skills/tree/main/docs/archive)
122122
123123## Deliverables & Success Metrics
from line 124
124124
125125### Completed Milestones
126126
127* [SEP-2640](/seps/2640-skills-extension) is **Final**, merged on September 13, 2026.
128* The official specification is published in [ext-skills](https://github.com/modelcontextprotocol/ext-skills/blob/main/specification/stable/skills.mdx), with a [website overview](/extensions/skills/overview).
127* [SEP-2640](/seps/2640-skills-extension.md) is **Final**, merged on September 13, 2026.
128* The official specification is published in [ext-skills](https://github.com/modelcontextprotocol/ext-skills/blob/main/specification/stable/skills.mdx), with a [website overview](/extensions/skills/overview.md).
129129* [Skills conformance scenarios](https://github.com/modelcontextprotocol/conformance/pull/330) were merged on September 11, 2026.
130130
131131### Current Work
community/working-groups/tasks-events Changed · +3 / -3 lines
from line 33
3333
3434### Related Groups
3535
36* **[Transports WG](/community/working-groups/transports)** — delivery and ordering guarantees depend on transport capabilities; callback semantics must be coherent across stdio, Streamable HTTP, and future transports.
37* **[Agents IG](/community/interest-groups/agents)** — agent-as-tool, remote-agent, and supervisor/sub-agent patterns depend on Tasks and on task completion notifications. The IG provides use cases and requirements, and this WG owns the protocol surface.
36* **[Transports WG](/community/working-groups/transports.md)** — delivery and ordering guarantees depend on transport capabilities; callback semantics must be coherent across stdio, Streamable HTTP, and future transports.
37* **[Agents IG](/community/interest-groups/agents.md)** — agent-as-tool, remote-agent, and supervisor/sub-agent patterns depend on Tasks and on task completion notifications. The IG provides use cases and requirements, and this WG owns the protocol surface.
3838
3939## Leadership
4040
from line 82
8282* Tasks extension repository:
8383 [modelcontextprotocol/ext-tasks](https://github.com/modelcontextprotocol/ext-tasks)
8484* Tasks specification:
85 [SEP-2663: Tasks Extension](/seps/2663-tasks-extension)
85 [SEP-2663: Tasks Extension](/seps/2663-tasks-extension.md)
8686
8787## Deliverables & Success Metrics
8888
community/working-groups/transports Changed · +6 / -6 lines
from line 24
2424* **Transport Bindings**: Framing, delivery, request and envelope metadata,
2525 cancellation and termination, connection lifecycle, backward compatibility, and
2626 the behavior of existing and future MCP transports. The current specification's
27 [transport overview](/specification/draft/basic/transports) defines the boundary
27 [transport overview](/specification/draft/basic/transports.md) defines the boundary
2828 between a transport binding and core protocol semantics.
2929* **Scalability and Reliability**: Transport-level connection management, resource
3030 efficiency, multiplexing, load distribution, error handling, reconnection,
from line 64
6464
6565### Related Groups
6666
67* **[SDK WG](/community/working-groups/sdk)**: Official SDKs implement transport
67* **[SDK WG](/community/working-groups/sdk.md)**: Official SDKs implement transport
6868 changes; the groups coordinate on feasibility, reference implementations, and
6969 rollout sequencing.
70* **[Tasks and Events WG](/community/working-groups/tasks-events)**: The Tasks and
70* **[Tasks and Events WG](/community/working-groups/tasks-events.md)**: The Tasks and
7171 Events WG owns Tasks and durable execution; the groups coordinate where these
7272 depend on multi-round-trip requests, request association, stateless operation, or
7373 binding behavior. Event callbacks, subscriptions, and application-level delivery
7474 semantics are owned by that group; Transports owns binding-specific carriage and
7575 guarantees.
76* **[Auth IG](/community/interest-groups/auth)** and
77 **[Security IG](/community/interest-groups/security)**: The groups coordinate on
76* **[Auth IG](/community/interest-groups/auth.md)** and
77 **[Security IG](/community/interest-groups/security.md)**: The groups coordinate on
7878 credential carriage and transport wire security while authorization mechanics and
7979 broader security requirements remain with the respective IGs.
8080
from line 117
1171173. Review and iterate on the solution to address WG feedback.
1181184. After the WG reaches consensus under its decision-making process, present the
119119 solution to Core Maintainers as an SEP through the
120 [SEP process](/community/sep-guidelines).
120 [SEP process](/community/sep-guidelines.md).
121121
122122## Resources
123123
community/working-interest-groups Changed · +5 / -5 lines
from line 81
8181
8282**Requirements for all Leads and Facilitators:**
8383
84* Hold at least Member status on the MCP Contributor Ladder — see [Governance](/community/governance) for role definitions
84* Hold at least Member status on the MCP Contributor Ladder — see [Governance](/community/governance.md) for role definitions
8585* Demonstrated sustained engagement with the group's scope area
8686* Ability to facilitate across organizational boundaries
8787* Commitment to running the group's operations
from line 102
102102
103103**WG Leads are additionally responsible for:**
104104
105* Drive proposals through the [SEP process](/community/sep-guidelines) to resolution
105* Drive proposals through the [SEP process](/community/sep-guidelines.md) to resolution
106106* Triage SEPs in the WG's scope area, including closing SEPs that do not fit the roadmap (with documented rationale; authors may appeal to Core Maintainers)
107107* Escalate blocked decisions to Core Maintainers with clear context
108108* Maintain the working group's roadmap
from line 226
226226**Working Group Formation:**
227227
228228* There must be a widely acknowledged concern requiring coordination
229* PR adding the WG charter as `docs/community/working-groups/<name>.mdx`, written from the [Group Charter Template](/community/charter-template) and including the corresponding navigation entry in `docs/docs.json`, gated by CODEOWNERS requiring approval from Core Maintainers
229* PR adding the WG charter as `docs/community/working-groups/<name>.mdx`, written from the [Group Charter Template](/community/charter-template.md) and including the corresponding navigation entry in `docs/docs.json`, gated by CODEOWNERS requiring approval from Core Maintainers
230230* Initial member list approved by WG Lead
231231
232232**Interest Group Formation:**
from line 252
252252
253253Every MCP Working Group and Interest Group must maintain a charter document that captures its specific mission, scope, leadership, membership, and operations. The governance rules above apply automatically and do not need to be repeated in the charter.
254254
255See the [Group Charter Template](/community/charter-template) for the required structure and a copyable template.
255See the [Group Charter Template](/community/charter-template.md) for the required structure and a copyable template.
256256
257257## FAQ
258258
from line 275
275275
276276### Do I need to be in a WG to submit a SEP?
277277
278No. Anyone can submit a SEP, and group membership is not required. The proposal must still be brought to the relevant group's Discord channel before the SEP pull request is opened, as described in the [SEP guidelines](/community/sep-guidelines#step-by-step-process). Beyond that requirement, closer WG collaboration can strengthen your proposal and help it find a sponsor.
278No. Anyone can submit a SEP, and group membership is not required. The proposal must still be brought to the relevant group's Discord channel before the SEP pull request is opened, as described in the [SEP guidelines](/community/sep-guidelines.md#step-by-step-process). Beyond that requirement, closer WG collaboration can strengthen your proposal and help it find a sponsor.
279279
280280### What if my IG discussion leads to a concrete solution?
281281
development/roadmap Changed · +20 / -20 lines
from line 6
66>
77> Last updated: **2026-08-22**
88
9This page outlines the Core Maintainers' vision for the protocol over the coming six to twelve months, highlighting objectives targeted for the next specification update and beyond. It describes our primary strategic goals and the expected deliverables from [Working and Interest Groups](/community/working-interest-groups).
9This page outlines the Core Maintainers' vision for the protocol over the coming six to twelve months, highlighting objectives targeted for the next specification update and beyond. It describes our primary strategic goals and the expected deliverables from [Working and Interest Groups](/community/working-interest-groups.md).
1010
1111> [!NOTE]
1212>
from line 14
1414
1515## SEP Prioritization
1616
17**[Specification Enhancement Proposals](/community/sep-guidelines) (SEPs) that fall within the priority areas below get expedited review and have the best chance of acceptance.** SEPs outside them aren't rejected automatically, but expect a longer queue and a higher bar for justification. Maintainer review time is scarce. We spend it here first.
17**[Specification Enhancement Proposals](/community/sep-guidelines.md) (SEPs) that fall within the priority areas below get expedited review and have the best chance of acceptance.** SEPs outside them aren't rejected automatically, but expect a longer queue and a higher bar for justification. Maintainer review time is scarce. We spend it here first.
1818
19If you're considering writing a SEP, start by identifying which priority area it belongs to and raising it with the relevant Working Group, then bring that group's support with the proposal. SEPs with a Working Group behind them and a clear line to this roadmap move fastest. See the [SEP guidelines](/community/sep-guidelines) for the full process.
19If you're considering writing a SEP, start by identifying which priority area it belongs to and raising it with the relevant Working Group, then bring that group's support with the proposal. SEPs with a Working Group behind them and a clear line to this roadmap move fastest. See the [SEP guidelines](/community/sep-guidelines.md) for the full process.
2020
21Each priority area names the Core Maintainers responsible for it, who can be reached on [Discord](/community/communication#discord) by anyone interested in contributing. The items listed under each area are the deliverables prioritized for this roadmap period. The remainder of each area is open scope, and Working Groups are expected to define and contribute further work within it.
21Each priority area names the Core Maintainers responsible for it, who can be reached on [Discord](/community/communication.md#discord) by anyone interested in contributing. The items listed under each area are the deliverables prioritized for this roadmap period. The remainder of each area is open scope, and Working Groups are expected to define and contribute further work within it.
2222
2323## Priority Areas
2424
from line 26
2626
2727Core Maintainers: [**Caitie McCaffrey**](https://github.com/CaitieM20), [**Clare Liguori**](https://github.com/clareliguori), [**Peter Alexander**](https://github.com/pja-ant)
2828
29Agentic workloads need [messaging patterns](/specification/2026-07-28/basic/patterns) beyond request and response: work that runs for minutes, servers that push, results that stream, and a way to steer work mid-flight. MCP has grown a set of concepts for this, including [Tasks](/extensions/tasks/overview), [`subscriptions/listen`](/specification/2026-07-28/basic/patterns/subscriptions), and [progress notifications](/specification/2026-07-28/basic/patterns/progress), spread across multiple Working Groups. The risk is three answers to "the server isn't done yet" that don't share a lifecycle, a cancellation model, or an error surface. We want them to compose.
29Agentic workloads need [messaging patterns](/specification/2026-07-28/basic/patterns.md) beyond request and response: work that runs for minutes, servers that push, results that stream, and a way to steer work mid-flight. MCP has grown a set of concepts for this, including [Tasks](/extensions/tasks/overview.md), [`subscriptions/listen`](/specification/2026-07-28/basic/patterns/subscriptions), and [progress notifications](/specification/2026-07-28/basic/patterns/progress.md), spread across multiple Working Groups. The risk is three answers to "the server isn't done yet" that don't share a lifecycle, a cancellation model, or an error surface. We want them to compose.
3030
3131**This roadmap period:**
3232
33* **Server-initiated events**: [Tasks & Events WG](/community/working-groups/tasks-events). Channels and subscriptions for push delivery, including webhooks. As we take on asynchronous workloads through Tasks and other events, we need extensions that let servers tell clients when work has finished, without relying purely on expensive client-side polling.
34* **A composition review**: [Tasks & Events](/community/working-groups/tasks-events) and Transports WGs, with the [Agents](/community/interest-groups/agents) IG. Primitives in the making, such as Tasks and Triggers, need to compose cleanly with each other and fit concrete use cases.
33* **Server-initiated events**: [Tasks & Events WG](/community/working-groups/tasks-events.md). Channels and subscriptions for push delivery, including webhooks. As we take on asynchronous workloads through Tasks and other events, we need extensions that let servers tell clients when work has finished, without relying purely on expensive client-side polling.
34* **A composition review**: [Tasks & Events](/community/working-groups/tasks-events.md) and Transports WGs, with the [Agents](/community/interest-groups/agents.md) IG. Primitives in the making, such as Tasks and Triggers, need to compose cleanly with each other and fit concrete use cases.
3535
36Beyond these, we expect continued work on Tasks ([SEP-2663](/seps/2663-tasks-extension)) toward eventual inclusion of the extension in the core protocol.
36Beyond these, we expect continued work on Tasks ([SEP-2663](/seps/2663-tasks-extension.md)) toward eventual inclusion of the extension in the core protocol.
3737
3838### 2. HTTP-Native Transport Unification and Hardening
3939
4040Core Maintainers: [**Kurtis Van Gent**](https://github.com/kurtisvg), [**Nick Cooper**](https://github.com/nickcoai)
4141
42The [2026-07-28 release](/specification/2026-07-28/changelog) made a remote MCP server a normal HTTP workload, and we increasingly rely on HTTP specifics such as headers and status codes to carry transport-level information. Every HTTP-native feature needs a second stdio-specific design or doesn't work locally. SDKs maintain two transport pipelines, and protocol metadata is now duplicated across HTTP headers and message fields that servers have to cross-validate. We want one transport model, with standard HTTP practice on top of it.
42The [2026-07-28 release](/specification/2026-07-28/changelog.md) made a remote MCP server a normal HTTP workload, and we increasingly rely on HTTP specifics such as headers and status codes to carry transport-level information. Every HTTP-native feature needs a second stdio-specific design or doesn't work locally. SDKs maintain two transport pipelines, and protocol metadata is now duplicated across HTTP headers and message fields that servers have to cross-validate. We want one transport model, with standard HTTP practice on top of it.
4343
4444**This roadmap period:**
4545
4646* **HTTP over stdio**: Transports WG. Streamable HTTP as the single binding, spoken over stdin/stdout for local servers. We believe we can use HTTP/2 over stdio to get multiplexed HTTP transport while retaining the security and lifecycle guarantees of a subprocess.
47* **Caching**: Transports WG. The most recent protocol revision made strides toward caching, adding `ttlMs` and `cacheScope` to list results and resource reads ([SEP-2549](/seps/2549-TTL-for-list-results)). As part of this work, we want to extend our caching approach to support ETags, which should allow versioning the results of primitives, in particular tool calls.
47* **Caching**: Transports WG. The most recent protocol revision made strides toward caching, adding `ttlMs` and `cacheScope` to list results and resource reads ([SEP-2549](/seps/2549-TTL-for-list-results.md)). As part of this work, we want to extend our caching approach to support ETags, which should allow versioning the results of primitives, in particular tool calls.
4848
49Beyond these, we want to look at standardized error handling across all surfaces, capability scoping for tool lists after [SEP-2575](/seps/2575-stateless-mcp), and providing servers with configuration options in a secure way.
49Beyond these, we want to look at standardized error handling across all surfaces, capability scoping for tool lists after [SEP-2575](/seps/2575-stateless-mcp.md), and providing servers with configuration options in a secure way.
5050
5151### 3. Agent Identity and Enterprise-Ready Security
5252
from line 57
5757**This roadmap period:**
5858
5959* **DPoP**: Agent Identity WG (forming during this roadmap period). Finalize the specification for Demonstrating Proof of Possession (DPoP) and focus on getting widespread adoption.
60* **Agent identity and delegation**: Agent Identity WG. We want an opinionated way for MCP servers to be reached by agents through their own identity or a user-delegated identity. The work will focus on Workload Identity Federation ([SEP-1933](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1933)), the Identity Assertion JWT Authorization Grant (ID-JAG) used by [Enterprise-Managed Authorization](/extensions/auth/enterprise-managed-authorization), and [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693) token exchange, coordinated with the IETF OAuth and [WIMSE](https://datatracker.ietf.org/wg/wimse/about/) working groups.
60* **Agent identity and delegation**: Agent Identity WG. We want an opinionated way for MCP servers to be reached by agents through their own identity or a user-delegated identity. The work will focus on Workload Identity Federation ([SEP-1933](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1933)), the Identity Assertion JWT Authorization Grant (ID-JAG) used by [Enterprise-Managed Authorization](/extensions/auth/enterprise-managed-authorization.md), and [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693) token exchange, coordinated with the IETF OAuth and [WIMSE](https://datatracker.ietf.org/wg/wimse/about/) working groups.
6161
6262Beyond these, several other topics are under discussion and may come into scope as the Working Group forms, including human-presence attestation for distinguishing interactive clients from headless agents and other agent identity concerns.
6363
from line 71
7171
7272* **Tool result shape**: Core Primitives WG (forming during this roadmap period). Redesign the `tools/call` interface to resolve fidelity disparities among return types and streamline the handling of structured and unstructured output.
7373* **Progressive discovery**: Core Primitives WG. Clients learn a server's tools and resources as they need them instead of ingesting the full catalog up front, with a defined interaction with the caching work under [HTTP-Native Transport Unification and Hardening](#2-http-native-transport-unification-and-hardening).
74* **Primitive annotations**: Core Primitives WG. [Content annotations](/specification/2026-07-28/server/resources#annotations) in the specification declare a piece of content's intended audience and priority. Applying them to tool results and resources could resolve the visibility confusion described in [SEP-2200](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2200), but most implementers haven't adopted these annotations and may not be aware of their purpose. If they aren't useful, we should consider deprecating them.
74* **Primitive annotations**: Core Primitives WG. [Content annotations](/specification/2026-07-28/server/resources.md#annotations) in the specification declare a piece of content's intended audience and priority. Applying them to tool results and resources could resolve the visibility confusion described in [SEP-2200](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2200), but most implementers haven't adopted these annotations and may not be aware of their purpose. If they aren't useful, we should consider deprecating them.
7575
76In addition, the [File Uploads WG](/community/working-groups/file-uploads) continues on scoped file operations and filesystem-like resource semantics (range reads, hierarchical listing).
76In addition, the [File Uploads WG](/community/working-groups/file-uploads.md) continues on scoped file operations and filesystem-like resource semantics (range reads, hierarchical listing).
7777
7878### 5. Improved SDK Developer Experience
7979
from line 83
8383
8484**This roadmap period:**
8585
86* **The extension contract**: [SDK WG](/community/working-groups/sdk) with the Core Maintainers. Which role an extension binds (host, client, server, agent) and what each does when the capability is declared; what SDKs must support natively; how extensions are packaged; capability additions as versioned changes to the extension; auth treated as its own area.
87* **The generated-artifacts experiment**: [SDK WG](/community/working-groups/sdk). Generate a candidate [Tier 1 SDK](/community/sdk-tiers) and its companion quickstart examples from the specification, validate both against the [conformance test suite](/community/sdk-tiers#conformance-testing), and publish findings with a recommendation for the next cycle, including which layers should be deterministic codegen versus model-assisted.
86* **The extension contract**: [SDK WG](/community/working-groups/sdk.md) with the Core Maintainers. Which role an extension binds (host, client, server, agent) and what each does when the capability is declared; what SDKs must support natively; how extensions are packaged; capability additions as versioned changes to the extension; auth treated as its own area.
87* **The generated-artifacts experiment**: [SDK WG](/community/working-groups/sdk.md). Generate a candidate [Tier 1 SDK](/community/sdk-tiers.md) and its companion quickstart examples from the specification, validate both against the [conformance test suite](/community/sdk-tiers.md#conformance-testing), and publish findings with a recommendation for the next cycle, including which layers should be deterministic codegen versus model-assisted.
8888
8989Beyond these, we want to revisit ownership and freshness expectations for the reference servers and quickstart repositories, and treat spec clarity issues surfaced by generation failures as documentation bugs.
9090
from line 92
9292
9393Every priority area above has a Working Group behind it or forming around it, and all of them have room for more contributors. There are several ways to participate:
9494
95* **Join a Working Group or Interest Group**: see the [Working and Interest Groups](/community/working-interest-groups) page and the [community channels](/community/communication).
96* **Propose or comment on a SEP**: read the [SEP guidelines](/community/sep-guidelines), then open one or weigh in.
97* **Start an experimental extension**: [SEP-2133](/seps/2133-extensions) lets any WG or IG experiment in an `experimental-ext-` repository before a formal SEP.
98* **Contribute directly**: the [contributing guide](/community/contributing) covers the specification, SDKs, and tooling.
95* **Join a Working Group or Interest Group**: see the [Working and Interest Groups](/community/working-interest-groups.md) page and the [community channels](/community/communication.md).
96* **Propose or comment on a SEP**: read the [SEP guidelines](/community/sep-guidelines.md), then open one or weigh in.
97* **Start an experimental extension**: [SEP-2133](/seps/2133-extensions.md) lets any WG or IG experiment in an `experimental-ext-` repository before a formal SEP.
98* **Contribute directly**: the [contributing guide](/community/contributing.md) covers the specification, SDKs, and tooling.
9999
docs/2024-11-05/develop/build-server Changed · +17 / -17 lines
from line 12
1212
1313> [!NOTE]
1414>
15> Servers can connect to any client. We've chosen Claude for Desktop here for simplicity, but we also have a guide on [building your own client](/docs/2024-11-05/develop/build-client).
15> Servers can connect to any client. We've chosen Claude for Desktop here for simplicity, but we also have a guide on [building your own client](/docs/2024-11-05/develop/build-client.md).
1616
1717### Core MCP Concepts
1818
1919MCP servers can provide three main types of capabilities:
2020
211. **[Resources](/docs/2024-11-05/learn/server-concepts#resources)**: File-like data that can be read by clients (like API responses or file contents)
222. **[Tools](/docs/2024-11-05/learn/server-concepts#tools)**: Functions that can be called by the LLM (with user approval)
233. **[Prompts](/docs/2024-11-05/learn/server-concepts#prompts)**: Pre-written templates that help users accomplish specific tasks
211. **[Resources](/docs/2024-11-05/learn/server-concepts.md#resources)**: File-like data that can be read by clients (like API responses or file contents)
222. **[Tools](/docs/2024-11-05/learn/server-concepts.md#tools)**: Functions that can be called by the LLM (with user approval)
233. **[Prompts](/docs/2024-11-05/learn/server-concepts.md#prompts)**: Pre-written templates that help users accomplish specific tasks
2424
2525This tutorial will primarily focus on tools.
2626
from line 253
253253
254254> [!NOTE]
255255>
256> Claude for Desktop is not yet available on Linux. Linux users can proceed to the [Building a client](/docs/2024-11-05/develop/build-client) tutorial to build an MCP client that connects to the server we just built.
256> Claude for Desktop is not yet available on Linux. Linux users can proceed to the [Building a client](/docs/2024-11-05/develop/build-client.md) tutorial to build an MCP client that connects to the server we just built.
257257
258258First, make sure you have Claude for Desktop installed. [You can install the latest version
259259here.](https://claude.ai/download) If you already have Claude for Desktop, **make sure it's updated to the latest version.**
from line 717
717717
718718> [!NOTE]
719719>
720> Claude for Desktop is not yet available on Linux. Linux users can proceed to the [Building a client](/docs/2024-11-05/develop/build-client) tutorial to build an MCP client that connects to the server we just built.
720> Claude for Desktop is not yet available on Linux. Linux users can proceed to the [Building a client](/docs/2024-11-05/develop/build-client.md) tutorial to build an MCP client that connects to the server we just built.
721721
722722First, make sure you have Claude for Desktop installed. [You can install the latest version
723723here.](https://claude.ai/download) If you already have Claude for Desktop, **make sure it's updated to the latest version.**
from line 1358
13581358
13591359> [!NOTE]
13601360>
1361> Claude for Desktop is not yet available on Linux. Linux users can proceed to the [Building a client](/docs/2024-11-05/develop/build-client) tutorial to build an MCP client that connects to the server we just built.
1361> Claude for Desktop is not yet available on Linux. Linux users can proceed to the [Building a client](/docs/2024-11-05/develop/build-client.md) tutorial to build an MCP client that connects to the server we just built.
13621362
13631363First, make sure you have Claude for Desktop installed. [You can install the latest version
13641364here.](https://claude.ai/download) If you already have Claude for Desktop, **make sure it's updated to the latest version.**
from line 1615
16151615
16161616> [!NOTE]
16171617>
1618> Claude for Desktop is not yet available on Linux. Linux users can proceed to the [Building a client](/docs/2024-11-05/develop/build-client) tutorial to build an MCP client that connects to the server we just built.
1618> Claude for Desktop is not yet available on Linux. Linux users can proceed to the [Building a client](/docs/2024-11-05/develop/build-client.md) tutorial to build an MCP client that connects to the server we just built.
16191619
16201620First, make sure you have Claude for Desktop installed. [You can install the latest version
16211621here.](https://claude.ai/download) If you already have Claude for Desktop, **make sure it's updated to the latest version.**
from line 1909
19091909
19101910> [!NOTE]
19111911>
1912> Claude for Desktop is not yet available on Linux. Linux users can proceed to the [Building a client](/docs/2024-11-05/develop/build-client) tutorial to build an MCP client that connects to the server we just built.
1912> Claude for Desktop is not yet available on Linux. Linux users can proceed to the [Building a client](/docs/2024-11-05/develop/build-client.md) tutorial to build an MCP client that connects to the server we just built.
19131913
19141914First, make sure you have Claude for Desktop installed. [You can install the latest version here.](https://claude.ai/download) If you already have Claude for Desktop, **make sure it's updated to the latest version.**
19151915
from line 2325
23252325
23262326> [!NOTE]
23272327>
2328> Claude for Desktop is not yet available on Linux. Linux users can proceed to the [Building a client](/docs/2024-11-05/develop/build-client) tutorial to build an MCP client that connects to the server we just built.
2328> Claude for Desktop is not yet available on Linux. Linux users can proceed to the [Building a client](/docs/2024-11-05/develop/build-client.md) tutorial to build an MCP client that connects to the server we just built.
23292329
23302330First, make sure you have Claude for Desktop installed. [You can install the latest version here.](https://claude.ai/download) If you already have Claude for Desktop, **make sure it's updated to the latest version.**
23312331
from line 2752
27522752
27532753> [!NOTE]
27542754>
2755> Claude for Desktop is not yet available on Linux. Linux users can proceed to the [Building a client](/docs/2024-11-05/develop/build-client) tutorial to build an MCP client that connects to the server we just built.
2755> Claude for Desktop is not yet available on Linux. Linux users can proceed to the [Building a client](/docs/2024-11-05/develop/build-client.md) tutorial to build an MCP client that connects to the server we just built.
27562756
27572757First, make sure you have Claude for Desktop installed. [You can install the latest version here.](https://claude.ai/download) If you already have Claude for Desktop, **make sure it's updated to the latest version.**
27582758
from line 2884
28842884>
28852885> **None of this is working. What do I do?**
28862886>
2887> Please refer to our [debugging guide](/docs/2024-11-05/tools/debugging) for better debugging tools and more detailed guidance.
2887> Please refer to our [debugging guide](/docs/2024-11-05/tools/debugging.md) for better debugging tools and more detailed guidance.
28882888
28892889> **Weather API Issues**
28902890>
from line 2908
29082908
29092909> [!NOTE]
29102910>
2911> For more advanced troubleshooting, check out our guide on [Debugging MCP](/docs/2024-11-05/tools/debugging)
2911> For more advanced troubleshooting, check out our guide on [Debugging MCP](/docs/2024-11-05/tools/debugging.md)
29122912
29132913## Next steps
29142914
2915> **[Building a client](/docs/2024-11-05/develop/build-client)**
2915> **[Building a client](/docs/2024-11-05/develop/build-client.md)**
29162916>
29172917> Learn how to build your own MCP client that can connect to your server
29182918
2919> **[Example servers](/examples)**
2919> **[Example servers](/examples.md)**
29202920>
29212921> Check out our gallery of official MCP servers and implementations
29222922
2923> **[Debugging Guide](/docs/2024-11-05/tools/debugging)**
2923> **[Debugging Guide](/docs/2024-11-05/tools/debugging.md)**
29242924>
29252925> Learn how to effectively debug MCP servers and integrations
29262926
2927> **[Build with Agent Skills](/docs/2024-11-05/develop/build-with-agent-skills)**
2927> **[Build with Agent Skills](/docs/2024-11-05/develop/build-with-agent-skills.md)**
29282928>
29292929> Use agent skills to guide AI coding assistants through server design
29302930
docs/2024-11-05/develop/build-with-agent-skills Changed · +6 / -6 lines
from line 57
5757Based on discovery, the skill recommends one of four paths and scaffolds
5858accordingly:
5959
60**Remote [HTTP with SSE](/specification/2024-11-05/basic/transports#http-with-sse)**
60**Remote [HTTP with SSE](/specification/2024-11-05/basic/transports.md#http-with-sse)**
6161is the default for anything wrapping a cloud API. Zero install friction, one
6262deployment serves all users, and OAuth flows work properly because the server
6363can handle redirects and token storage. The reference skill includes scaffolds
6464for Cloudflare Workers and portable Express/FastMCP setups.
6565
66**[MCP apps](/extensions/apps/overview)** extend a server with interactive
66**[MCP apps](/extensions/apps/overview.md)** extend a server with interactive
6767widgets rendered in chat, such as searchable pickers, charts, and live
6868dashboards. The skill hands off to `build-mcp-app` when plain text output
6969doesn't fit.
from line 74
7474must touch the user's machine: reading local files, driving desktop apps, or
7575talking to localhost services. The skill hands off to `build-mcpb`.
7676
77**Local [stdio](/specification/2024-11-05/basic/transports#stdio)** remains available
77**Local [stdio](/specification/2024-11-05/basic/transports.md#stdio)** remains available
7878for prototyping, with a noted upgrade path to MCPB when you're ready to
7979distribute.
8080
from line 83
8383Once your agent scaffolds the server, iterate on tool descriptions and error
8484handling, then test and ship:
8585
86> **[MCP Inspector](/docs/2024-11-05/tools/inspector)**
86> **[MCP Inspector](/docs/2024-11-05/tools/inspector.md)**
8787>
8888> Test your server's tools, resources, and prompts interactively
8989
90> **[Connect to a client](/docs/2024-11-05/develop/connect-local-servers)**
90> **[Connect to a client](/docs/2024-11-05/develop/connect-local-servers.md)**
9191>
9292> Wire your server into an MCP client via local or remote configuration
9393
94> **[Publish to the Registry](/registry/quickstart)**
94> **[Publish to the Registry](/registry/quickstart.md)**
9595>
9696> Make your server discoverable in the MCP Registry
9797
docs/2024-11-05/develop/connect-local-servers Changed · +4 / -4 lines
from line 204
204204
205205> **None of this is working. What do I do?**
206206>
207> Please refer to our [debugging guide](/docs/2024-11-05/tools/debugging) for better debugging tools and more detailed guidance.
207> Please refer to our [debugging guide](/docs/2024-11-05/tools/debugging.md) for better debugging tools and more detailed guidance.
208208
209209> **ENOENT error and `$\{APPDATA\}` in paths on Windows**
210210>
from line 244
244244> Browse our collection of official and community-created MCP servers for
245245> additional capabilities
246246
247> **[Build your own server](/docs/2024-11-05/develop/build-server)**
247> **[Build your own server](/docs/2024-11-05/develop/build-server.md)**
248248>
249249> Create custom MCP servers tailored to your specific workflows and
250250> integrations
251251
252> **[Connect to remote servers](/docs/2024-11-05/develop/connect-remote-servers)**
252> **[Connect to remote servers](/docs/2024-11-05/develop/connect-remote-servers.md)**
253253>
254254> Learn how to connect Claude to remote MCP servers for cloud-based tools and
255255> services
256256
257> **[Understand the protocol](/docs/2024-11-05/learn/architecture)**
257> **[Understand the protocol](/docs/2024-11-05/learn/architecture.md)**
258258>
259259> Dive deeper into how MCP works and its architecture
260260
docs/2024-11-05/develop/connect-remote-servers Changed · +4 / -4 lines
from line 19
1919With Custom Connectors, you can:
2020
2121* [Connect Claude to existing remote MCP servers](https://support.anthropic.com/en/articles/11175166-getting-started-with-custom-connectors-using-remote-mcp) provided by third-party developers
22* [Build your own remote MCP servers to connect with any tool](/docs/2024-11-05/develop/build-server)
22* [Build your own remote MCP servers to connect with any tool](/docs/2024-11-05/develop/build-server.md)
2323
2424## Connecting to a Remote MCP Server
2525
from line 81
8181
8282Now that you've connected Claude to a remote MCP server, you can explore its capabilities in your conversations. Try using the connected tools to automate tasks, access external data, or integrate with your existing workflows.
8383
84> **[Build your own remote server](/docs/2024-11-05/develop/build-server)**
84> **[Build your own remote server](/docs/2024-11-05/develop/build-server.md)**
8585>
8686> Create custom remote MCP servers to integrate with proprietary tools and
8787> services
from line 90
9090>
9191> Browse our collection of official and community-created MCP servers
9292
93> **[Connect local servers](/docs/2024-11-05/develop/connect-local-servers)**
93> **[Connect local servers](/docs/2024-11-05/develop/connect-local-servers.md)**
9494>
9595> Learn how to connect Claude Desktop to local MCP servers for direct system
9696> access
9797
98> **[Understand the architecture](/docs/2024-11-05/learn/architecture)**
98> **[Understand the architecture](/docs/2024-11-05/learn/architecture.md)**
9999>
100100> Dive deeper into how MCP works and its architecture
101101
docs/2024-11-05/getting-started/intro Changed · +6 / -6 lines
from line 29
2929
3030## Start Building
3131
32> **[Build servers](/docs/2024-11-05/develop/build-server)**
32> **[Build servers](/docs/2024-11-05/develop/build-server.md)**
3333>
3434> Create MCP servers to expose your data and tools
3535
36> **[Build clients](/docs/2024-11-05/develop/build-client)**
36> **[Build clients](/docs/2024-11-05/develop/build-client.md)**
3737>
3838> Develop applications that connect to MCP servers
3939
40> **[Build MCP Apps](/extensions/apps/overview)**
40> **[Build MCP Apps](/extensions/apps/overview.md)**
4141>
4242> Build interactive apps that run inside AI clients
4343
4444## Learn more
4545
46> **[Architecture](/docs/2024-11-05/learn/architecture)**
46> **[Architecture](/docs/2024-11-05/learn/architecture.md)**
4747>
4848> Learn the core concepts and architecture of MCP
4949
50> **[Security](/docs/2024-11-05/tutorials/security/security_best_practices)**
50> **[Security](/docs/2024-11-05/tutorials/security/security_best_practices.md)**
5151>
5252> Understand the security considerations and best practices for MCP
5353
5454## Community
5555
56> **[Contributing](/community/contributing)**
56> **[Contributing](/community/contributing.md)**
5757>
5858> Learn how to get involved and contribute to MCP
5959