Merge branch 'main' into feature/modelcontextchat-client

Author: vichudo

.gitattributes

@@ -1,2 +1,4 @@
 package-lock.json linguist-generated=true
 schema/*/schema.json linguist-generated=true
+docs/specification/*/schema.md linguist-generated=true
+docs/specification/*/schema.mdx linguist-generated=true

.github/workflows/main.yml

@@ -21,5 +21,8 @@ jobs:
       - name: Check TypeScript definitions
         run: npm run check:schema:ts
 
-      - name: Verify that `npm run generate:json` did not change outputs (if it did, please re-run it and re-commit!)
+      - name: Check schema.json files are up to date
         run: npm run check:schema:json
+
+      - name: Check schema.mdx files are up to date
+        run: npm run check:schema:md

.prettierignore

@@ -0,0 +1,2 @@
+docs/specification/*/schema.md
+docs/specification/*/schema.mdx

CONTRIBUTING.md

@@ -47,7 +47,7 @@ git checkout -b feature/your-feature-name
 
 ```bash
 npm run check:schema:ts
-npm run generate:json
+npm run generate:schema
 ```
 
 4. Validate documentation changes and apply formatting:

docs/community/governance.mdx

@@ -0,0 +1,146 @@
+---
+title: Governance and Stewardship
+description: Learn about the Model Context Protocol's governance structure and how to participate in the community
+---
+
+The Model Context Protocol (MCP) follows a formal governance model to ensure transparent decision-making and community participation. This document outlines how the project is organized and how decisions are made.
+
+## Technical Governance
+
+The MCP project adopts a hierarchical structure, similar to Python, PyTorch and other open source projects:
+
+- A community of **contributors** who file issues, make pull requests, and contribute to the project.
+- A small set of **maintainers** drive components within the MCP project, such as SDKs, documentation, and others.
+- Contributors and maintainers are overseen by **core maintainers**, who drive the overall project direction.
+- The core maintainers have two **lead core maintainers** who are the catch-all decision makers.
+- Maintainers, core maintainers, and lead core maintainers form the **MCP steering group**.
+
+All maintainers are expected to have a strong bias towards MCP's design philosophy. Membership in the technical governance process is for individuals, not companies. That is, there are no seats reserved for specific companies, and membership is associated with the person rather than the company employing that person. This ensures that maintainers act in the best interests of the protocol itself and the open source community.
+
+### Channels
+
+Technical Governance is facilitated through a shared Discord server of all **maintainers, core maintainers** and **lead maintainers**. Each maintainer group can choose additional communication channels, but all decisions and their supporting discussions must be recorded and made transparently available on the core group Discord server.
+
+### Maintainers
+
+Maintainers are responsible for individual projects or technical working groups within the MCP project. These generally are independent repositories such as language-specific SDKs, but can also extend to subdirectories of a repository, such as the MCP documentation. Maintainers may adopt their own rules and procedures for making decisions. Maintainers are expected to make decisions for their respective projects independently, but can defer or escalate to the core maintainers when needed.
+
+Maintainers are responsible for the:
+
+- Thoughtful and productive engagement with community contributors,
+- Maintaining and improving their respective area of the MCP project,
+- Supporting documentation, roadmaps and other adjacent parts of the MCP project,
+- Present ideas from community to core.
+
+Maintainers are encouraged to propose additional maintainers when needed. Maintainers can only be appointed and removed by core maintainers or lead core maintainers at any time and without reason.
+
+Maintainers have write and/or admin access to their respective repositories.
+
+### Core Maintainers
+
+The core maintainers are expected to have a deep understanding of the Model Context Protocol and its specification. Their responsibilities include:
+
+- Designing, reviewing and steering the evolution of the MCP specification, as well as all other parts of the MCP project, such as documentation,
+- Articulating a cohesive long-term vision for the project,
+- Mediating and resolving contentious issues with fairness and transparency, seeking consensus where possible while making decisive choices when necessary,
+- Appoint or remove maintainers,
+- Stewardship of the MCP project in the best interest of MCP.
+
+The core maintainers as a group have the power to veto any decisions made by maintainers by majority vote. The core maintainers have power to resolve disputes as they see fit. The core maintainers should publicly articulate their decision-making. The core group is responsible for adopting their own procedures for making decisions.
+
+Core maintainers generally have write and admin access to all MCP repositories, but should use the same contribution (usually pull-requests) mechanism as outside contributors. Exceptions can be made based on security considerations.
+
+### Lead Maintainers (BDFL)
+
+MCP has two lead maintainers: Justin Spahr-Summers and David Soria Parra. Lead Maintainers can veto any decision by core maintainers or maintainers. This model is also commonly known as Benevolent Dictator for Life (BDFL) in the open source community. The Lead Maintainers should publicly articulate their decision-making and give clear reasoning for their decisions. Lead maintainers are part of the core maintainer group.
+
+The Lead Maintainers are responsible for confirming or removing core maintainers.
+
+Lead Maintainers are administrators on all infrastructure for the MCP project where possible. This includes but is not restricted to all communication channels, GitHub organizations and repositories.
+
+### Decision Process
+
+The core maintainer group meets every two weeks to discuss and vote on proposals, as well as discuss any topics needed. The shared Discord server can be used to discuss and vote on smaller proposals if needed.
+
+The lead maintainer, core maintainer, and maintainer group should attempt to meet in person every three to six months.
+
+## Processes
+
+Core and lead maintainers are responsible for all aspects of Model Context Protocol, including documentation, issues, suggestions for content, and all other parts under the [MCP project](https://github.com/modelcontextprotocol). Maintainers are responsible for documentation, issues, and suggestions of content for their area of the MCP project, but are encouraged to partake in general maintenance of the MCP projects. Maintainers, core maintainers, and lead maintainers should use the same contribution process as external contributors, rather than making direct changes to repos. This provides insight into intent and opportunity for discussion.
+
+### Projects and Working Groups
+
+The MCP project is organized into two main structures: projects and working groups.
+
+Projects are concrete components maintained in dedicated repositories. These include the Specification, TypeScript SDK, Go SDK, Inspector, and other implementation artifacts.
+
+Working groups are forums for collaboration where interested parties discuss specific aspects of MCP without maintaining code repositories. These include groups focused on transport protocols, client implementation, and other cross-cutting concerns.
+
+#### Governance Principles
+
+All projects and working groups are self-governed while adhering to these core principles:
+
+1. Clear contribution and decision-making processes
+2. Open communication and transparent decisions
+
+Both must:
+
+- Document their contribution process
+- Maintain transparent communication
+- Make decisions publicly (working groups must publish meeting notes and proposals)
+
+Projects and working groups without specified processes default to:
+
+- GitHub pull requests and issues for contributions
+- A public channel in the official MCP Discord (TBD)
+
+#### Maintenance Responsibilities
+
+Components without dedicated maintainers (such as documentation) fall under core maintainer responsibility. These follow standard contribution guidelines through pull requests, with maintainers handling reviews and escalating to core maintainer review for any significant changes.
+
+Core maintainers and maintainers are encouraged to improve any part of the MCP project, regardless of formal maintenance assignments.
+
+### Specification Project
+
+#### Specification Enhancement Proposal (SEP)
+
+Proposed changes to the specification must come in the form of a written version, starting with a summary of the proposal, outlining the **problem** it tries to solve, propose **solution**, **alternatives**, **considerations, outcomes** and **risks**. The [SEP Guidelines](/community/sep-guidelines) outline information on the expected structure of SEPs. SEP's should be created as issues in the [specification repository](https://github.com/modelcontextprotocol/specification) and tagged with the labels `proposal, sep`.
+
+All proposals must have a **sponsor** from the MCP steering group (maintainer, core maintainer or lead core maintainer). The sponsor is responsible for ensuring that the proposal is actively developed, meets the quality standard for proposals and is responsible for presenting and discussing it in meetings of core maintainers. Maintainer and Core Maintainer groups should review open proposals without sponsors in regular intervals. Proposals that do not find a sponsor within six months are automatically rejected.
+
+Once proposals have a sponsor, they are assigned to the sponsor and are tagged `draft`.
+
+## Communication
+
+### Core Maintainer Meetings
+
+The core maintainer group meets on a bi-weekly basis to discuss proposals and the project. Notes on proposals should be made public. The core maintainer group will strive to meet in person every 3-6 months.
+
+### Public Chat
+
+The MCP project maintains a public Discord server with open chats for interest groups. The MCP project may have private channels for certain communications.
+
+## Nominating, Confirming and Removing Maintainers
+
+### The Principles
+
+- Membership in module maintainer groups is given to **individuals** on merit basis after they demonstrated strong expertise of their area of work through contributions, reviews, and discussions and are aligned with the overall MCP direction.
+- For membership in the **maintainer** group the individual has to demonstrate strong and continued alignment with the overall MCP principles.
+- No term limits for module maintainers or core maintainers
+- Light criteria of moving working-group or sub-project maintenance to 'emeritus' status if they don't actively participate over long periods of time. Each maintainer group may define the inactive period that's appropriate for their area.
+- The membership is for an individual, not a company.
+
+### Nomination and Removal
+
+- Core Maintainers are responsible for adding and removing maintainers. They will take the consideration of existing maintainers into account.
+- The lead maintainers are responsible for adding and removing core maintainers.
+
+## Current Core Maintainers
+
+- Inna Harper
+- Basil Hosmer
+- Paul Carleton
+- Nick Cooper
+- Nick Aldridge
+- Che Liu
+- Den Delimarsky

docs/community/sep-guidelines.mdx

@@ -0,0 +1,102 @@
+---
+title: SEP Guidelines
+description: Specification Enhancement Proposal (SEP) guidelines for proposing changes to the Model Context Protocol
+---
+
+## What is a SEP?
+
+SEP stands for Specification Enhancement Proposal. A SEP is a design document providing information to the MCP community, or describing a new feature for the Model Context Protocol or its processes or environment. The SEP should provide a concise technical specification of the feature and a rationale for the feature.
+
+We intend SEPs to be the primary mechanisms for proposing major new features, for collecting community input on an issue, and for documenting the design decisions that have gone into MCP. The SEP author is responsible for building consensus within the community and documenting dissenting opinions.
+
+Because the SEPs are maintained as text files in a versioned repository (GitHub Issues), their revision history is the historical record of the feature proposal.
+
+## SEP Types
+
+There are three kinds of SEP:
+
+1. **Standards Track** SEP describes a new feature or implementation for the Model Context Protocol. It may also describe an interoperability standard that will be supported outside the core protocol specification.
+2. **Informational** SEP describes a Model Context Protocol design issue, or provides general guidelines or information to the MCP community, but does not propose a new feature. Informational SEPs do not necessarily represent a MCP community consensus or recommendation.
+3. **Process** SEP describes a process surrounding MCP, or proposes a change to (or an event in) a process. Process SEPs are like Standards Track SEPs but apply to areas other than the MCP protocol itself.
+
+## SEP Workflow
+
+The SEP process begins with a new idea for the Model Context Protocol. It is highly recommended that a single SEP contain a single key proposal or new idea. Small enhancements or patches often don't need a SEP and can be injected into the MCP development workflow with a pull request to the MCP repo. The more focused the SEP, the more successful it tends to be.
+
+### SEP Author
+
+Each SEP must have an **SEP author** -- someone who writes the SEP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The SEP author should first attempt to ascertain whether the idea is SEP-able. Posting to the MCP community forums (Discord, GitHub Discussions) is the best way to go about this.
+
+### Submitting a SEP
+
+SEPs should be submitted as a GitHub Issue in the [specification repository](https://github.com/modelcontextprotocol/modelcontextprotocol). The draft must be written in the style of this SEP and must include:
+
+- A clear and concise title
+- A written motivation and rationale for the change
+- A pull request with the changes to the specification
+- Example code and usage patterns
+- Backwards compatibility analysis
+- Security analysis
+- At least one reference implementation
+
+The standard SEP workflow is:
+
+1. You, the SEP author, create a well-formatted GitHub Issue with the proposal and SEP tags
+2. Find a Core Maintainer or Maintainer to sponsor your proposal. Core Maintainers and Maintainers will regularly go over the list of open proposals to determine which proposals to sponsor. Once a sponsor is found, the sponsor is "assigned" to the issue and a milestone is assigned. The tag `draft` is added. At this point a unique SEP number is assigned.
+3. The sponsor will review and may request changes before formal review, based on community feedback. Once ready for review, the tag `in-review` is added.
+4. Once sponsored, the SEP enters formal review by the core team
+5. The SEP may be accepted, rejected, or returned for revision.
+6. If the SEP has not found a sponsor within three months, core-maintainers are free to close the SEP as `dormant`.
+
+### SEP States
+
+SEPs can be one one of the following states
+
+- `proposal:` SEP proposal without a sponsor.
+- `draft` : SEP proposal with a sponsor.
+- `in-review`: SEP proposal ready for review.
+- `accepted`: SEP accepted by core maintainers, but still requires final wording and reference implementation.
+- `rejected`: SEP rejected by core maintainers.
+- `withdrawn`: SEP withdrawn.
+- `final`: SEP finalized.
+- `superseded`: SEP has been replaced by a newer SEP.
+- `dormant`: SEP that has not found sponsors and was subsequently closed.
+
+### SEP Review & Resolution
+
+SEPs are reviewed by the MCP core maintainers team on a bi-weekly basis.
+
+For a SEP to be accepted it must meet certain minimum criteria:
+
+- A prototype implementation demonstrating the proposal
+- Clear benefit to the MCP ecosystem
+- Community support and consensus
+
+Once a SEP has been accepted, the reference implementation must be completed. When the reference implementation is complete and incorporated into the main source code repository, the status will be changed to "Final".
+
+A SEP can also be "Rejected" or "Withdrawn". A SEP that is "Withdrawn" may be re-submitted at a later date.
+
+## What belongs in a successful SEP?
+
+Each SEP should have the following parts:
+
+1. **Preamble** -- A short descriptive title, the names and contact info for each author, the current status.
+2. **Abstract** -- a short (~200 word) description of the technical issue being addressed.
+3. **Motivation** -- The motivation is critical for SEPs that want to change the Model Context Protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the SEP solves. SEP submissions without sufficient motivation may be rejected outright.
+4. **Rationale** -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
+5. **Specification** -- The technical specification should describe the syntax and semantics of any new protocol feature. The specification should be detailed enough to allow competing, interoperable implementations. A PR with the changes to the specification should be provided.
+6. **Backwards Compatibility** -- All SEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The SEP must explain how the author proposes to deal with these incompatibilities.
+7. **Reference Implementation** -- The reference implementation must be completed before any SEP is given status "Final", but it need not be completed before the SEP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of protocol details.
+8. **Security Implications** -- If there are security concerns in relation to the SEP, those concerns should be explicitly written out to make sure reviewers of the SEP are aware of them.
+
+## Reporting SEP Bugs, or Submitting SEP Updates
+
+How you report a bug, or submit a SEP update depends on several factors, such as the maturity of the SEP, the preferences of the SEP author, and the nature of your comments. For SEPs not yet reaching `final` state, it's probably best to send your comments and changes directly to the SEP author. Once SEP is finalized, you may want to submit corrections as a GitHub comment on the issue or pull request to the reference implementation.
+
+## Transferring SEP Ownership
+
+It occasionally becomes necessary to transfer ownership of SEPs to a new SEP author. In general, we'd like to retain the original author as a co-author of the transferred SEP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the SEP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the SEP. We try to build consensus around a SEP, but if that's not possible, you can always submit a competing SEP.
+
+## Copyright
+
+This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.