One read of Model Context Protocolmcp-20260814T095811Z

community/antitrust First recorded · 61 lines, first recorded

# Antitrust Policy ## Introduction ## Participation ## Conduct of Meetings ## Requirements/Standard Setting ## Contact Information

The first capture of this source. The page was already there, and this is what it said.

# Antitrust Policy

> MCP Project Antitrust Policy for participants and contributors

**Effective: September 29, 2025**

<Note>
  This policy applies when participating in MCP meetings, Working Groups,
  Interest Groups, and other collaborative forums where competitors may be
  present. Most individual contributors working on code or documentation don't
  need to worry about this in day-to-day work - it's primarily relevant for
  group discussions about standards and specifications.
</Note>

## Introduction

The goal of the Model Context Protocol open source project (the "Project") is to develop a universal standard for model-to-world interactions, including enabling LLMs and agents to seamlessly connect with and utilize external data sources and tools. The purpose of this Antitrust Policy (the "Policy") is to avoid antitrust risks in carrying out this pro-competitive mission.

Participants in and contributors to the Project (collectively, "participants") will use their best reasonable efforts to comply in all respects with all applicable state and federal antitrust and trade regulation laws, and applicable antitrust/competition laws of other countries (collectively, the "Antitrust Laws").

The goal of Antitrust Laws is to encourage vigorous competition. Nothing in this Policy prohibits or limits the ability of participants to make, sell or use any product, or otherwise to compete in the marketplace. This Policy provides general guidance on compliance with Antitrust Law. Participants should contact their respective legal counsel to address specific questions.

This Policy is conservative and is intended to promote compliance with the Antitrust Laws, not to create duties or obligations beyond what the Antitrust Laws actually require. In the event of any inconsistency between this Policy and the Antitrust Laws, the Antitrust Laws preempt and control.

## Participation

Technical participation in the Project shall be open to all, subject only to compliance with the provisions of the Project's charter and other governance documents.

## Conduct of Meetings

At meetings among actual or potential competitors, there is a risk that participants in those meetings may improperly disclose or discuss information in violation of the Antitrust Laws or otherwise act in an anti-competitive manner. To avoid this risk, participants must adhere to the following policies when participating in Project-related or sponsored meetings, conference calls, or other forums (collectively, "Project Meetings").

Participants must not, in fact or appearance, discuss or exchange information regarding:

* An individual company's current or projected prices, price changes, price differentials, markups, discounts, allowances, terms and conditions of sale, including credit terms, etc., or data that bear on prices, including profits, margins or cost.
* Industry-wide pricing policies, price levels, price changes, differentials, or the like.
* Actual or projected changes in industry production, capacity or inventories.
* Matters relating to bids or intentions to bid for particular products, procedures for responding to bid invitations or specific contractual arrangements.
* Plans of individual companies concerning the design, characteristics, production, distribution, marketing or introduction dates of particular products, including proposed territories or customers.
* Matters relating to actual or potential individual suppliers that might have the effect of excluding them from any market or of influencing the business conduct of firms toward such suppliers.
* Matters relating to actual or potential customers that might have the effect of influencing the business conduct of firms toward such customers.
* Individual company current or projected cost of procurement, development or manufacture of any product.
* Individual company market shares for any product or for all products.
* Confidential or otherwise sensitive business plans or strategy.

In connection with all Project Meetings, participants must do the following:

* Adhere to prepared agendas.
* Insist that meeting minutes be prepared and distributed to all participants, and that meeting minutes accurately reflect the matters that transpired.
* Consult with their respective counsel on all antitrust questions related to Project Meetings.
* Protest against any discussions that appear to violate these policies or the Antitrust Laws, leave any meeting in which such discussions continue, and either insist that such protest be noted in the minutes.

## Requirements/Standard Setting

The Project may establish standards, technical requirements and/or specifications for use (collectively, "requirements"). Participants shall not enter into agreements that prohibit or restrict any participant from establishing or adopting any other requirements. Participants shall not undertake any efforts, directly or indirectly, to prevent any firm from manufacturing, selling, or supplying any product not conforming to a requirement.

The Project shall not promote standardization of commercial terms, such as terms for license and sale.

## Contact Information

To contact the Project regarding matters addressed by this Antitrust Policy, please send an email to [[email protected]](mailto:[email protected]), and reference "Antitrust Policy" in the subject line.

community/charter-template First recorded · 154 lines, first recorded

# Group Charter Template ## Example Mission Statements

The first capture of this source. The page was already there, and this is what it said.

# Group Charter Template

> Template for MCP Working Group and Interest Group charters.

Every MCP Working Group and Interest Group must maintain a charter document following this structure. Charters are stored at `docs/community/working-groups/<group-name>.mdx` or `docs/community/interest-groups/<group-name>.mdx` in the [modelcontextprotocol repository](https://github.com/modelcontextprotocol/modelcontextprotocol) and added to `docs/docs.json`.

The charter captures information specific to your group. Governance rules — leadership requirements, decision-making process, meeting requirements, escalation paths — are defined in the [Working and Interest Groups](/community/working-interest-groups) documentation and apply automatically. Do not repeat them here.

Sections marked **(WG only)** are required for Working Groups and optional for Interest Groups.

<Note>
  Copy the markdown below into `docs/community/working-groups/<group-name>.mdx` (or `interest-groups/` for an IG) and replace the placeholder text.
</Note>

***

```markdown theme={null}
---
title: <Group Name> Charter
description: Charter for the MCP <Group Name> <Working Group | Interest Group>.
---

## Group Type

<!-- State whether this is a Working Group or an Interest Group. -->

**Working Group** | **Interest Group**

## Mission Statement

<!--
A 2-3 sentence summary of the group's purpose.
- The problem space being addressed
- Why cross-cutting collaboration is needed
- For WGs: what concrete deliverables the group will produce
- For IGs: what discussions and knowledge-sharing the group will facilitate
-->

## Scope

### In Scope

<!--
For WGs:
- Specification Work: Specific spec sections or SEPs owned
- Reference Implementations: SDK components or reference implementations
- Cross-Cutting Concerns: Areas requiring coordination with other groups
- Documentation: Documentation responsibilities

For IGs:
- Topic areas for discussion
- Types of output (problem statements, use cases, recommendations)
-->

### Out of Scope

<!-- Explicit statements of what is NOT within the group's purview to prevent mission creep. -->

### Related Groups

<!-- List of other WGs or IGs with intersecting work and the nature of overlap. -->

## Leadership

<!--
Leadership requirements and responsibilities are defined in the governance rules.
List current Leads (WG) or Facilitators (IG).
-->

| Role | Name | Organization | GitHub | Term |
| ---- | ---- | ------------ | ------ | ---- |
|      |      |              |        |      |

## Authority & Decision Rights (WG only)

<!--
The decision-making process (lazy consensus → vote → escalation) is defined in
the governance rules. This table documents which decisions this WG can make at
which authority level.

IGs do not make binding decisions and do not need this section.
-->

| Decision Type                       | Authority Level                                        |
| ----------------------------------- | ------------------------------------------------------ |
| Meeting logistics & scheduling      | WG Leads (autonomous)                                  |
| Proposal prioritization within WG   | WG Leads (autonomous)                                  |
| SEP triage & closure (in scope)     | WG Leads (autonomous, with documented rationale)       |
| Technical design within scope       | WG consensus                                           |
| Spec changes (additive)             | WG consensus → Core Maintainer approval                |
| Spec changes (breaking/fundamental) | WG consensus → Core Maintainer approval + wider review |
| Scope expansion                     | Core Maintainer approval required                      |
| WG Member approval                  | WG Member sponsors                                     |

## Membership

<!--
List current group members and their participation levels, if any.
Leave out if no members exist yet. Participation tiers and membership
criteria are defined in the governance rules.
-->

| Name | Organization | GitHub | Discord | Level |
| ---- | ------------ | ------ | ------- | ----- |
|      |              |        |         |       |

## Operations

<!--
Document the group's current meeting approach. Meeting requirements (open,
published 7 days ahead, agendas/notes to GitHub Discussions) and communication
channels are defined in the governance rules.
-->

| Meeting         | Frequency | Duration | Purpose                               |
| --------------- | --------- | -------- | ------------------------------------- |
| Working Session |           |          | Technical discussion, proposal review |
| Office Hours    |           |          | Open Q&A for newcomers and observers  |

## Deliverables & Success Metrics (WG only)

<!--
Track active work items with status and ownership.
IGs may optionally list current discussion topics or planned outputs here.
-->

### Active Work Items

| Item          | Status                    | Target Date | Champion |
| ------------- | ------------------------- | ----------- | -------- |
| SEP-XXX: Name | Draft / Review / Approved |             |          |

### Success Criteria

<!-- Measurable outcomes for WG success. -->

## Changelog

| Date | Change |
| ---- | ------ |
|      |        |
```

***

## Example Mission Statements

**Working Group:**

> The Transport Working Group exists to evolve MCP's transport mechanisms to support diverse deployment scenarios—from local subprocess communication to horizontally-scaled cloud deployments—while maintaining protocol coherence and backward compatibility.

**Interest Group:**

> The Enterprise IG explores the challenges of deploying MCP in enterprise environments, gathering use cases and requirements to inform future specification work.

community/communication First recorded · 109 lines, first recorded

# Contributor Communication ## Communication Channels ## Discord ### Public Channels (Default) ### Private Channels (Exceptions) ## GitHub Discussions ## GitHub Issues ## Security Issues ## Decision Records

The first capture of this source. The page was already there, and this is what it said.

# Contributor Communication

> Communication strategy and framework for the Model Context Protocol community

This document explains how to communicate and collaborate within the Model Context Protocol (MCP) project.

## Communication Channels

| Channel                                                                                                     | Purpose               | When to Use                                      |
| ----------------------------------------------------------------------------------------------------------- | --------------------- | ------------------------------------------------ |
| [Discord](https://discord.gg/6CSzBmMkjX)                                                                    | Real-time discussion  | Quick questions, coordination, WG/IG discussions |
| [Live calls](https://meet.modelcontextprotocol.io/)                                                         | Sync up               | WG/IG presentations, progress reports            |
| [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions)              | Structured discussion | Proposals, roadmap planning, longer-form debate  |
| [GitHub Issues](https://github.com/modelcontextprotocol/modelcontextprotocol/issues)                        | Actionable tasks      | Bug reports, documentation fixes                 |
| [Vulnerability reports](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SECURITY.md) | Security issues       | Vulnerabilities - **never post publicly**        |

All communication is governed by our [Code of Conduct](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/CODE_OF_CONDUCT.md). We expect respectful, professional, and inclusive interactions across all channels.

## Discord

The [MCP Contributor Discord](https://discord.gg/6CSzBmMkjX) is for real-time contributor discussion and collaboration. The server is designed for **MCP contributors** and is not intended for general MCP support.

### Public Channels (Default)

**Purpose:** Open community engagement, collaborative development, and transparent project coordination.

**Primary use cases:**

* SDK and tooling development (e.g., `#typescript-sdk-dev`, `#inspector-dev`)
* [Working Group and Interest Group](/community/working-interest-groups) discussions (e.g., `#auth-wg`, `#security-ig`)
* Community onboarding and contribution guidance
* Community feedback and collaborative brainstorming
* Public office hours and maintainer availability

**Avoid:**

* MCP user support - Read official documentation and use GitHub Discussions for questions
* Service or product marketing - Keep discussions vendor-neutral; mentions of brands are discouraged except as examples relevant to the specification

### Private Channels (Exceptions)

**Purpose:** Confidential coordination and sensitive matters. Access is restricted to designated maintainers.

**Criteria for private use:**

* Security incidents (CVEs, protocol vulnerabilities)
* People matters (maintainer discussions, code of conduct issues)
* Coordination requiring immediate or focused response with a limited audience
* Some channels are read-only for maintainer decision-making

**Transparency requirements:**

* All technical and governance decisions affecting the community must be documented in GitHub Discussions and/or Issues, labeled with `notes`
* Private channels are temporary "incident rooms," not for routine development
* Some matters related to individual contributors may remain private when appropriate

Any significant discussion on Discord that leads to a potential decision or proposal must be moved to GitHub Discussion or Issue for a persistent, searchable record.

## GitHub Discussions

Use for structured, long-form discussion and debate on project direction.

**When to use:**

* Project roadmap planning and milestone discussions
* Announcements and release communications
* Community polls and consensus-building
* Feature requests with context and rationale
* If a repository doesn't have Discussions enabled, use GitHub Issues instead

## GitHub Issues

Use for bug reports and actionable development tasks. Feature requests should go to [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions).

**When to use:**

* Bug reports with reproducible steps
* Documentation improvements with specific scope
* CI/CD problems and infrastructure issues
* Release tasks and milestone tracking

**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).

## Security Issues

**Do not post security issues publicly.**

1. Use the private security reporting process in [SECURITY.md](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SECURITY.md)
2. Contact Lead or [Core Maintainers](/community/governance#current-core-maintainers) directly
3. Follow responsible disclosure guidelines

## Decision Records

All MCP decisions are documented in public channels:

| Type                  | Location                                                                                      |
| --------------------- | --------------------------------------------------------------------------------------------- |
| Technical decisions   | [GitHub Issues](https://github.com/modelcontextprotocol/modelcontextprotocol/issues) and SEPs |
| Specification changes | [Changelog](https://modelcontextprotocol.io/specification/draft/changelog)                    |
| Process changes       | [Community documentation](https://modelcontextprotocol.io/community/governance)               |
| Governance decisions  | [GitHub Issues](https://github.com/modelcontextprotocol/modelcontextprotocol/issues) and SEPs |

When documenting decisions, we retain as much context as possible:

* Decision makers
* Background context and motivation
* Options considered
* Rationale for chosen approach
* Implementation steps

community/contributing First recorded · 573 lines, first recorded

# Contributing to MCP ## Before You Begin ### Prerequisites ### Repository Structure ### Project Roles ## Your First Contribution ### Step 1: Set Up Your Environment ### Step 2: Find Something to Work On ### Step 3: Make Your Change ### Step 4: Submit a Pull Request ### What Makes a Good Contribution ## Types of Contributions ### Small Changes (Direct PR) ### Major Changes (SEP Required) ## Working with the Specification Repository ### Schema Changes ### Documentation Changes ### Major Protocol Changes ## Working with the SDK Repositories ### Before Contributing to an SDK ### SDK Repositories ## Getting Help ### Communication Channels ### Finding a Sponsor for SEPs ## Troubleshooting ### `npm run check` fails ### My PR has been sitting unnoticed for weeks ### I can't find a sponsor for my SEP ### My SEP was rejected ## Out of Scope ## AI Contributions ## Code of Conduct ## License

The first capture of this source. The page was already there, and this is what it said.

# Contributing to MCP

> How to contribute to the Model Context Protocol project

The Model Context Protocol (MCP) is an open source project that welcomes contributions from the
community. This guide walks you through everything you need to get started.

## Before You Begin

### Prerequisites

Before contributing, ensure you have the following installed and ready:

* **[Git](https://git-scm.com/downloads)** - For cloning repositories and submitting changes
* **[Node.js 24+](https://nodejs.org/)** - Required for building and testing our projects
* **npm** - Comes with Node.js, used for dependency management
* **[GitHub account](https://github.com/signup)** - For submitting pull requests and issues
* **Language-specific tooling** - If contributing to an SDK, you'll need the appropriate
  development environment for that language (e.g., Python, Rust, Go)

Verify your setup:

```bash theme={null}
node --version  # Should be 24.x or higher
npm --version   # Should be 11.x or higher
git --version   # Any recent version
```

<Note>
  These commands work the same on macOS, Linux, and Windows, so you're good to
  go on any platform.
</Note>

### Repository Structure

MCP spans multiple repositories in the
[`modelcontextprotocol`](https://github.com/modelcontextprotocol) organization on GitHub. Here are
a few notable sub-projects worth checking out:

| Repository                                                                                                  | Contents                  |
| ----------------------------------------------------------------------------------------------------------- | ------------------------- |
| [`modelcontextprotocol/modelcontextprotocol`](https://github.com/modelcontextprotocol/modelcontextprotocol) | Specification, docs, SEPs |
| [`modelcontextprotocol/typescript-sdk`](https://github.com/modelcontextprotocol/typescript-sdk)             | TypeScript/JavaScript SDK |
| [`modelcontextprotocol/python-sdk`](https://github.com/modelcontextprotocol/python-sdk)                     | Python SDK                |
| [`modelcontextprotocol/go-sdk`](https://github.com/modelcontextprotocol/go-sdk)                             | Go SDK                    |
| [`modelcontextprotocol/java-sdk`](https://github.com/modelcontextprotocol/java-sdk)                         | Java SDK                  |
| [`modelcontextprotocol/kotlin-sdk`](https://github.com/modelcontextprotocol/kotlin-sdk)                     | Kotlin SDK                |
| [`modelcontextprotocol/csharp-sdk`](https://github.com/modelcontextprotocol/csharp-sdk)                     | C# SDK                    |
| [`modelcontextprotocol/swift-sdk`](https://github.com/modelcontextprotocol/swift-sdk)                       | Swift SDK                 |
| [`modelcontextprotocol/rust-sdk`](https://github.com/modelcontextprotocol/rust-sdk)                         | Rust SDK                  |
| [`modelcontextprotocol/ruby-sdk`](https://github.com/modelcontextprotocol/ruby-sdk)                         | Ruby SDK                  |
| [`modelcontextprotocol/php-sdk`](https://github.com/modelcontextprotocol/php-sdk)                           | PHP SDK                   |

Throughout this guide, **specification repository** refers to
`modelcontextprotocol/modelcontextprotocol`, which contains the protocol spec, this documentation
site, and [Spec Enhancement Proposals (SEPs)](/community/sep-guidelines).

### Project Roles

MCP follows a [governance model](/community/governance) with different levels of responsibility:

* **Contributors** - Anyone who files issues, submits PRs, or participates in discussions (that's
  you!)
* **Maintainers** - Steward specific areas like SDKs, documentation, or
  [Working Groups](/community/working-interest-groups)
* **Core Maintainers** - Guide overall project direction, review SEPs, and oversee the specification

You can find the current list of maintainers in the
[`MAINTAINERS.md`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md)
file.

Maintainers are here to help you succeed! Don't hesitate to reach out if you have questions or
need guidance on your contribution.

## Your First Contribution

Start here if you are new to MCP and contributing to its ecosystem.

<Note>
  While we use the specification repository as an example, the key patterns are
  applicable to other MCP repos as well.
</Note>

### Step 1: Set Up Your Environment

Set up your local environment so you can test and validate changes before submitting them.

<Steps>
  <Step title="Fork the repository">
    Click the **Fork** button on the [repository page](https://github.com/modelcontextprotocol/modelcontextprotocol) to create your own copy. This gives you a personal workspace where you can make changes without affecting the main project.
  </Step>

  <Step title="Clone your fork">
    ```bash theme={null}
    git clone https://github.com/YOUR-USERNAME/modelcontextprotocol.git
    cd modelcontextprotocol
    ```

    Replace `YOUR-USERNAME` with your GitHub username.
  </Step>

  <Step title="Install dependencies">
    ```bash theme={null}
    npm install
    ```

    This installs the tools needed for schema generation, documentation building, and validation.
  </Step>

  <Step title="Verify everything works">
    ```bash theme={null}
    npm run check
    ```

    This runs TypeScript compilation, schema validation, example validation, documentation link checks, and formatting checks. If everything passes, your environment is good and you're ready to contribute.
  </Step>
</Steps>

If `npm run check` fails, see [Troubleshooting](#troubleshooting) below.

### Step 2: Find Something to Work On

While a lot of the items you might see tracked in the repository can feel intimidating, especially
for newcomers, there are plenty of places where you can start with your first improvements:

1. **Documentation improvements** - Help us fix typos, unclear explanations, broken links, or
   incomplete examples
2. **Issues labeled `good first issue`** - Tackle issues tagged in the
   [specification repo](https://github.com/modelcontextprotocol/modelcontextprotocol/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
   as well as our SDK repos
3. **Schema examples** - Add examples to `schema/draft/examples/` to make it easier for developers
   to understand protocol primitives

### Step 3: Make Your Change

Create your changes in a dedicated branch.

<Steps>
  <Step title="Create a branch">
    ```bash theme={null}
    git checkout -b fix/your-description
    ```

    Use a descriptive branch name that reflects your change, like `fix/typo-in-tools-doc` or `feat/add-example-for-resources`.
  </Step>

  <Step title="Make your changes">
    Edit the relevant files in your local copy. If you're editing schema files, remember to run `npm run generate:schema` to regenerate the JSON schema and documentation.
  </Step>

  <Step title="Run checks">
    ```bash theme={null}
    npm run check
    ```

    Fix any issues before committing. If you have formatting errors, `npm run format` can auto-fix most of them.
  </Step>

  <Step title="Commit with a clear message">
    ```bash theme={null}
    git commit -m "Fix typo in tools documentation"
    ```

    Write a concise message that describes what you changed and why. Reference issue numbers if applicable (e.g., `Fix typo in tools documentation (#123)`).
  </Step>
</Steps>

### Step 4: Submit a Pull Request

When you're ready, push your branch and open a pull request.

<Steps>
  <Step title="Push your branch">
    ```bash theme={null}
    git push origin fix/your-description
    ```
  </Step>

  <Step title="Open a PR on GitHub">
    You can use the [GitHub CLI](https://cli.github.com/) to make this process easier:

    ```bash theme={null}
    gh pr create --fill
    ```

    Alternatively, navigate to your fork on GitHub and click **Compare & pull request**.
  </Step>

  <Step title="Fill in the PR template">
    Provide a clear description of your changes and link any related issues.
  </Step>

  <Step title="Wait for review">
    Maintainers typically respond within 1-5 business days.
  </Step>
</Steps>

<Tip>
  That's it, **congratulations on your first contribution**! Every improvement,
  no matter how small, helps make MCP better for everyone.
</Tip>

### What Makes a Good Contribution

Help us review your contribution quickly by following these patterns:

| Harder to Review                             | Thoughtful and Impactful                         |
| -------------------------------------------- | ------------------------------------------------ |
| Large PR with unrelated changes              | Focused PR addressing one issue                  |
| Reformatting code without functional changes | Fixing a bug with a clear explanation            |
| Vague commit messages ("fixed stuff")        | Descriptive commits linking to issues            |
| Submitting with failing CI checks            | All CI tests pass before requesting review       |
| Duplicating existing documentation           | Documenting an undocumented feature or edge case |

## Types of Contributions

Different contributions follow different processes depending on their scope.

<Tip>
  Not sure which category your change falls into? Ask in the [MCP Contributor
  Discord](/community/communication#discord) before starting any significant
  work.
</Tip>

### Small Changes (Direct PR)

Simply submit a pull request directly to the repo for:

* Bug fixes and typo corrections
* Documentation improvements, such as bringing clarity to an ambiguous or unclear section
* Adding examples to existing features
* Minor schema fixes that don't materially change the specification or SDK behavior
* Test improvements

### Major Changes (SEP Required)

Anything that changes the MCP specification requires following the
[Specification Enhancement Proposal (SEP)](/community/sep-guidelines) process. This includes, but
is not limited to:

* New protocol features or API methods
* Breaking changes to existing behavior
* Changes to the message format or schema structure
* New interoperability standards
* Governance or process changes

Here are a few concrete examples of what would require following the SEP steps:

* Adding a new RPC method like `tools/execute`
* Changing how authentication and authorization works
* Adding a new capability negotiation field
* Modifying the transport layer specification

## Working with the Specification Repository

Once you've determined [what type of contribution](#types-of-contributions) you're making, here's
how to work with the specification repository.

### Schema Changes

The TypeScript schema (`schema/draft/schema.ts`) is the **source of truth** for the protocol. It
defines every message type, request/response structure, and primitive (tools, resources, prompts)
that clients and servers exchange. SDK implementers across all languages rely on this schema to
build conformant implementations.

When you run `npm run generate:schema`, it generates:

* The JSON schema (`schema/draft/schema.json`) for validation
* The Schema Reference documentation (`docs/specification/draft/schema.mdx`)

To modify the schema:

<Steps>
  <Step title="Edit the TypeScript schema">
    Make your changes in `schema/draft/schema.ts`.
  </Step>

  <Step title="Add examples (optional)">
    Add JSON examples in `schema/draft/examples/[TypeName]/` (e.g., `Tool/my-example.json`). Reference them in the schema using `@example` + `@includeCode` JSDoc tags.
  </Step>

  <Step title="Generate JSON schema and docs">
    ```bash theme={null}
    npm run generate:schema
    ```
  </Step>

  <Step title="Validate your changes">
    ```bash theme={null}
    npm run check
    ```
  </Step>
</Steps>

### Documentation Changes

Docs are written in [MDX format](https://mdxjs.com/) (Markdown with JSX components) and powered by
[Mintlify](https://mintlify.com/). The `docs/` directory contains:

* `docs/docs/` - Guides and tutorials for getting started and building with MCP

Cut at 300 lines. The page has the rest.

community/contributor-ladder First recorded · 378 lines, first recorded

# Contributor Ladder ## Guiding Principles ## Roles at a Glance ## Contributor ## Member ## Maintainer ## Core Maintainer ## Lead Maintainer ### Succession ## Community Moderator ## Working Group and Interest Group Leadership ## Advancement Process ### Self-Nomination vs. Recognition ### Process Steps ## Decision-Making and Escalation ### Delegation as Default ### Escalation Matrix ## Contribution Pathways ## Stepping Down and Emeritus Status ## Recognition and Visibility

The first capture of this source. The page was already there, and this is what it said.

# Contributor Ladder

> Roles, responsibilities, and advancement criteria for MCP contributors, from first contribution to Core Maintainer

The 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.

This document implements [SEP-2148](/seps/2148-contributor-ladder). For Working Group and Interest Group governance, see [SEP-2149](/seps/2149-working-group-charter-template).

## Guiding Principles

* **Earned Trust.** Advancement follows from demonstrated contributions, good judgment, and sustained engagement. Tenure alone is not enough.
* **Multiple Growth Pathways.** Code, specification work, documentation, and community building all lead to advancement.
* **Transparency.** Criteria for advancement are explicit and applied consistently.
* **Alignment With MCP Goals.** Contributors must show commitment to MCP beyond any single employer's interests.

## Roles at a Glance

| Role                                            | Summary                                       | Key Privileges                                                            | Minimum Timeline                                      |
| ----------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------- | ----------------------------------------------------- |
| [**Contributor**](#contributor)                 | Anyone who contributes to MCP                 | Submit issues, PRs, participate in discussions                            | Immediate                                             |
| [**Member**](#member)                           | Established, active contributor               | GitHub org membership, triage rights, eligible for WG/IG leadership       | 2-3 months of meaningful contributions                |
| [**Maintainer**](#maintainer)                   | Area steward with operational responsibility  | Merge rights, release participation                                       | 6+ months as Member                                   |
| [**Core Maintainer**](#core-maintainer)         | Technical leadership and protocol stewardship | Final decision authority, governance participation                        | By invitation after sustained Maintainer contribution |
| [**Lead Maintainer**](#lead-maintainer)         | Ultimate project authority (founders)         | All Core Maintainer privileges, veto authority, appoints Core Maintainers | Reserved for project founders; succession only        |
| [**Community Moderator**](#community-moderator) | CoC enforcement and community health          | Moderation rights on community platforms, incident handling               | Parallel track: Member status + appointment           |

<Note>
  Timelines are minimums, not guarantees. They protect the project from rapid
  privilege escalation and ensure a high bar of demonstrated commitment. Actual
  advancement is discretionary and may take longer. Exceptions require explicit
  Core Maintainer approval with documented rationale.
</Note>

***

## Contributor

Anyone who has contributed to MCP in any form is a Contributor. This includes opening issues, submitting pull requests, participating in working group discussions, improving documentation, or helping other community members.

**There are no formal requirements.** We welcome all contributions that follow our contributing guidelines.

**Getting started:**

* Review the [Contributing Guide](/community/contributing)
* Join community channels (Discord, GitHub Discussions)
* Look for issues tagged `good-first-issue` or `help-wanted`
* Attend working group meetings

***

## Member

Members are established contributors with a record of ongoing commitment to MCP.

**Requirements:**

* Multiple contributions to MCP (code, documentation, and/or community)
* At least one merged PR or accepted contribution
* Ongoing engagement with the community, not just one-off contributions
* Two-factor authentication enabled on GitHub
* No objections from existing Members within 7 days

**Sponsorship:**

* Sponsored by two existing Members or Maintainers from different organizations, **or**
* Sponsored by one Core Maintainer or Lead Maintainer

**Minimum timeline:** 2-3 months of active participation

**Responsibilities:**

* Continue contributing in good faith
* Respond to assigned issues and PRs
* Follow community guidelines and the code of conduct
* Help onboard new contributors when possible

**Privileges:**

* GitHub organization membership with triage rights
* Can be assigned to issues and PRs
* Can use shortcut approval or review commands on PRs, such as `/lgtm`
* Listed in the community membership roster
* Can create PRs in restricted repositories
* Eligible for Working Group Lead or Interest Group Facilitator roles

**Inactivity:** Members with no contributions for 3 months may be moved to emeritus status. Re-engagement follows a simplified re-familiarization process.

***

## Maintainer

Maintainers are trusted stewards who take operational responsibility for specific areas.

**Requirements:**

* Member for at least 6 months with sustained, high-quality contributions
* Demonstrated leadership in working groups or significant initiatives
* Ability to represent MCP's interests above those of any single employer or organization
* Deep understanding of the MCP vision, roadmap, and design principles
* Understanding of how the area impacts real-world AI integration and model interaction patterns
* Completed security and governance onboarding

**Sponsorship and Approval:**

* Sponsored by an existing Maintainer or Core Maintainer
* Approved by Core Maintainers

**Responsibilities:**

* Own the operational health of the area (test stability, documentation currency)
* Run release processes and milestone planning for the scope
* Provide timely review of escalated decisions
* Participate actively in governance discussions
* Mentor Members and develop future Maintainers
* Represent MCP in external contexts when appropriate
* Engage with the area ecosystem and stakeholders; understand real-world usage and represent community needs
* Ensure proposals reaching Core Maintainers are refined, well-considered, and account for ecosystem-wide impact
* Participate actively in discussions on communication channels (GitHub issues, Discord)

**Privileges:**

* Merge privileges for owned areas
* Can sponsor new Maintainers
* Participate in roadmap and prioritization discussions
* Listed in `MAINTAINERS.md`

**Inactivity:** Maintainers with no contributions for 6 months may be moved to emeritus status following review by Core Maintainers. Merge rights are revoked upon emeritus transition. Re-engagement requires completing security and governance onboarding again.

All contribution pathways can lead to Maintainer. The specific scope will align with the contribution type.

***

## Core Maintainer

Core Maintainers hold final decision-making authority for MCP's technical direction. This is the highest level of trust in the community.

<Note>
  The Core Maintainer role is intentionally limited. This ensures a coherent
  technical vision while the project scales. Bandwidth concerns are addressed
  through delegation to Maintainers, Working Group Leads, and Interest Group
  Facilitators, not by expanding Core Maintainer numbers.
</Note>

**Requirements:**

* Sustained contribution as Maintainer or similar role over at least 6 months
* Demonstrated judgment on complex, project-wide decisions
* Trust and respect across organizational boundaries
* Deep commitment to MCP's long-term success

**Appointment:**

* Nominated by a majority of Core Maintainers and approved by Lead Maintainers, **or**
* Direct appointment by Lead Maintainers

When evaluating candidates, Core Maintainers should consider whether the current composition adequately represents the breadth of the MCP ecosystem. This includes enterprise adopters deploying MCP in production.

**Responsibilities:**

* Final technical decision authority for contested or cross-cutting issues
* Stewardship of project vision and design principles
* Governance and policy decisions
* External representation of MCP
* Succession planning and community health
* Ensure restraint and sustainability in protocol evolution
* Attend Core Maintainer meetings and meetups

**Privileges:**

* Final approval on breaking changes and major spec revisions
* Voting rights on [SEPs](/community/sep-guidelines)
* Approval of Maintainers
* Governance voting rights and expectation of governance participation
* Administrative rights to all MCP GitHub repositories
* Listed in `MAINTAINERS.md` as Core Maintainer

**Inactivity:** Core Maintainers with no participation in governance or technical decisions for 6 months may be moved to emeritus status following review by Lead Maintainers. Given the visibility of this role, Core Maintainers should proactively communicate reduced availability.

***

## Lead Maintainer

Lead Maintainers hold ultimate authority over MCP's direction and governance. This is a lifetime appointment reserved for project founders. There is no advancement path to this role. It is only assumed through succession (see [Succession](#succession)).

**Responsibilities:**

* All Core Maintainer responsibilities
* Appoint and remove Core Maintainers
* Final authority on contested governance decisions
* Project-wide strategic direction

**Privileges:**

* Can act alone where Core Maintainers require multiple approvals
* Veto authority over any decision
* Appoints successor

### Succession

If a Lead Maintainer leaves the role for any reason, succession begins upon their written notice. If they cannot give notice, the remaining Lead Maintainers or Core Maintainers may determine that the Lead Maintainer is unable to continue serving.

If one or more Lead Maintainers remain, they appoint a successor. If more than one remains, they decide by majority vote. The remaining Lead Maintainers continue to govern until a successor is appointed.

If no Lead Maintainers remain, the Core Maintainers appoint a successor by majority vote within 30 days. Until a new Lead Maintainer is appointed, the project operates by two-thirds vote of Core Maintainers.

***

## Community Moderator

Community Moderators help keep the MCP community healthy, safe, and welcoming. This role focuses on moderation and Code of Conduct enforcement rather than technical contribution.

**Requirements:**

* Member status minimum
* Demonstrated good judgment and composure in community interactions
* Understanding of the MCP Code of Conduct and community guidelines
* Ability to handle sensitive situations with discretion and fairness

**Sponsorship:**

* Sponsored by a Core Maintainer or Lead Maintainer

**Responsibilities:**

* Monitor community channels (Discord, GitHub Discussions, etc.) for Code of Conduct adherence
* Handle Code of Conduct incident reports, including initial triage and response
* Escalate serious or complex incidents to Core Maintainers
* Help maintain a welcoming and inclusive environment
* Coordinate with other moderators to ensure consistent enforcement
* Document moderation actions and maintain confidentiality of incident details
* Recuse from any incident involving them personally; such incidents go directly to Core Maintainers

**Privileges:**

* Moderation rights on community platforms (Discord, GitHub Discussions)
* Access to moderation tools and private moderation channels
* Authority to issue warnings, mute, or temporarily ban users for Code of Conduct violations
* Listed in the community moderator roster

**Relationship to Contributor Ladder:** Community Moderator is a parallel track, not a prerequisite for technical advancement. Moderator experience counts toward any role, especially where community judgment matters. Moderators may hold other roles at the same time (Member, Maintainer, etc.).

**Removal:** Core Maintainers may remove Community Moderators for failure to uphold moderation standards or for Code of Conduct violations. Moderators may step down voluntarily at any time.

***

## Working Group and Interest Group Leadership

Working 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.

The 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.

**Requirements:**

* Member status minimum
* Demonstrated sustained engagement with the group's scope
* Good facilitation and communication skills
* Ability to represent multiple perspectives fairly
* Group and its leadership sponsored by at least two Core Maintainers or one Lead Maintainer

**Relationship to Contributor Ladder:**

* WG Lead and IG Facilitator experience is valuable for advancement to Maintainer
* Leads and Facilitators without Maintainer status work with Maintainers for merge decisions
* Leads and Facilitators have authority over group operations but not spec approval
* WG Leads and Maintainers may sponsor SEPs
* WG Leads may triage SEPs in their scope area. This includes closing SEPs that do not fit the roadmap. Closures require documented rationale, and authors may appeal to Core Maintainers.

***

## Advancement Process

### Self-Nomination vs. Recognition

Contributors may either:

1. **Self-nominate** when they believe they meet the requirements
2. **Be nominated** by a sponsor who has observed their contributions

Both paths are equally valid. Self-nomination is encouraged. It shows initiative and self-awareness of one's contribution scope.

### Process Steps

1. **Nomination.** The nominee or sponsor opens an issue using the nomination template. It must include links to contributions that demonstrate the requirements, plus sponsor confirmations.
2. **Community Review.** A 7-day period follows for community input.
3. **Decision.** The approving authority reviews and decides.
4. **Onboarding.** The new role-holder receives appropriate access and onboarding.

| Advancement To      | Approved By                                                                     |
| ------------------- | ------------------------------------------------------------------------------- |
| Member              | 2 existing Members+ from different organizations, **or** 1 Core/Lead Maintainer |
| Maintainer          | 1 Maintainer or Core Maintainer sponsor + Core Maintainer approval              |
| Core Maintainer     | Lead Maintainers                                                                |
| Community Moderator | 1 Core Maintainer or Lead Maintainer                                            |

Nominees who self-nominate must still secure the required sponsorship. Sponsors confirm support in the nomination issue.

***

## Decision-Making and Escalation

Cut at 300 lines. The page has the rest.

community/design-principles First recorded · 47 lines, first recorded

# Design Principles ## Convergence over choice ## Composability over specificity ## Interoperability over optimization ## Stability over velocity ## Capability over compensation ## Demonstration over deliberation ## Pragmatism over purity ## Standardization over innovation

The first capture of this source. The page was already there, and this is what it said.

# Design Principles

> The core design principles that guide the development of the Model Context Protocol.

These 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).

## Convergence over choice

There 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.

[Extensions](/extensions/overview) are where convergence gets tested; the specification is where it gets committed.

## Composability over specificity

MCP 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.

When 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.

## Interoperability over optimization

MCP runs across clients, servers, and models of widely varying sophistication. We favor features that degrade gracefully over those that only work when every participant is equally capable. Capability negotiation makes this concrete: participants declare what they support, and the protocol adapts rather than assumes.

## Stability over velocity

Adding to a protocol as widely adopted as MCP is easy. Removing from it is nearly impossible. Every addition is a permanent commitment and a cost for client implementers to support. We move deliberately, knowing that "no" today leaves the door open while "yes" closes it forever.

Contributors accustomed to rapid shipping may find this pace frustrating, but sustainable standards require sustainable decision-making. We optimize for decades, not quarters.

## Capability over compensation

Models improve faster than protocols evolve. We avoid adding permanent structure to work around limitations that are likely temporary — the limitation fades, but the complexity remains.

This is not license to ignore today's reality. Optional context that weaker models lean on and stronger ones ignore costs nothing. But when a proposal exists primarily because current models struggle without it, we ask whether they will outgrow the need before we can shed the weight.

## Demonstration over deliberation

MCP values working implementations over theoretical debates. When evaluating proposals, we prioritize evidence from real usage over hypothetical arguments. We encourage contributors to prototype, experiment, and demonstrate rather than design by committee. Implementation reveals what discussion cannot.

## Pragmatism over purity

MCP makes practical tradeoffs in service of adoption and usability. We don't pursue theoretical elegance at the cost of real-world utility. When a "correct" design creates friction for implementers, we consider whether a "good enough" design better serves the ecosystem. This means accepting some inconsistency, some historical accidents, and some decisions we might make differently with hindsight.

## Standardization over innovation

MCP 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.

We encourage the use of [MCP extensions](/extensions/overview) as a way to experiment with new patterns that may eventually lead to standardization.

community/feature-lifecycle First recorded · 153 lines, first recorded

# Feature Lifecycle and Deprecation Policy ## Scope ## Feature States ### SDKs ## Deprecating a Feature ## The Deprecated Registry ## Tier 1 SDK Obligations ## Removing a Feature ## Expedited Removal ## Roles

The first capture of this source. The page was already there, and this is what it said.

# Feature Lifecycle and Deprecation Policy

> How individual MCP specification features move through Active, Deprecated, and Removed states, and the timeline implementers can plan against.

This policy defines a lifecycle for individual features within the Model
Context Protocol specification. It defines three feature states (Active,
Deprecated, Removed), the criteria and procedure for moving between them, a
minimum window between deprecation and removal, and the documentation required
at each transition.

This policy was adopted via
[SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596).

## Scope

This policy governs **features** of the MCP core specification: protocol
messages, capabilities, transports, schema types, and normative behavioral
requirements. The revision lifecycle of the specification document itself
(Draft, Current, Final) is defined in the [versioning guide](/docs/learn/versioning).

## Feature States

A specification feature is in exactly one of three states:

| State          | Meaning                                                                                                                                                       | Implementer expectation                                                                                                     |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Active**     | The feature is part of the Current specification revision.                                                                                                    | Implement per the feature's normative requirements.                                                                         |
| **Deprecated** | The feature remains in the specification but is scheduled for removal. A migration path is documented (see below).                                            | New implementations should not adopt the feature. Existing implementations should migrate before the earliest removal date. |
| **Removed**    | The feature has been deleted from `draft` and will be absent from the next Current revision. It remains documented in the Final revision it last appeared in. | Implementations targeting that next Current revision must not depend on the feature.                                        |

A Deprecated feature MAY be restored to Active by a SEP that supersedes the
deprecation SEP and documents the changed circumstances. Restoration follows
the same approval path as deprecation. If the feature is later deprecated
again, the minimum deprecation window in
[Deprecating a feature](#deprecating-a-feature) is measured afresh from the
revision in which the new deprecation takes effect.

### SDKs

Removal from the specification does not oblige an SDK to drop the feature from
releases. That timeline is governed by the SDK's own revision-support policy.

## Deprecating a Feature

A feature may be proposed for deprecation when:

* it has been superseded by another feature that covers the same use cases,
* it presents a security, privacy, or interoperability risk that cannot be
  mitigated in place,
* ecosystem telemetry or SDK maintainer consensus indicates negligible adoption
  relative to its maintenance cost,
* or any other reasons the Core Maintainers deem appropriate.

Deprecation is a specification change and therefore requires a SEP per the
[SEP guidelines](/community/sep-guidelines). The deprecation SEP must:

1. Identify the feature by name and link to its definition in `schema.ts`
   (where applicable) and the specification prose.
2. State the rationale against the criteria above.
3. Document the migration path, or state explicitly that none is required. If
   the migration path names a replacement feature, that feature must be Active
   in the revision in which the deprecation takes effect; the replacement and
   the deprecation may land in the same revision.
4. Specify the **minimum deprecation window**: the number of months, at least
   twelve, that the feature must remain Deprecated before it is eligible for
   removal. The window is measured from the release of the specification
   revision in which the feature is first marked Deprecated, not from the date
   the SEP reaches Final. The feature becomes eligible for removal in the first
   specification revision released as Current on or after the window elapses;
   that point is the feature's **earliest removal**.

When the deprecation SEP is accepted and reaches Final, the deprecation is scheduled.

* The feature's entry in `schema.ts` gains a `@deprecated` JSDoc tag
  referencing the deprecation SEP and the revision in which the deprecation
  takes effect.
* The specification prose for the feature gains a deprecation notice with the
  same information.
* The `changelog.mdx` for that revision gains an entry under a "Deprecated"
  heading. "Deprecated" and "Removed" are standing changelog headings alongside
  the existing Major/Minor/Other groupings.
* The feature is added to the
  [deprecated registry](#the-deprecated-registry) with its deprecation SEP, the
  revision in which it became Deprecated, its migration path, and its earliest
  removal.

The feature becomes Deprecated when the revision carrying these changes is released
and becomes the new Current revision (see [versioning guide](/docs/learn/versioning)).
The minimum deprecation window is counted from that release.

## The Deprecated Registry

[`docs/specification/draft/deprecated.mdx`](/specification/draft/deprecated) is
a single page listing every feature in a Deprecated or Removed state. It is
the canonical answer to "what is on its way out, and by when," so that an
implementer does not have to reconstruct that picture from deprecation entries
spread across revision changelogs.

## Tier 1 SDK Obligations

Once the revision in which a feature becomes Deprecated is
released as Current, Tier 1 SDKs:

* Must mark the corresponding API surface deprecated using the language's
  native mechanism (for example `@Deprecated` in Java, `[Obsolete]` in .NET,
  `@deprecated` JSDoc in TypeScript, the `Deprecated:` doc convention in Go) in
  their next release, referencing the deprecation SEP and the earliest removal
  date where the mechanism permits.
* Should emit a runtime warning when a deprecated feature is exercised, using
  the language's idiomatic mechanism (for example Python's
  `DeprecationWarning`, Node.js's `process.emitWarning`, or a configurable
  logger).

A Tier 1 SDK that consistently fails to surface a Deprecated feature is subject to the
[Tier Relegation Process](/community/sdk-tiers#tier-relegation).

## Removing a Feature

1. Once a feature is set for removal, the removal is executed at the discretion
   of the Core Maintainers after the minimum deprecation window has elapsed.
2. The removal needs to be documented in the `changelog.mdx` and [registry](#the-deprecated-registry).
3. A SEP is required for any change to the original deprecation or removal SEP, for
   example extending or shortening the timeline
   ([Expedited removal](#expedited-removal)) or restoring the feature to Active
   ([Feature states](#feature-states)).

Features may remain Deprecated, without removal, for much longer than the minimum deprecation window.

## Expedited Removal

The twelve-month floor may be shortened when the feature presents an active
security risk, meaning a vulnerability with a published security advisory or
documented in-the-wild exploitation for which no in-place mitigation exists.
Shortening the window requires Core Maintainer approval under the
[governance decision process](/community/governance#decision-process), recorded
in the deprecation SEP or, where the risk surfaces after that SEP is already
Final, in a short expedited-removal SEP that references it. The shortened
window must still provide at least ninety days between the feature becoming
Deprecated and its earliest removal.

## Roles

| Action                                         | Who                                                                                             |
| ---------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Propose deprecation, extension, or restoration | Any contributor, per the SEP process                                                            |
| Sponsor                                        | A Maintainer or Core Maintainer, per the SEP process                                            |
| Approve a deprecation SEP                      | Core Maintainers, per the [governance decision process](/community/governance#decision-process) |
| Decide a removal during release preparation    | Core Maintainers, per the [governance decision process](/community/governance#decision-process) |
| Approve an extension or restoration SEP        | Core Maintainers, per the [governance decision process](/community/governance#decision-process) |
| Approve expedited removal                      | Core Maintainers, per the [governance decision process](/community/governance#decision-process) |

Lead Maintainers retain veto authority over each of the approvals
above, per the [governance roles](/community/governance#roles) definition.

community/governance First recorded · 127 lines, first recorded

# Governance and Stewardship ## General Project Policies ## Technical Governance ### Communication Channels ### Roles ### Decision Process ## Processes ### Working Groups and Interest Groups ### Specification Enhancement Proposals (SEPs) ### Maintenance Responsibilities ## Communication ### Core Maintainer Meetings ### Public Chat ## Nominating, Confirming, and Removing Maintainers ## Current Lead Maintainers ## Current Core Maintainers ## Emeritus ## Current Maintainers and Working Groups

The first capture of this source. The page was already there, and this is what it said.

# Governance and Stewardship

> 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.

## General Project Policies

Model Context Protocol has been established as **Model Context Protocol a Series of LF Projects, LLC**. Policies applicable to Model Context Protocol and participants in Model Context Protocol, including guidelines on the usage of trademarks, are located at [https://www.lfprojects.org/policies/](https://www.lfprojects.org/policies/). Governance changes approved as per the provisions of this governance document must also be approved by LF Projects, LLC.

Model Context Protocol participants acknowledge that the copyright in all new contributions will be retained by the copyright holder as independent works of authorship and that no contributor or copyright holder will be required to assign copyrights to the project.

Except as described below, all code and specification contributions to the project must be made using the Apache License, Version 2.0 (available here: [https://www.apache.org/licenses/LICENSE-2.0](https://www.apache.org/licenses/LICENSE-2.0)) (the "Project License").

All outbound code and specifications will be made available under the Project License. The Core Maintainers may approve the use of an alternative open license or licenses for inbound or outbound contributions on an exception basis.

All documentation (excluding specifications) will be made available under Creative Commons Attribution 4.0 International license, available at: [https://creativecommons.org/licenses/by/4.0](https://creativecommons.org/licenses/by/4.0).

## Technical Governance

The MCP project adopts a hierarchical structure, similar to Python, PyTorch, and other open source projects:

| Role                        | Scope                            |
| --------------------------- | -------------------------------- |
| **Lead Maintainers (BDFL)** | Final decision authority         |
| **Core Maintainers**        | Overall project direction        |
| **Maintainers**             | Working Groups, SDKs, components |
| **Contributors**            | Issues, PRs, discussions         |

* **Contributors** file issues, make pull requests, and contribute to the project.
* **Maintainers** drive components within the MCP project, such as SDKs, documentation, and Working Groups.
* **Core Maintainers** drive the overall project direction and oversee contributors and maintainers.
* **Lead Maintainers** are the final decision makers (also known as BDFL - Benevolent Dictator for Life).

Together, Maintainers, Core Maintainers, and Lead 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.

### Communication Channels

Technical governance is facilitated through a shared [Discord server](https://discord.gg/6CSzBmMkjX) for all 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 Discord server.

### Roles

The [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.

**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.

**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.

**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.

The [Contributor Ladder](/community/contributor-ladder) also defines the **Member** and **Community Moderator** roles, which sit outside the Steering Group.

### 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 Maintainers 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.

### Working Groups and Interest Groups

MCP collaboration and contributions are organized around two structures: [Working Groups and Interest Groups](/community/working-interest-groups).

* **Interest Groups** identify and articulate problems that MCP should address through open discussions
* **Working Groups** develop concrete solutions by producing deliverables like SEPs or implementations

For details on how to create, participate in, and facilitate these groups, see the [Working and Interest Groups](/community/working-interest-groups) documentation.

### Specification Enhancement Proposals (SEPs)

Proposed 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.

For the complete SEP process, format requirements, and status workflow, see the [SEP Guidelines](/community/sep-guidelines).

### 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.

## 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](https://discord.gg/6CSzBmMkjX) with open chats for interest groups. The MCP project may have private channels for certain communications.

## Nominating, Confirming, and Removing Maintainers

Membership 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.

The 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).

## Current Lead Maintainers

* David Soria Parra
* Den Delimarsky

## Current Core Maintainers

* Peter Alexander
* Caitie McCaffrey
* Kurtis Van Gent
* Clare Liguori
* Paul Carleton
* Nick Cooper

## Emeritus

* Justin Spahr-Summers (Co-Inventor, Lead Maintainer Emeritus)
* Basil Hosmer (Core Maintainer Emeritus)
* Che Liu (Core Maintainer Emeritus)
* Nick Aldridge (Core Maintainer Emeritus)

## Current Maintainers and Working Groups

Refer to [the maintainer list](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md).

community/interest-groups/auth First recorded · 86 lines, first recorded

# Authorization Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Membership ## Operations ### Working Group Incubation ## Deliverables & Success Metrics ## Changelog

The first capture of this source. The page was already there, and this is what it said.

# Authorization Charter

> Charter for the MCP Authorization Interest Group.

## Group Type

**Interest Group**

## Mission Statement

The Authorization Interest Group provides a venue for MCP implementers, identity-provider vendors, and security practitioners to surface real-world authorization challenges encountered when deploying MCP clients and servers. The group gathers use cases, documents gaps in the current OAuth 2.1–based authorization specification, and incubates validated problems until they are scoped well enough to propose a focused Working Group via the standard [group-creation process](/community/working-interest-groups#creating-a-working-group) to drive the corresponding [SEPs](/community/sep-guidelines).

## Scope

### In Scope

* **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
* **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
* **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
* **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
* **Credentials for non-HTTP transports**: patterns for stdio, WebSocket, and future transports where the HTTP authorization spec does not directly apply
* **Client identity and registration**: operator experience with Dynamic Client Registration, Client ID Metadata Documents, software statements, and pre-registered clients
* **Threat modelling input**: cataloguing authorization-related attack surfaces (token confusion, confused-deputy, audience mismatch, redirect handling) to inform Security Best Practices documentation
* **Proposing Working Groups**: once a problem is validated and scoped, the IG submits a Working Group creation proposal via the standard `#wg-ig-group-creation` process; approval remains with community moderators and core maintainers
* **Problem statements and requirements**: use-case catalogues and recommendations published to GitHub Discussions for consumption by SEP authors and Working Groups

### Out of Scope

* **Authentication of end users to MCP clients**: how a host application authenticates its own users is a host concern, not a protocol concern
* **Transport security (TLS, mTLS, certificate handling)**: belongs to the Transports WG
* **Server identity, provenance, and trust signalling**: belongs to the Server Card / Registry efforts
* **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 can or cannot implement *are* in scope as deployment experience
* **Competitively sensitive or non-public business information**, per the [MCP Antitrust Policy](/community/antitrust)

### Related Groups

* **[Enterprise-Managed Authorization IG](/community/interest-groups/enterprise-managed-authorization)**: coordinates IdP, client, and server interoperability testing for the EMA extension produced by the Profiles WG; spec-change requests surfaced there are routed back to this group
* **Transports WG**: authorization is currently specified at the HTTP transport level; changes to transports affect where credentials are carried
* **Agents WG**: delegated/on-behalf-of access and consent for multi-agent chains overlap heavily with agentic use cases
* **[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
* **SDK Maintainers**: SDKs ship the auth client implementations; IG findings should inform cross-SDK auth ergonomics

## Leadership

| Role        | Name          | Organization | GitHub                                     | Term    |
| ----------- | ------------- | ------------ | ------------------------------------------ | ------- |
| Facilitator | Aaron Parecki | Okta         | [@aaronpk](https://github.com/aaronpk)     | Initial |
| Facilitator | Darin McAdams | Amazon       | [@D-McAdams](https://github.com/D-McAdams) | Initial |
| Facilitator | Paul Carleton | Anthropic    | [@pcarleton](https://github.com/pcarleton) | Initial |

## Membership

Open to anyone; no formal membership or approval step is required to join the channel, attend calls, or contribute.

Join the `#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). If your topic clearly matches one of the Working Groups in the table below, you can post directly in that WG's channel. Calls are open and attendance is optional — async participation via Discord and GitHub is equally valued.

## Operations

| Meeting         | Frequency     | Duration | Purpose                                                                      |
| --------------- | ------------- | -------- | ---------------------------------------------------------------------------- |
| Discussion Call | Every 2 weeks | 45 min   | Use-case sharing, problem triage, WG proposal decisions, implementer reports |

Discord: [#auth-ig](https://discord.com/channels/1358869848138059966/1360835991749001368)

### Working Group Incubation

A topic graduates to a Working Group proposal when it has a written problem statement in GitHub Discussions and rough consensus on a bi-weekly call (recorded in published notes). A facilitator then files the standard WG creation template in `#wg-ig-group-creation`, citing that discussion. The IG's role ends at the proposal; approval remains with community moderators and core maintainers.

## Deliverables & Success Metrics

The IG incubates problems until they are well-scoped, then proposes focused Working Groups to drive specific SEPs. Each spawned WG maintains its own charter; this list is a directory, not a substitute. The IG stewards [modelcontextprotocol/ext-auth](https://github.com/modelcontextprotocol/ext-auth), where individual WGs land authorization extension specifications via PR.

| Working Group              | Discord                        | Focus                                                                                                                                                                               | Status    | Charter |
| -------------------------- | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | ------- |
| Client Registration        | `#auth-wg-client-registration` | Dynamic Client Registration, Client ID Metadata Documents, software statements, and pre-registered client workflows                                                                 | Completed | —       |
| Mix-up Protection          | `#auth-wg-mixup-protection`    | Mitigating OAuth authorization-server mix-up and token-audience confusion attacks                                                                                                   | Completed | —       |
| Profiles                   | `#auth-wg-profiles`            | Extension specifications for additional grant types and token-binding mechanisms (Client Credentials, Enterprise-Managed Authorization, DPoP, Workload Identity Federation)         | Completed | —       |
| Tool Scopes                | `#auth-wg-tool-scopes`         | Per-tool OAuth scope advertisement, step-up authorization / scope challenge, and client-side scope accumulation — mechanics within the OAuth scope-string model                     | Active    | Pending |
| Fine-Grained Authorization | `#auth-wg-fine-grained-authz`  | Authorization granularity beyond scope strings — Rich Authorization Requests ([RFC 9396](https://www.rfc-editor.org/rfc/rfc9396)), remediation hints, and multi-credential handling | Active    | Pending |
| Improve DevX               | `#auth-wg-improve-devx`        | Best-practices guidance and tutorials for building secure MCP clients and servers, beyond the normative spec                                                                        | Completed | —       |

## Changelog

| Date       | Change          |
| ---------- | --------------- |
| 2026-06-02 | Initial charter |

community/interest-groups/enterprise-managed-authorization First recorded · 65 lines, first recorded

# Enterprise-Managed Authorization Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Membership ## Operations ## Changelog

The first capture of this source. The page was already there, and this is what it said.

# Enterprise-Managed Authorization Charter

> Charter for the MCP Enterprise-Managed Authorization Interest Group.

## Group Type

**Interest Group**

## Mission Statement

The 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.

## Scope

### In Scope

* **Interoperability reports**: documented results of pairing specific IdPs, MCP clients, and MCP authorization servers through the full ID-JAG exchange, including what worked, what required workarounds, and what failed
* **Conformance scenario input**: identifying the assertions an EMA conformance suite should make (ID-JAG validation, audience and issuer checks, claim mapping, account linking, error handling) and contributing scenarios to the [conformance](https://github.com/modelcontextprotocol/conformance) repository
* **Deployment patterns**: comparing notes on tenant isolation, admin-consent flows, JIT provisioning, claim-to-permission mapping, and token-lifetime choices observed in production rollouts
* **IdP capability gaps**: cataloguing where existing IdP products cannot yet issue or validate ID-JAGs as specified, so implementers know what to expect and IdP vendors have a shared backlog
* **Spec clarification requests**: collecting ambiguities and underspecified behaviour discovered during implementation and routing them to the [ext-auth](https://github.com/modelcontextprotocol/ext-auth) repository as issues or PRs

### Out of Scope

* **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)
* **General enterprise deployment topics**: networking, packaging, and host-application rollout concerns that are not specific to the ID-JAG flow
* **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
* **Competitively sensitive or non-public business information**, per the [MCP Antitrust Policy](/community/antitrust)

### Related Groups

* **[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
* **[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
* **SDK Maintainers**: SDKs ship the EMA client implementation; interop findings inform cross-SDK behaviour and defaults

## Leadership

| Role        | Name          | Organization | GitHub                                     | Term    |
| ----------- | ------------- | ------------ | ------------------------------------------ | ------- |
| Facilitator | Paul Carleton | Anthropic    | [@pcarleton](https://github.com/pcarleton) | Initial |
| Facilitator | Aaron Parecki | Okta         | [@aaronpk](https://github.com/aaronpk)     | Initial |

Sponsored by Den Delimarsky ([@localden](https://github.com/localden), Lead Maintainer).

## Membership

Open 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.

Join 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.

## Operations

| Meeting      | Frequency     | Duration | Purpose                                                               |
| ------------ | ------------- | -------- | --------------------------------------------------------------------- |
| Interop Call | Every 2 weeks | 45 min   | Deployment reports, compatibility-matrix review, spec-feedback triage |

An agenda is shared in `#enterprise-managed-auth-ig` ahead of each call. Meeting notes are posted to the Authorization category in [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions).

Discord: [#enterprise-managed-auth-ig](https://discord.com/channels/1358869848138059966/1516754292294287360) · [invite](https://discord.gg/xw55W9Sw5s)

## Changelog

| Date       | Change          |
| ---------- | --------------- |
| 2026-06-16 | Initial charter |

community/interest-groups/financial-services First recorded · 118 lines, first recorded

# Financial Services Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Membership ## Operations ## Discussion Topics ## Changelog

The first capture of this source. The page was already there, and this is what it said.

# Financial Services Charter

> Charter for the MCP Financial Services Interest Group.

## Group Type

**Interest Group**

## Mission Statement

The Financial Services Interest Group brings together stakeholders from regulated financial
institutions to identify where MCP needs to adapt for compliance, auditability, and risk-controlled
deployment. It gathers use cases and requirements from the financial sector, develops and validates
domain-specific extensions, and scopes problems with broad applicability into [SEPs](/community/sep-guidelines)
or Working Groups so that innovations proven in regulated environments can benefit the wider MCP
ecosystem.

## Scope

### In Scope

* **Compliance and auditability**: requirements for tamper-evident, portable records of what a tool
  call did, under what authority, and against which policy, so that MCP interactions can satisfy
  regulatory audit and incident-review obligations
* **Data lineage and provenance**: source attribution, citation, and consent metadata for data
  surfaced through MCP, so that downstream consumers can establish where information came from and
  on what basis it may be used
* **Guardrails and attestation**: verification frameworks and cryptographic attestations that let a
  regulated institution gain assurance about server identity, tool behavior, and the integrity of
  responses before acting on them
* **Policy enforcement**: declarative policies for tool usage and data handling, and the points at
  which they are enforced, so that institutions can encode regulatory and internal-control
  constraints as machine-checkable rules
* **Finance-specific extensions**: developing, maintaining, and gathering implementation experience
  on MCP extensions that address the above in the FSIG repository, including reference
  implementations and conformance testing
* **Interoperability across institutions**: common patterns and standards that allow regulated
  institutions to interoperate without each reinventing compliance plumbing
* **SEP promotion**: identifying extensions with applicability beyond financial services and
  shepherding them toward the core specification with core-maintainer sponsorship
* **Regulatory liaison**: translating constraints from regulators and industry bodies into concrete
  technical requirements and input for other groups

### Out of Scope

* **Competitively sensitive or non-public business information**: pricing, costs, margins, customer
  lists, market segmentation, and competitive strategy, per the [MCP Antitrust Policy](/community/antitrust)
* **General security threat modeling**: MCP-wide attack-surface analysis belongs to the
  [Security IG](/community/interest-groups/security). This group provides financial-sector requirements as
  input and consumes its threat models
* **Authorization protocol mechanics**: OAuth flows, scopes, client registration, and token handling
  belong to the [Authorization IG](/community/interest-groups/auth)
* **Product-specific compliance guides**: step-by-step configuration for an individual host
  application, cloud platform, or institution is documentation for that product rather than protocol
  work
* **Non-technical business discussions**: legal interpretation, procurement, and commercial terms

### Related Groups

* **[Security IG](/community/interest-groups/security)**: attestation, auditability, and guardrails are
  shared concerns; the FSIG supplies regulated-deployment requirements and consumes the IG's threat
  models
* **[Authorization IG](/community/interest-groups/auth)**: identity and access control for sensitive
  financial data sit at the boundary between the two groups
* **[Tool Annotations IG](/community/interest-groups/tool-annotations)**: trust and sensitivity annotations
  are directly relevant to financial tool exposure; the FSIG provides requirements as input
* **[Interceptors WG](/community/working-groups/interceptors)**: interceptors are a primary enforcement point
  for the policy and guardrail requirements surfaced here
* **[Registry WG](/community/working-groups/registry)**: server provenance and publishing metadata intersect
  with financial supply-chain and admission concerns

## Leadership

| Role        | Name                     | Organization | GitHub                                 | Term    |
| ----------- | ------------------------ | ------------ | -------------------------------------- | ------- |
| Facilitator | Sambhav Kothari          | Bloomberg    | [@sambhav](https://github.com/sambhav) | Initial |
| Facilitator | Peder Holdgaard Pedersen | Saxo Bank    | [@PederHP](https://github.com/PederHP) | Initial |

## Membership

| Name       | Organization | GitHub                               | Discord | Level       |
| ---------- | ------------ | ------------------------------------ | ------- | ----------- |
| Xin Fu     | Bloomberg    | [@imfing](https://github.com/imfing) | *TBD*   | Participant |
| Kengo Arao | Bloomberg    | [@KengoA](https://github.com/KengoA) | *TBD*   | Participant |

Open to anyone. Join the `#financial-services-ig` channel on the
[MCP Contributors Discord](/community/communication#discord). Calls are open and no approval is
required to attend or contribute. The group especially welcomes contributors from regulated
institutions who can bring real-world deployment constraints and help drive proposals forward.

## Operations

| Meeting         | Frequency     | Duration | Purpose                                                   |
| --------------- | ------------- | -------- | --------------------------------------------------------- |
| Working Session | Every 2 weeks | 60 min   | Use-case review, extension and proposal work, SEP scoping |

Meetings are held 16:00–17:00 London (BST/GMT). An agenda is shared in `#financial-services-ig`
ahead of each call, and notes with decisions and action items are published afterwards.

Discord: [#financial-services-ig](https://discord.gg/NzkBHsrGf)

## Discussion Topics

The following items form the IG's current agenda. This list is not exhaustive and will evolve as the
group identifies new areas of interest.

| Item | Name                                                                          | Status | Champion |
| ---- | ----------------------------------------------------------------------------- | ------ | -------- |
| —    | Regulatory audit & attestation: portable, verifiable event/claim models       | Open   | —        |
| —    | Data lineage & citation: provenance, consent metadata, source attribution     | Open   | —        |
| —    | Guardrails & security: verification frameworks and cryptographic attestations | Open   | —        |
| —    | Policy enforcement: declarative policies for tool usage and data handling     | Open   | —        |

## Changelog

| Date       | Change          |
| ---------- | --------------- |
| 2026-06-25 | Initial charter |

community/interest-groups/primitive-grouping First recorded · 129 lines, first recorded

# Primitive Grouping Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Problem Statement ## Goals ## Organization Strategies ## IG Principles ## Leadership ## Membership ## Operations ## Discussion Topics ## Lifecycle ### Graduation Criteria (IG → WG) ### Retirement Criteria ## Success Criteria ## Resources ## Changelog

The first capture of this source. The page was already there, and this is what it said.

# Primitive Grouping Charter

> Charter for the MCP Primitive Grouping Interest Group.

## Group Type

**Interest Group**

## Mission Statement

The Primitive Grouping Interest 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.

## Scope

### In Scope

* **Requirements gathering**: documenting use cases and constraints
* **Pattern exploration**: testing and evaluating various approaches
* **Proof of concepts**: maintaining a shared repository of reference implementations and experimental findings

### Out of Scope

* **Approving spec changes**: this IG does not have authority to approve protocol changes; recommendations flow through the SEP process
* **Implementation mandates**: the group can document patterns but cannot require specific client or server behavior

### Related Groups

* **[Tool Annotations IG](/community/interest-groups/tool-annotations)** - annotation-based filtering and selection of primitives intersects with how primitives are organized and surfaced
* **[Skills Over MCP WG](/community/working-groups/skills-over-mcp)** - the MCP-and-Skills effort is evaluating how capabilities are discovered and organized, which overlaps with grouping
* **[Registry WG](/community/working-groups/registry)** - organizing MCP servers (beyond this group's mandate) is evaluated here
* **[Security IG](/community/interest-groups/security)** - organizing and disclosing primitives by privilege level is a security concern outside this group's scope

## Problem Statement

Flat lists of MCP primitives can be long and cumbersome to work with for several reasons. Many such problems are within the scope of this group, but some are not.

**Within Scope**

* **Context overload** - when loaded into the context of an LLM, a primitive list can overwhelm the model and lead to confusion and poor selection
* **Inefficient operations** - long lists in the context consume many tokens, which increases processing cost and response latency
* **Poor developer experience** - the lack of organizational tools for primitives makes them harder to manage and maintain

**Beyond Scope**

* **Organization for security** - organizing and disclosing primitives to clients based on their privilege level is an important problem but beyond this group's mandate
* **Organizing MCP servers** - the MCP Registry and MCP-and-Skills groups are evaluating how different servers should be organized to improve the client experience

## Goals

1. **Documenting requirements and experiences** - document diverse requirements for the different clients, servers, and gateways that implement these extensions. We will **not** try to find consensus early on, but aim to document the trade-offs based on feedback from real-world experience.
2. **Reference extensions** - many possible organization mechanisms are emerging, and it may be too early to select one canonical pattern. Different servers are implementing similar features, but the lack of standardization limits clients' ability to leverage them effectively. This group will support reference extensions of varied organization strategies, e.g., grouping, tool-search, code-mode.
3. **Evangelizing standards** - invite feedback from developers and maintainers of large MCP servers and clients to migrate away from bespoke implementations toward standardized extensions.

## Organization Strategies

See [Approaches](https://github.com/modelcontextprotocol/experimental-ext-grouping/blob/main/docs/approaches.md) for detailed descriptions of each strategy, including prior art, examples, and discussion links.

## IG Principles

1. **Document discussions** - the IG aims to document the trade-offs and discussions rather than dictate one specific implementation. Prefer GitHub Discussions on the IG repository over prolonged Discord threads. Meeting notes from synchronous IG calls are also uploaded to GitHub Discussions for future reference.
2. **Experimental extensions** - the repository houses experimental extensions for different approaches. Extensions SHOULD support at least Python and TypeScript implementations and include (1) end-to-end working demonstrations and (2) detailed instructions for how others can integrate with them.
3. **Feedback from deployments** - the IG solicits deployment experiences and feedback from users of extensions to prioritize feature development and changes.

## Leadership

| Role        | Name        | Organization             | GitHub                                               | Term    |
| ----------- | ----------- | ------------------------ | ---------------------------------------------------- | ------- |
| Facilitator | Tapan Chugh | University of Washington | [@chughtapan](https://github.com/chughtapan)         | Initial |
| Facilitator | Sam Morrow  | GitHub                   | [@SamMorrowDrums](https://github.com/SamMorrowDrums) | Initial |

## Membership

| Name        | Organization             | GitHub                                               | Discord | Level       |
| ----------- | ------------------------ | ---------------------------------------------------- | ------- | ----------- |
| Tapan Chugh | University of Washington | [@chughtapan](https://github.com/chughtapan)         |         | Facilitator |
| Sam Morrow  | GitHub                   | [@SamMorrowDrums](https://github.com/SamMorrowDrums) |         | Facilitator |
| Cliff Hall  | Futurescale              | [@cliffhall](https://github.com/cliffhall)           |         | Maintainer  |

## Operations

| Meeting    | Frequency | Duration | Purpose                                                        |
| ---------- | --------- | -------- | -------------------------------------------------------------- |
| Discussion | TBD       | TBD      | Requirements alignment, approach review, experimental findings |

Open to anyone. Join the [#primitive-grouping-ig](https://discord.com/channels/1358869848138059966/1425903819186770064) channel on the [MCP Contributors Discord](/community/communication#discord).

## Discussion Topics

The following items form the IG's current work agenda. This list is not exhaustive and will evolve as the group identifies new areas of interest.

| Item                               | Status      | Champion         | Notes                                                             |
| ---------------------------------- | ----------- | ---------------- | ----------------------------------------------------------------- |
| Requirements alignment             | In Progress | All facilitators | Review approaches, identify common requirements and gaps          |
| Experimental findings repo section | Proposed    | TBD              | Dedicated repo section for implementations and evaluation results |
| MCP Grouping Convention v0.1       | Proposed    | TBD              | Documented pattern (not spec) for grouping of primitives          |

## Lifecycle

**Current Status: Active Exploration**

### Graduation Criteria (IG → WG)

This IG may propose becoming a Working Group if:

* Clear consensus emerges on an approach requiring sustained spec work
* Cross-cutting coordination requires formal authority delegation
* At least two Core Maintainers sponsor WG formation

### Retirement Criteria

* Problem space resolved (conventions established, absorbed into other WGs)
* Insufficient participation to maintain momentum
* Community consensus that grouping doesn't belong in MCP protocol scope

## Success Criteria

* **Short-term**: documented consensus on requirements and evaluation of existing approaches
* **Medium-term**: clear recommendation (convention vs. protocol extension vs. both)
* **Long-term**: interoperable grouping convention across MCP servers and clients

## Resources

* [Experimental repo](https://github.com/modelcontextprotocol/experimental-ext-grouping) - incubation space for the Primitive Grouping Interest Group

## Changelog

| Date       | Change          |
| ---------- | --------------- |
| 2026-06-18 | Initial charter |

community/interest-groups/security First recorded · 127 lines, first recorded

# Security Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Membership ## Operations ## Discussion Topics ## Changelog

The first capture of this source. The page was already there, and this is what it said.

# Security Charter

> Charter for the MCP Security Interest Group.

## Group Type

**Interest Group**

## Mission Statement

The Security Interest Group catalogs MCP-specific threats, reviews security-relevant proposals, and
scopes validated problems into focused Working Groups or [SEPs](/community/sep-guidelines).

## Scope

### In Scope

* **Threat modeling**: developing and maintaining a shared, layered view of MCP attack surfaces
  spanning admission and identity, caller governance, runtime behavior, interception and enforcement,
  and auditability, to give individual proposals a common frame of reference
* **Server identity, attestation, and admission**: requirements for establishing that a server is
  what it claims to be before a client dispatches to it, including signed assertions, trust roots,
  and the boundary between protocol-level and registry-level verification
* **Supply chain and provenance**: integrity of locally executed server binaries and packages
  (typosquatting, unpinned dependencies, unsigned artifacts) and how clients can verify what they
  spawn
* **Runtime drift and post-admission change**: treatment of tool, schema, or behavior changes after
  a server has been approved, and whether such changes are versioning, re-approval, or security
  events
* **Auditability and observability**: requirements for tamper-evident records of what a tool call
  did and under what authority, for compliance and incident review
* **Transport-adjacent security**: secrets handling, process isolation, and unauthenticated surface
  area for stdio and other non-HTTP transports where the HTTP authorization specification does not
  apply
* **Security Best Practices documentation**: authoring and reviewing entries in the
  [Security Best Practices](/docs/tutorials/security/security_best_practices) guidance, including
  liaising with external bodies such as OWASP GenAI and CoSAI on MCP-specific content
* **Vulnerability disclosure routing**: providing a known point of contact for reporters who have
  filed a private security advisory against an MCP repository and need help reaching the right
  maintainer

### Out of Scope

* **Authorization protocol mechanics**: OAuth flows, scopes, client registration, and token handling
  belong to the [Authorization IG](/community/interest-groups/auth) and its spawned Working Groups
* **Transport wire security**: TLS, mTLS, and certificate handling belong to the Transports WG
* **Tool annotation design**: the annotation model itself belongs to the
  [Tool Annotations IG](/community/interest-groups/tool-annotations). This group provides security
  requirements as input
* **Registry service operation**: running and securing the hosted Registry service belongs to the
  [Registry WG](/community/working-groups/registry). This group provides threat input on provenance and
  publishing
* **Product-specific hardening guides**: step-by-step configuration for individual host applications
  or cloud platforms is documentation for those products rather than protocol work
* **Competitively sensitive or non-public business information**, per the
  [MCP Antitrust Policy](/community/antitrust)

### Related Groups

* **[Authorization IG](/community/interest-groups/auth)**: token confusion, audience mismatch, and SSRF in
  metadata discovery sit at the boundary between the two groups
* **[Tool Annotations IG](/community/interest-groups/tool-annotations)**: trust and sensitivity annotations
  ([SEP-1913](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913)) span both
  groups
* **[Interceptors WG](/community/working-groups/interceptors)**: interceptors are the primary enforcement
  point for runtime security decisions surfaced here
* **[Server Card WG](/community/working-groups/server-card) / [Registry WG](/community/working-groups/registry)**:
  server identity, provenance, and discovery metadata intersect with admission and supply-chain
  concerns
* **Transports WG**: stdio process isolation and unauthenticated method surface
* **SDK Maintainers**: coordinated handling of SDK security advisories and cross-SDK security
  defaults

## Leadership

| Role        | Name           | Organization | GitHub                                     | Term    |
| ----------- | -------------- | ------------ | ------------------------------------------ | ------- |
| Facilitator | Den Delimarsky | Anthropic    | [@localden](https://github.com/localden)   | Initial |
| Facilitator | Paul Carleton  | Anthropic    | [@pcarleton](https://github.com/pcarleton) | Initial |

## Membership

| Name                     | Organization | GitHub                                               | Discord          | Level       |
| ------------------------ | ------------ | ---------------------------------------------------- | ---------------- | ----------- |
| Sam Morrow               | GitHub       | [@SamMorrowDrums](https://github.com/SamMorrowDrums) | `sammorrowdrums` | Participant |
| Ola Hungerford           | Nordstrom    | [@olaservo](https://github.com/olaservo)             | `olaservo`       | Participant |
| Peder Holdgaard Pedersen | Saxo Bank    | [@PederHP](https://github.com/PederHP)               | `pederhp`        | Participant |
| Stefano Ortolani         | Broadcom     | [@ostefano](https://github.com/ostefano)             | `ostefano.`      | Participant |

Open to anyone. Join the `#security-ig` channel on the
[MCP Contributors Discord](/community/communication#discord). Calls are open and active
participation is highly encouraged. The group is looking for contributors who will engage with
proposals and help drive work forward rather than observe.

## Operations

| Meeting      | Frequency     | Duration | Purpose                                                                 |
| ------------ | ------------- | -------- | ----------------------------------------------------------------------- |
| Office Hours | Every 2 weeks | 45 min   | Threat review, proposal triage, deployment reports, WG-proposal scoping |

An agenda is shared in `#security-ig` ahead of each call.

Discord: [#security-ig](https://discord.com/channels/1358869848138059966/1379811011669921883)

Meeting notes are posted to the
[Meeting Notes - Security IG](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/categories/meeting-notes-security-ig)
category in GitHub Discussions.

## Discussion Topics

The following items form the IG's current discussion agenda. This list is not exhaustive and will
evolve as the group identifies new areas of interest.

| Item                                                                               | Name                                                                                                                        | Status      | Champion                                                 |
| ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ----------- | -------------------------------------------------------- |
| [SEP-2809](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2809) | Attested Tool-Server Admission (ATSA)                                                                                       | Draft       | [@metereconsulting](https://github.com/metereconsulting) |
| —                                                                                  | SDK vulnerability disclosure                                                                                                | In progress | Facilitators                                             |
| —                                                                                  | Runtime drift: `list_changed` semantics after approval                                                                      | Open        | —                                                        |
| —                                                                                  | Supply-chain integrity: protocol, registry, or companion standard                                                           | Open        | —                                                        |
| —                                                                                  | Tool identity across servers                                                                                                | Open        | —                                                        |
| —                                                                                  | Capability declarations: hints or contracts (joint with [Tool Annotations IG](/community/interest-groups/tool-annotations)) | Open        | —                                                        |

## Changelog

| Date       | Change          |
| ---------- | --------------- |
| 2026-06-13 | Initial charter |

community/interest-groups/tool-annotations First recorded · 94 lines, first recorded

# Tool Annotations Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Membership ## Operations ## Discussion Topics ### Active SEPs Under Discussion ### Open Questions ## Resources ## Changelog

The first capture of this source. The page was already there, and this is what it said.

# Tool Annotations Charter

> Charter for the MCP Tool Annotations Interest Group.

## Group Type

**Interest Group**

## Mission Statement

The Tool Annotations Interest Group explores the role of tool annotations in enabling safe, usable agentic systems across the MCP ecosystem. Today, six independent SEPs propose annotation changes, each solving real problems but lacking the coherent, cross-cutting perspective that a dedicated group can bring. The IG gathers use cases from server and client authors, evaluates existing and proposed annotations, and considers the long-term future of the annotation model, including whether runtime annotations, tool response annotations, and other extensions belong in the protocol.

## Scope

### In Scope

* **Evaluation of existing annotations**: Assess whether the current set of tool annotations (`readOnlyHint`, `destructiveHint`, `idempotentHint`, `openWorldHint`) adequately serves server and client authors
* **Discussion of proposed annotations**: Review and provide feedback on SEPs proposing new or modified tool annotations (trust/sensitivity, agency, model preferences, and others)
* **Future of the annotation model**: Explore whether runtime annotations, tool response annotations, or structural changes to the annotation system are worth adding to the protocol
* **Use-case gathering**: Collect real-world use cases from server authors, client authors, and host applications to ground annotation decisions in practical needs
* **Problem statements and recommendations**: Produce recommendations for Working Groups or SEP authors on annotation design, coherence, and prioritization

### Out of Scope

* **Binding specification changes**: The IG produces recommendations, not binding decisions; specification changes are made through the SEP process
* **Implementation work**: Building SDK features or reference implementations (may be explored in the [experimental repo](https://github.com/modelcontextprotocol/experimental-ext-tool-annotations) but is not the IG's primary purpose)
* **Non-annotation tool changes**: Changes to tool discovery, invocation, or lifecycle that do not relate to annotations
* **Resource annotations**: While related, resource-level annotation work is tracked separately unless it directly intersects with tool annotation design

### Related Groups

* **Security IG** - Trust and sensitivity annotations ([SEP-1913](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913)) span both groups' interests
* **[Skills Over MCP WG](/community/working-groups/skills-over-mcp)** - Skill-level metadata may interact with tool annotations for discovery and filtering

## Leadership

| Role        | Name           | Organization | GitHub                                               | Term    |
| ----------- | -------------- | ------------ | ---------------------------------------------------- | ------- |
| Facilitator | Sam Morrow     | GitHub       | [@SamMorrowDrums](https://github.com/SamMorrowDrums) | Initial |
| Facilitator | Robert Reichel | OpenAI       | [@rreichel3](https://github.com/rreichel3)           | Initial |

## Membership

| Name                    | Organization | GitHub                                               | Discord  | Level       |
| ----------------------- | ------------ | ---------------------------------------------------- | -------- | ----------- |
| Sam Morrow              | GitHub       | [@SamMorrowDrums](https://github.com/SamMorrowDrums) |          | Facilitator |
| Robert Reichel          | OpenAI       | [@rreichel3](https://github.com/rreichel3)           |          | Facilitator |
| Matt Carey              | Cloudflare   | [@mattzcarey](https://github.com/mattzcarey)         |          | Participant |
| Kapil Sharma            | Microsoft    | [@kapil8811](https://github.com/kapil8811)           |          | Participant |
| Connor Peet             | Microsoft    | [@connor4312](https://github.com/connor4312)         |          | Participant |
| Ola Hungerford          | Nordstrom    | [@olaservo](https://github.com/olaservo)             |          | Participant |
| Gökhan Arkan            | GitHub       | [@gokhanarkan](https://github.com/gokhanarkan)       |          | Participant |
| Joanna Krzek-Lubowiecka | GitHub       | [@joannakl](https://github.com/joannakl)             |          | Participant |
| Maxi Boch               | Independent  | [@maxiboch](https://github.com/maxiboch)             | maxiboch | Participant |

## Operations

| Meeting    | Frequency | Duration | Purpose                                        |
| ---------- | --------- | -------- | ---------------------------------------------- |
| Discussion | TBD       | TBD      | Use-case sharing, annotation review, open Q\&A |

Discord: [#tool-annotations-ig](https://discord.com/channels/1358869848138059966/1482836798517543073)

## Discussion Topics

The following SEPs and themes form the IG's initial discussion agenda. This list is not exhaustive and will evolve as the group identifies new areas of interest.

### Active SEPs Under Discussion

| SEP                                                                                | Title                              | Status | Author                                                                                           |
| ---------------------------------------------------------------------------------- | ---------------------------------- | ------ | ------------------------------------------------------------------------------------------------ |
| [SEP-1862](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1862) | Tool Resolution (preflight checks) | Draft  | [@SamMorrowDrums](https://github.com/SamMorrowDrums)                                             |
| [SEP-1913](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913) | Trust and Sensitivity Annotations  | Draft  | [@SamMorrowDrums](https://github.com/SamMorrowDrums), [@rreichel3](https://github.com/rreichel3) |
| [SEP-1984](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1984) | Comprehensive Tool Annotations     | Draft  | [@sambhav](https://github.com/sambhav)                                                           |
| [SEP-2417](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2417) | Model Preferences for Tools        | Draft  | [@ProductOfAmerica](https://github.com/ProductOfAmerica)                                         |

### Open Questions

* Should runtime annotations (annotations that change between invocations) be added to the protocol?
* Are additional static annotations worth standardizing, and which serve both server and client authors?
* Should tool *response* annotations be added to the protocol?
* How should annotations interact with trust, security, and human-in-the-loop requirements?
* What is the right level of granularity - a few well-defined hints vs. a richer, extensible vocabulary?

## Resources

* [Tool Annotations as Risk Vocabulary](https://blog.modelcontextprotocol.io/posts/2026-03-16-tool-annotations/) - blog post framing the motivation for this work
* [Experimental repo](https://github.com/modelcontextprotocol/experimental-ext-tool-annotations) - repository for the Tool Annotations Interest Group

## Changelog

| Date       | Change          |
| ---------- | --------------- |
| 2026-04-20 | Initial charter |

community/sdk-tiers First recorded · 143 lines, first recorded

# SDK Tiering System ## Overview ## Tier Requirements ## Conformance Testing ## Tier Advancement ## Tier Relegation ## Issue Triage Labels ### Type (pick one) ### Status (pick one) ### Priority (only if actionable)

The first capture of this source. The page was already there, and this is what it said.

# SDK Tiering System

> Feature completeness, protocol support, and maintenance commitment levels for Model Context Protocol SDKs

The MCP SDK Tiering System establishes clear expectations for feature completeness, protocol support, and maintenance commitments across official and community-driven SDKs. This helps developers choose the right SDK for their needs and provides SDK maintainers with a clear path to improving adoption expectations.

<Note>
  **Key dates:**

  * **January 23, 2026**: Conformance tests available
  * **February 23, 2026**: Official SDK tiering published

  Between January 23 and February 23, SDK maintainers can work with the
  Conformance Testing working group to adopt the tests and set up GitHub issue
  tracking with the standardized labels defined below.
</Note>

## Overview

SDKs are classified into three tiers based on feature completeness, maintenance commitments, and documentation quality:

* **Tier 1**: Fully supported SDKs with complete protocol implementation, including all
  non-experimental features and optional capabilities like sampling and elicitation
* **Tier 2**: Actively-maintained SDKs working toward full protocol specification support
* **Tier 3**: Experimental, partially implemented, or specialized SDKs

Experimental features and protocol extensions (such as Tasks and MCP Apps) are not required
for any tier.

## Tier Requirements

| Requirement                 | Tier 1: Fully Supported                                                                  | Tier 2: Commitment to Full Support                               | Tier 3: Experimental   |
| --------------------------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ---------------------- |
| **Conformance Tests**       | 100% pass rate                                                                           | 80% pass rate                                                    | No minimum             |
| **New Protocol Features**   | Before new spec version release, timeline agreed per release based on feature complexity | Within 6 months                                                  | No timeline commitment |
| **Issue Triage**            | Within 2 business days                                                                   | Within a month                                                   | No requirement         |
| **Critical Bug Resolution** | Within 7 days                                                                            | Within two weeks                                                 | No requirement         |
| **Stable Release**          | Required with clear versioning                                                           | At least one stable release                                      | Not required           |
| **Documentation**           | Comprehensive with examples for all features                                             | Basic documentation covering core features                       | No minimum             |
| **Dependency Policy**       | Published update policy                                                                  | Published update policy                                          | Not required           |
| **Roadmap**                 | Published roadmap                                                                        | Published plan toward Tier 1 or explanation for remaining Tier 2 | Not required           |

**Issue Triage** means labeling and determining whether an issue is valid, not resolving the issue.

**Critical Bug** refers to P0 issues (see [Priority labels](#priority-only-if-actionable) for
detailed criteria).

**Stable Release** is a published version explicitly marked as production-ready (e.g., version `1.0.0`
or higher without pre-release identifiers like `-alpha`, `-beta`, or `-rc`).

**Clear Versioning** means following idiomatic versioning patterns with documented
breaking change policies, so users can understand compatibility expectations when upgrading.

**Roadmap** outlines concrete steps and work items that track implementation of required MCP
specification components (non-experimental features and optional capabilities as described in
[Conformance Testing](#conformance-testing)), giving users visibility into upcoming feature support.

## Conformance Testing

All SDKs are evaluated using [automated conformance tests](https://github.com/modelcontextprotocol/conformance)
that validate protocol support against the published specifications. SDKs receive a conformance score
based on test results:

* **Tier 1**: 100% conformance required
* **Tier 2**: 80% conformance required
* **Tier 3**: No minimum requirement

Conformance scores are calculated against **applicable required tests** only:

* Tests for the specification version the SDK targets
* Excluding tests marked as pending or skipped
* Excluding tests for experimental features
* Excluding legacy backward-compatibility tests (unless the SDK claims legacy support)
* Excluding tests labeled `disputed` in the conformance repository, until the dispute is resolved

Conformance testing validates that SDKs correctly implement the protocol by running standardized test
scenarios and checking protocol message exchanges. See [Tier Relegation](#tier-relegation) for how
temporary test failures are handled.

## Tier Advancement

SDK maintainers can request tier advancement by:

1. Self-assessing against tier requirements
2. Opening an issue in the [modelcontextprotocol/modelcontextprotocol](https://github.com/modelcontextprotocol/modelcontextprotocol) repository with supporting evidence
3. Passing automated conformance testing
4. Receiving approval from SDK Working Group maintainers

The SDK Working Group reviews advancement requests and makes final tier assignments.

## Tier Relegation

An SDK may be moved to a lower tier if existing conformance tests on the latest stable release fail
continuously for 4 weeks:

* **Tier 1 → Tier 2**: Any conformance test fails
* **Tier 2 → Tier 3**: More than 20% of conformance tests fail

An SDK may also be relegated if issues remain unaddressed for two months.

## Issue Triage Labels

SDK repositories must use consistent labels to enable automated reporting on issue handling metrics.
Tier calculations use these metrics to measure triage response times (time from issue creation to
first label) and critical bug resolution times (time from P0 label to issue close).

### Type (pick one)

| Label         | Description                   |
| ------------- | ----------------------------- |
| `bug`         | Something isn't working       |
| `enhancement` | Request for new feature       |
| `question`    | Further information requested |

Repositories using [GitHub's native issue types](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/managing-issue-types-in-an-organization)
satisfy this requirement without needing type labels.

### Status (pick one)

Use these exact label names across all repositories to enable consistent reporting and analysis.

| Label                | Description                                             |
| -------------------- | ------------------------------------------------------- |
| `needs confirmation` | Unclear if still relevant                               |
| `needs repro`        | Insufficient information to reproduce                   |
| `ready for work`     | Has enough information to start                         |
| `good first issue`   | Good for newcomers                                      |
| `help wanted`        | Contributions welcome from those familiar with codebase |

### Priority (only if actionable)

| Label | Description                                                     |
| ----- | --------------------------------------------------------------- |
| `P0`  | Critical: core functionality failures or high-severity security |
| `P1`  | Significant bug affecting many users                            |
| `P2`  | Moderate issues, valuable feature requests                      |
| `P3`  | Nice to haves, rare edge cases                                  |

**P0 (Critical)** issues are:

* **Security vulnerabilities** with CVSS score ≥ 7.0 (High or Critical severity)
* **Core functionality failures** that prevent basic MCP operations: connection establishment,
  message exchange, or use of core primitives (tools, resources, prompts)

community/security First recorded · 66 lines, first recorded

# Security Policy ## Reporting a vulnerability ## SDK disclosure and cross-SDK coordination ## Scope ### Stdio transport trust boundary ## Security Interest Group

The first capture of this source. The page was already there, and this is what it said.

# Security Policy

> How to report security vulnerabilities in the Model Context Protocol specification and SDKs, what is in and out of scope, and how SDK maintainers coordinate disclosure.

This page summarizes how security reports are handled across the Model Context Protocol
project. The full policy, including the trust model and the complete list of behaviors that
are intentional and not eligible as vulnerabilities, lives in
[SECURITY.md](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SECURITY.md)
in the specification repository.

## Reporting a vulnerability

Report security issues through GitHub Security Advisories on the affected repository.
Private vulnerability reporting is enabled on the specification repository and on every
official SDK repository in the [modelcontextprotocol](https://github.com/modelcontextprotocol)
organization.

Do not report security issues through public issues, discussions, or pull requests.

## SDK disclosure and cross-SDK coordination

When a report is filed against an SDK, the maintainers of that SDK assess whether the same
issue affects other official SDKs. Many MCP vulnerabilities stem from shared patterns,
transport implementations, or spec-level behavior that multiple SDKs implement the same
way. The receiving maintainers coordinate with the maintainers of other potentially
affected SDKs to determine which are impacted and to what degree, so that fixes and
advisories can be released together rather than leaving some SDKs exposed after others have
published.

If the root cause is a defect in the specification rather than an implementation bug, the
coordinating maintainers will discuss this with the specification maintainers.

CVEs are assigned through GitHub's CNA as part of the GHSA workflow.

## Scope

The following are considered security vulnerabilities when they arise from flaws in the
specification or official SDKs: protocol-level vulnerabilities, authentication or
authorization bypasses, implementation bugs such as injection or memory-safety issues,
sandbox escapes, session hijacking, token leakage, and cross-tenant access.

The full
[SECURITY.md](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SECURITY.md)
documents the MCP trust model and a list of intentional behaviors that are not
vulnerabilities. One of the most common is stdio peer attacks, summarized below.

### Stdio transport trust boundary

When using the stdio transport, the client spawns the server as a local subprocess and both
might run with equivalent environment-level privilege. The SDK does not defend either peer
against a malicious counterpart across the stdio channel: a malicious server already has
arbitrary code execution by virtue of being run, and a malicious client already has full
process control over the server it spawned.

Reports whose only impact is that one stdio peer can crash, hang, exhaust resources of, or
otherwise deny service to the other are out of scope and should be filed as regular issues
rather than as a GHSA. If the affected SDK code is reachable via any of the supported
remote transports, or results in a sandbox escape, the report remains in scope. Deployments
that run stdio servers at reduced privilege are responsible for enforcing isolation at that
boundary. The SDK's stdio transport is not a sandbox.

## Security Interest Group

The [Security Interest Group](/community/interest-groups/security) is the venue for
discussing MCP-specific threats, reviewing security-relevant proposals, and routing
disclosure questions that don't fit a single repository.

community/sep-guidelines First recorded · 271 lines, first recorded

# SEP Guidelines ## What is a SEP? ## When to Write a SEP ## SEP Types ## SEP Workflow ### Step-by-Step Process ### SEP Statuses ## SEP Format ### 1. Preamble ### 2. Abstract ### 3. Motivation ### 4. Specification ### 5. Rationale ### 6. Backward Compatibility ### 7. Reference Implementation ### 8. Security Implications ## Prototype Requirements ## The Sponsor Role ## Status Management ## SEP Review & Resolution ## Conformance Test Requirement ## After Rejection ## Reporting SEP Bugs or Updates ## Transferring SEP Ownership ## Copyright

The first capture of this source. The page was already there, and this is what it said.

# SEP Guidelines

> 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. The SEP should provide a concise technical specification of the feature and a rationale for the feature.

SEPs 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.

When 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.

SEPs 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.

## When to Write a SEP

The SEP process is reserved for changes that are substantial enough to require broad community discussion, a formal design document, and a historical record. A regular GitHub pull request is often more appropriate for smaller changes.

**Write a SEP if your change involves:**

* **A new feature or protocol change** - Adding, modifying, or removing features in the protocol (new API methods, message format changes, interoperability standards)
* **A breaking change** - Any change that is not backwards-compatible
* **A governance or process change** - Altering decision-making or contribution guidelines
* **A complex or controversial topic** - Changes likely to have multiple valid solutions or generate significant debate

**Skip the SEP process for:**

* Bug fixes and typo corrections
* Documentation clarifications
* Adding examples to existing features
* Minor schema fixes that don't change behavior

Not sure? Ask in [Discord](/community/communication#discord) before starting significant work.

## SEP Types

There are four kinds of SEP:

1. **Standards Track** - Describes a new feature or implementation for the Model Context Protocol, or an interoperability standard supported outside the core specification.
2. **Informational** - Describes a design issue or provides guidelines/information to the community without proposing a new feature.
3. **Process** - Describes a process surrounding MCP or proposes a change to a process (like this document).
4. **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.

## SEP Workflow

```mermaid theme={null}
flowchart TD
    Idea["Idea"]
    AwaitingSponsor{"Awaiting Sponsor<br/>(up to 6 months)"}
    Draft["Draft"]
    Dormant["Dormant<br/>(no sponsor)"]
    Withdrawn["Withdrawn<br/>(by author)"]
    InReview["In-Review"]
    Decision{"Core Maintainers decide"}
    Accepted["Accepted"]
    Rejected["Rejected"]
    Final["Final"]

    Idea -->|"Submit PR with SEP file"| AwaitingSponsor
    AwaitingSponsor --> Draft
    AwaitingSponsor --> Dormant
    AwaitingSponsor --> Withdrawn
    Draft -->|"Sponsor reviews"| InReview
    InReview --> Decision
    Decision --> Accepted
    Decision --> Rejected
    Accepted -->|"Reference implementation +<br/>conformance test complete"| Final
```

### Step-by-Step Process

<Note>
  To improve your chances of a SEP being accepted:

  * **Discuss your idea with the relevant [working or interest group](/community/working-interest-groups) in [Discord](/community/communication#discord) first.** This is the single best way to refine your proposal and build early support.
  * **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).** 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, and is still preferable to a cold submission.
  * **Check alignment with [Core Maintainer](/community/governance#roles) priorities and [design principles](/community/design-principles).** Priorities are generally reflected in the [project roadmap](/development/roadmap). Proposals outside current priorities or that conflict with design principles are more likely to face delays or additional friction in the review process.
</Note>

1. **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.

2. **Create a pull request** adding your SEP file to the `seps/` directory in the [specification repository](https://github.com/modelcontextprotocol/modelcontextprotocol).

3. **Update the SEP number**: Once your PR is created, rename the file using the PR number (e.g., PR #1850 becomes `1850-your-feature-title.md`) and update the SEP header.

4. **Find a Sponsor**: Tag a Core Maintainer or Maintainer from [the maintainer list](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md). Choose someone whose area relates to your proposal. Tips:
   * Tag 1-2 relevant maintainers, not everyone
   * Share your PR in the relevant Discord channel
   * If no response after 2 weeks, ask in `#general`

5. **Sponsor assigns themselves**: When a sponsor agrees, they assign themselves to the PR and update the SEP status to `draft`.

6. **Informal review**: The sponsor reviews the proposal and may request changes. Discussion happens in PR comments.

7. **Formal review**: When ready, the sponsor updates the status to `in-review`. The SEP enters formal review by Core Maintainers (meetings every two weeks).

8. **Resolution**: The SEP may be `accepted`, `rejected`, or returned for revision. The sponsor updates the status.

9. **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. When complete and incorporated into the specification, the sponsor updates the status to `final`.

### SEP Statuses

| Status       | Meaning                                          |
| ------------ | ------------------------------------------------ |
| `draft`      | Has a sponsor, undergoing informal review        |
| `in-review`  | Ready for formal Core Maintainer review          |
| `accepted`   | Approved, awaiting implementation + conformance  |
| `rejected`   | Declined by Core Maintainers                     |
| `withdrawn`  | Author withdrew the proposal                     |
| `final`      | Complete with implementation and conformance     |
| `superseded` | Replaced by a newer SEP                          |
| `dormant`    | No sponsor found within 6 months; can be revived |

**Important distinction**: `dormant` is not the same as `rejected`. A dormant SEP simply didn't find a sponsor - the idea may still be valid. If circumstances change (new community interest, new use cases), a dormant SEP can be revived by finding a sponsor and reopening the PR.

## SEP Format

Each SEP should have the following parts:

### 1. Preamble

A short descriptive title, author names/contact info, current status, SEP type, and PR number.

### 2. Abstract

A short (\~200 word) description of the technical issue being addressed.

### 3. Motivation

Why the existing protocol specification is inadequate. This is critical - SEPs without sufficient motivation may be rejected outright.

### 4. Specification

The technical specification describing syntax and semantics of the new feature. Must be detailed enough for competing, interoperable implementations.

### 5. Rationale

Why particular design decisions were made, alternate designs considered, and related work. Should provide evidence of community consensus and address objections raised during discussion.

### 6. Backward Compatibility

All SEPs introducing backward incompatibilities must describe these incompatibilities, their severity, and how to deal with them.

### 7. Reference Implementation

Must be completed before the SEP reaches "Final" status, but need not be complete before acceptance.

### 8. Security Implications

Any security concerns related to the SEP should be explicitly documented.

See the [SEP template](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/README.md#sep-file-structure) for the complete file structure.

## Prototype Requirements

Before a SEP can be accepted, you need "a prototype implementation demonstrating the proposal." Here's what qualifies:

**Acceptable prototypes:**

* A working implementation in one of the official SDKs (as a branch/fork)
* A standalone proof-of-concept demonstrating the key mechanics
* Integration tests showing the proposed behavior
* A reference server or client implementing the feature

**The prototype should:**

* Demonstrate the core functionality works as described
* Show the API design is practical and ergonomic
* Reveal any edge cases or implementation challenges
* Be runnable by reviewers (include setup instructions)

**Not sufficient:**

* Pseudocode alone
* A design document without code
* "Trust me, it works" - reviewers need to see it

The prototype doesn't need to be production-ready. It exists to prove feasibility and surface issues early.

## The Sponsor Role

A Sponsor is a Core Maintainer or Maintainer who champions the SEP through the review process. The sponsor's responsibilities include:

* Reviewing the proposal and providing constructive feedback
* Requesting changes based on community input
* **Updating the SEP status** as the proposal progresses
* Initiating formal review when the SEP is ready
* Presenting and discussing the proposal at Core Maintainer meetings
* Ensuring the proposal meets quality standards

Authors should request status changes through their sponsor rather than modifying the status field themselves.

## Status Management

**The Sponsor is responsible for updating the SEP status.** This ensures status transitions are made by someone with the authority and context to do so appropriately.

The sponsor:

1. Updates the `Status` field directly in the SEP markdown file (or, if they do not have access to the source repo, work with the author to set the right status)
2. Applies matching labels to the pull request (e.g., `draft`, `in-review`, `accepted`)

Both the markdown status field and PR labels should be kept in sync. The markdown file is the canonical record (versioned with the proposal), while PR labels make it easy to filter and search.

## SEP Review & Resolution

SEPs are reviewed by the MCP Core Maintainers team every two weeks.

For a SEP to be accepted it must meet these 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 complete and incorporated into the main repository, the status changes to "Final".

## Conformance Test Requirement

For **Standards Track SEPs** that introduce or modify observable protocol behavior, a conformance scenario must be merged into the [conformance repository](https://github.com/modelcontextprotocol/conformance) before the SEP can reach `Final` status.

**What's required:**

* A conformance scenario tagged with the SEP number, targeting the conformance repository's draft spec-version tag
* A structured traceability file (`sep-NNNN.yaml`) mapping each MUST/MUST NOT and SHOULD/SHOULD NOT in the SEP's Specification section to either a check ID or a documented exclusion (with a tracking issue if it's a framework gap)
* The scenario passes against the SEP's reference implementation

**What's exempt:**

* Process and Informational SEPs
* Standards Track SEPs with no observable protocol behavior (documentation clarifications, non-validating schema annotations, implementation-hardening recommendations)

**Who does what:**

* The **sponsor** ensures a conformance scenario is written and verifies the traceability file covers every MUST/MUST NOT and SHOULD/SHOULD NOT in the SEP
* The **conformance repository maintainers** review the scenario PR for technical correctness
* The test **author** can be anyone: the SEP author, an SDK maintainer, a community contributor

Writing 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.

See [SEP-2484](/seps/2484-conformance-tests-required-for-final-seps) for the full specification including the traceability file format and dispute process.

## After Rejection

Rejection is not permanent. You can:

1. **Address the feedback** - If specific concerns were raised, address them and resubmit
2. **Discuss the rejection** - Ask in Discord to understand the reasoning
3. **Submit a competing SEP** - Sometimes a different approach works better
4. **Wait for the right time** - Community needs evolve; what's rejected today may be welcomed later

## Reporting SEP Bugs or Updates

For SEPs not yet reaching `final` state, comment directly on the SEP's pull request.

Final SEPs are preserved as historical records of the design as accepted. They are not updated after finalization. If the specification changes after a SEP reaches Final status, the current specification is authoritative. Each Final SEP page displays a notice to this effect.

## Transferring SEP Ownership

It occasionally becomes necessary to transfer ownership of SEPs to a new author. In general, we'd like to retain the original author as a co-author, but that's up to the original author.

Good reasons to transfer ownership:

* Original author no longer has time or interest
* Original author is unreachable

Bad reasons:

* You disagree with the direction (submit a competing SEP instead)

## Copyright

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.

community/working-groups/agents First recorded · 143 lines, first recorded

# Agents Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Authority & Decision Rights ## Membership ## Operations ## Resources ## Deliverables & Success Metrics ### Active Work Items ### Success Criteria ## Changelog

The first capture of this source. The page was already there, and this is what it said.

# Agents Charter

> Charter for the MCP Agents Working Group.

## Group Type

**Working Group**

## Mission Statement

The Agents Working Group exists to make interactions with agent-backed systems
interoperable over MCP. Today, these systems are typically exposed as ordinary
tools or through framework-specific integrations, leaving durable execution,
capability discovery, delegation, and multi-turn interaction to ad hoc conventions.
The WG stewards Tasks as MCP's foundation for durable asynchronous execution and
evaluates which remaining gaps require protocol support. Based on production use
cases and prototypes, the group will either evolve Tasks, introduce an Agents
Extension that complements it, or document how existing MCP primitives should be
used consistently.

## Scope

### In Scope

* **Tasks**: Stabilization of the
  [`io.modelcontextprotocol/tasks`](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2663)
  extension and its promotion into the core MCP protocol, including collecting
  implementation feedback, resolving ambiguities, and evaluating proposed changes
  to its lifecycle.
* **Agents Extension Evaluation**: Evaluate agent-backed MCP use cases, including
  agent-as-tool, remote-agent, and supervisor/sub-agent patterns, to determine
  whether an Agents Extension is needed to complement Tasks.
* **Prototypes and Proposals**: Develop narrowly scoped proofs of concept where they
  help determine whether to introduce an Agents Extension, evolve Tasks, or rely on
  existing MCP primitives.
* **Implementation Coordination**: Coordinate with SDK and conformance maintainers
  on implementation feedback, examples, and coverage for specifications owned by
  the group.
* **Cross-Cutting Concerns**: Coordinate with relevant groups when Tasks or
  evaluated agent use cases raise transport, events, skills, authorization,
  metadata, or external-interoperability questions.
* **Documentation**: Maintain the Tasks specification and document agent-backed MCP
  use cases, findings, and any proposals adopted by the group.

### Out of Scope

* Building or standardizing general-purpose agent frameworks and runtimes, including
  internal choices about planning, memory, model selection, and orchestration. The
  group standardizes behavior at MCP interoperability boundaries rather than host or
  server implementation internals.
* Transport wire formats and session mechanics, which are owned by the Transports WG.
* General event delivery and callback mechanisms, which are owned by the Triggers and
  Events WG.

The charter does not predetermine where inference or agent loops run, or whether a
particular capability belongs in Tasks, an Agents Extension, or existing MCP
primitives. The WG evaluates those questions through its design work.

### Related Groups

* **[Transports WG](https://github.com/modelcontextprotocol/transports-wg)** -
  Task polling, multi-round-trip requests, stateless operation, and request
  association depend on transport and message-flow semantics.
* **[Triggers and Events WG](/community/working-groups/triggers-events)** -
  Proactive task-status and completion notifications are event-delivery concerns
  owned by that group.

## Leadership

| Role | Name             | Organization        | GitHub                                             | Term    |
| ---- | ---------------- | ------------------- | -------------------------------------------------- | ------- |
| Lead | Luca Chang       | Amazon Web Services | [@LucaButBoring](https://github.com/LucaButBoring) | Initial |
| Lead | Caitie McCaffrey | Microsoft           | [@CaitieM20](https://github.com/CaitieM20)         | Initial |

## Authority & Decision Rights

| Decision Type                       | Authority Level                                        |
| ----------------------------------- | ------------------------------------------------------ |
| Meeting logistics & scheduling      | WG Leads (autonomous)                                  |
| Proposal prioritization within WG   | WG Leads (autonomous)                                  |
| SEP triage & closure (in scope)     | WG Leads (autonomous, with documented rationale)       |
| Technical design within scope       | WG consensus                                           |
| Spec changes (additive)             | WG consensus → Core Maintainer approval                |
| Spec changes (breaking/fundamental) | WG consensus → Core Maintainer approval + wider review |
| Scope expansion                     | Core Maintainer approval required                      |
| WG Member approval                  | WG Member sponsors                                     |

## Membership

| Name             | Organization        | GitHub                                             | Discord | Level |
| ---------------- | ------------------- | -------------------------------------------------- | ------- | ----- |
| Luca Chang       | Amazon Web Services | [@LucaButBoring](https://github.com/LucaButBoring) |         | Lead  |
| Caitie McCaffrey | Microsoft           | [@CaitieM20](https://github.com/CaitieM20)         |         | Lead  |

## Operations

| Meeting         | Frequency | Duration   | Purpose                                             |
| --------------- | --------- | ---------- | --------------------------------------------------- |
| Working Session | Weekly    | 30 minutes | Technical discussion, research, and proposal review |

Meetings are published at
[meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io).

Discord: `#agents-wg`

## Resources

* Working group repository:
  [modelcontextprotocol/agents-wg](https://github.com/modelcontextprotocol/agents-wg)
* Tasks extension repository:
  [modelcontextprotocol/ext-tasks](https://github.com/modelcontextprotocol/ext-tasks)
* Tasks specification:
  [SEP-2663: Tasks Extension](/seps/2663-tasks-extension)

## Deliverables & Success Metrics

### Active Work Items

| Item                                            | Status      | Target Date | Champion                                                                                       |
| ----------------------------------------------- | ----------- | ----------- | ---------------------------------------------------------------------------------------------- |
| Tasks stabilization and core protocol promotion | In Progress |             | [@LucaButBoring](https://github.com/LucaButBoring)                                             |
| Agents Extension evaluation and recommendation  | In Progress |             | TBD                                                                                            |
| Two-level agent definition proof of concept     | In Progress |             | [@LucaButBoring](https://github.com/LucaButBoring), [@madhaviai](https://github.com/madhaviai) |

### Success Criteria

* Tasks is fully stabilized based on implementation feedback and promoted from an
  extension into the core MCP protocol.
* Lifecycle ambiguities and conformance gaps that block Tasks stabilization are
  resolved or explicitly dispositioned.
* The group publishes an evaluation of whether an Agents Extension is needed to
  complement Tasks, supported by documented use cases and relevant prototype
  evidence.
* Based on that evaluation, the group either evolves Tasks, proposes an Agents
  Extension, or documents how existing MCP primitives are sufficient.
* Proposed agent protocol surface is evaluated through prototypes and
  implementation feedback before being advanced.

## Changelog

| Date       | Change          |
| ---------- | --------------- |
| 2026-08-04 | Initial charter |

community/working-groups/file-uploads First recorded · 110 lines, first recorded

# File Uploads Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Authority & Decision Rights ## Membership ## Operations ## Deliverables & Success Metrics ### Active Work Items ### Success Criteria ## Changelog

The first capture of this source. The page was already there, and this is what it said.

# File Uploads Charter

> Charter for the MCP File Uploads Working Group.

## Group Type

**Working Group**

## Mission Statement

The File Uploads Working Group exists to define how MCP tools and elicitation requests declare file
inputs so that hosts can present native file pickers and pass user-selected file content to servers.
Today, servers that need a file from the user resort to prose instructions asking for base64 strings
or local paths, which produces inconsistent UX and pushes encoding details onto end users. This WG
will specify a minimal, schema-level mechanism for declaring file inputs and the wire format for
delivering them, anchored on [SEP-2356](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2356).

## Scope

### In Scope

* **Specification Work**: SEPs defining declarative file input descriptors on tool input schemas and
  elicitation request schemas, the wire encoding for file content, and host-side handling
  requirements.
* **Reference Implementations**: SDK types and helpers for `FileInputDescriptor`, data URI encoding,
  and a sample host flow demonstrating picker invocation and value substitution.
* **Cross-Cutting Concerns**: Coordination with the MCP Apps WG where embedded UI surfaces present
  their own file pickers, and with the Security WG on host-side validation requirements.
* **Documentation**: Specification sections covering file input declaration and a migration guide
  for servers currently using ad-hoc base64 instructions.

### Out of Scope

* Server-to-client file delivery, which is already covered by Resources and `BlobResourceContents`.
* Changes to the transport layer or session model.

The WG may evaluate approaches such as streaming, chunked transfer, or presigned upload URLs as part
of its design work; whether those land in the initial SEP or a follow-up is a WG decision rather
than a charter constraint.

### Related Groups

* **MCP Apps WG** — embedded app UIs may surface their own file pickers; the descriptor format
  should be reusable in that context.
* **Security WG** — host-side validation requirements for user-supplied file content (the SEP
  references [OWASP ASVS V5](https://owasp.org/www-project-application-security-verification-standard/)
  for general upload hygiene).
* **Tool Annotations IG** — file input descriptors are a form of input-parameter metadata and should
  remain consistent with the broader annotation taxonomy.

## Leadership

| Role | Name           | Organization | GitHub                                   | Term    |
| ---- | -------------- | ------------ | ---------------------------------------- | ------- |
| Lead | Den Delimarsky | Anthropic    | [@localden](https://github.com/localden) | Initial |

Sponsored by Den Delimarsky ([@localden](https://github.com/localden)) and Nick Cooper
([@nickcoai](https://github.com/nickcoai)).

## Authority & Decision Rights

| Decision Type                       | Authority Level                                        |
| ----------------------------------- | ------------------------------------------------------ |
| Meeting logistics & scheduling      | WG Leads (autonomous)                                  |
| Proposal prioritization within WG   | WG Leads (autonomous)                                  |
| SEP triage & closure (in scope)     | WG Leads (autonomous, with documented rationale)       |
| Technical design within scope       | WG consensus                                           |
| Spec changes (additive)             | WG consensus → Core Maintainer approval                |
| Spec changes (breaking/fundamental) | WG consensus → Core Maintainer approval + wider review |
| Scope expansion                     | Core Maintainer approval required                      |
| WG Member approval                  | WG Member sponsors                                     |

## Membership

| Name           | Organization | GitHub                                   | Discord | Level     |
| -------------- | ------------ | ---------------------------------------- | ------- | --------- |
| Den Delimarsky | Anthropic    | [@localden](https://github.com/localden) |         | Lead      |
| Nick Cooper    | OpenAI       | [@nickcoai](https://github.com/nickcoai) |         | WG Member |
| Olivier Chafik | Anthropic    | [@ochafik](https://github.com/ochafik)   |         | WG Member |

## Operations

| Meeting         | Frequency | Duration | Purpose                               |
| --------------- | --------- | -------- | ------------------------------------- |
| Working Session | Biweekly  | 30 min   | Technical discussion, proposal review |

Discord: `#file-uploads-wg`

## Deliverables & Success Metrics

### Active Work Items

| Item                                                                                                        | Status | Target Date | Champion                               |
| ----------------------------------------------------------------------------------------------------------- | ------ | ----------- | -------------------------------------- |
| [SEP-2356: Declarative file inputs](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2356) | Draft  | End May     | [@ochafik](https://github.com/ochafik) |
| TypeScript SDK reference implementation                                                                     | —      | End May     | [@ochafik](https://github.com/ochafik) |
| Reference implementation in a second Tier-1 SDK                                                             | —      | End June    | TBD                                    |

### Success Criteria

* An accepted SEP defining the file input descriptor and wire encoding.
* Reference implementations in at least two Tier-1 SDKs.
* At least one production host rendering a native file picker from the descriptor.
* Conformance test coverage for the new schema keyword.

## Changelog

| Date       | Change          |
| ---------- | --------------- |
| 2026-04-23 | Initial charter |

community/working-groups/inspector-v2 First recorded · 110 lines, first recorded

# Inspector V2 Working Group Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Authority & Decision Rights ## Membership ## Operations ## Deliverables & Success Metrics ### Active Work Items ### Success Criteria ## Changelog

The first capture of this source. The page was already there, and this is what it said.

# Inspector V2 Working Group Charter

> Charter for the Inspector V2 Working Group, a Working Group of the Model Context Protocol community.

## Group Type

Working Group

## Mission Statement

The Inspector V2 Working Group is building Inspector V2, a new web-based MCP inspector redesigned from the ground up for maintainability and reliability. The group delivers a shared Inspector Core architecture that maximizes code reuse across Web, CLI, and TUI implementations, together with a comprehensive testing apparatus. This effort requires cross-maintainer collaboration because it spans UI, protocol tooling, and test infrastructure that no single maintainer owns today.

## Scope

### In Scope

* The `modelcontextprotocol/inspector` repository, including:
* **Inspector Core** — a new shared-code architecture that provides common MCP and protocol interfaces for all Inspector front-ends.
* **Web Inspector UI** — browser-based inspector built on Mantine and TypeScript.
* **CLI Inspector** — command-line interface sharing Inspector Core.
* **TUI Inspector** — terminal UI sharing Inspector Core.
* **Testing apparatus** — shared test harnesses, fixtures, and integration tests across all Inspector surfaces.
* Deprecation and migration of the existing Inspector on `main` to a `v1.x` maintenance branch.
* Adoption of MCP TypeScript SDK V2 inside Inspector Core once available.

### Out of Scope

* The core MCP specification.
* MCP SDK maintenance (TypeScript, Python, or any other language SDK).
* MCP server implementations.

### Related Groups

* **SDK WG** — Inspector Core consumes the TypeScript SDK; coordination required for SDK V2 adoption.
* **MCP Apps WG** — shared surface area around client/app ergonomics and inspection workflows.
* **Auth WG** — authentication flows exercised by Inspector when connecting to protected servers.
* **Registry WG** — discovery and metadata surfaces that Inspector presents to users.

## Leadership

| Role    | Name           | Organization | GitHub                                           | Term    |
| ------- | -------------- | ------------ | ------------------------------------------------ | ------- |
| WG Lead | Cliff Hall     | Futurescale  | [@cliffhall](https://github.com/cliffhall)       | Ongoing |
| WG Lead | Ola Hungerford | Nordstrom    | [@olaservo](https://github.com/olaservo)         | Ongoing |
| WG Lead | Bob Dickinson  | TeamSpark.ai | [@BobDickinson](https://github.com/BobDickinson) | Ongoing |

## Authority & Decision Rights

| Decision Type                       | Authority Level                                        |
| ----------------------------------- | ------------------------------------------------------ |
| Meeting logistics & scheduling      | WG Leads (autonomous)                                  |
| Proposal prioritization within WG   | WG Leads (autonomous)                                  |
| SEP triage & closure (in scope)     | WG Leads (autonomous, with documented rationale)       |
| Technical design within scope       | WG consensus                                           |
| Spec changes (additive)             | WG consensus → Core Maintainer approval                |
| Spec changes (breaking/fundamental) | WG consensus → Core Maintainer approval + wider review |
| Scope expansion                     | Core Maintainer approval required                      |
| WG Member approval                  | WG Member sponsors                                     |

## Membership

| Name           | Organization | GitHub                                           | Discord     | Level      |
| -------------- | ------------ | ------------------------------------------------ | ----------- | ---------- |
| Cliff Hall     | Futurescale  | [@cliffhall](https://github.com/cliffhall)       | seaofarrows | Maintainer |
| Ola Hungerford | Nordstrom    | [@olaservo](https://github.com/olaservo)         | olaservo    | Maintainer |
| Bob Dickinson  | TeamSpark.ai | [@BobDickinson](https://github.com/BobDickinson) | rddthree    | Maintainer |
| Tobin South    | Anthropic    | [@tobinsouth](https://github.com/tobinsouth)     | tobinsouth  | Member     |

## Operations

| Meeting         | Frequency                                  | Duration   | Purpose                               |
| --------------- | ------------------------------------------ | ---------- | ------------------------------------- |
| Working Session | Weekly, Wednesdays 11:00 America/New\_York | 60 minutes | Technical discussion, proposal review |

Meetings are held at [meet.modelcontextprotocol.io/tag/inspector-v2-wg](https://meet.modelcontextprotocol.io/tag/inspector-v2-wg). Agendas are posted at least 7 days in advance per current MCP meeting policy. Meeting notes are published to the [Meeting Notes — Inspector V2 WG](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/categories/meeting-notes-inspector-v2-wg) discussion category in the `modelcontextprotocol/modelcontextprotocol` repository.

**Communication channels**

* Primary channel: `#inspector-v2-wg` on the MCP Discord.
* Async discussion: GitHub Discussions in `modelcontextprotocol/inspector`.
* Quarterly updates: posted to the WG's GitHub Discussions category.

## Deliverables & Success Metrics

### Active Work Items

| Work Item                                                                               | Status                       | Owner(s)                   |
| --------------------------------------------------------------------------------------- | ---------------------------- | -------------------------- |
| Web Inspector UI (Mantine / TypeScript) — dumb components with real MCP/Core interfaces | In Progress                  | Cliff Hall, Ola Hungerford |
| Inspector Core shared-code architecture                                                 | In Progress                  | Bob Dickinson              |
| CLI Inspector and TUI Inspector                                                         | In Progress                  | Bob Dickinson              |
| Migration of existing Inspector on `main` to `v1.x` maintenance branch                  | Planning                     | WG Leads                   |
| Testing apparatus across Core, Web, CLI, and TUI                                        | Planning                     | WG Leads                   |
| Inspector Core adoption of MCP TypeScript SDK V2                                        | Blocked (gated by TS SDK WG) | Bob Dickinson              |

### Success Criteria

1. **End of Q1** — Web UI complete with "dumb" components wired to real MCP/Inspector Core interfaces.
2. **End of Q1** — Inspector Core architecture finalized.
3. **End of Q2** — Inspector Core merged to `v2/main` and working end-to-end with the Web UI.
4. **End of Q2** — CLI and TUI Inspectors merged to `v2/main` and working end-to-end with Inspector Core.
5. **End of Q2** — Existing Inspector on `main` moved to the `v1.x` branch and officially deprecated.
6. **End of Q2** — New Inspector family (Web, CLI, TUI) published and generally available.
7. **End of Q3** — Inspector Core running on MCP TypeScript SDK V2 (gated by the TypeScript SDK WG's delivery schedule).

## Changelog

| Date       | Change                                           | Author               |
| ---------- | ------------------------------------------------ | -------------------- |
| 2026-04-11 | Initial charter adopted for SEP-2149 compliance. | Cliff Hall (Co-Lead) |

community/working-groups/interceptors First recorded · 92 lines, first recorded

# Interceptors Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Authority & Decision Rights ## Operations ## Resources ## Deliverables & Success Metrics ### Active Work Items ### Success Criteria ## Changelog

The first capture of this source. The page was already there, and this is what it said.

# Interceptors Charter

> Charter for the MCP Interceptors Working Group.

## Group Type

**Working Group**

## Mission Statement

The Interceptors Working Group exists to standardize how context operations are intercepted, validated, and transformed at key points in the agentic lifecycle. This covers MCP-defined operations such as tool invocations, resource access, prompt handling, sampling, and elicitation, as well as any other operation that shapes agent context — including LLM completions and custom application-specific workflows. The ecosystem is developing a sprawling landscape of sidecars, proxies, and gateways for cross-cutting concerns that are largely non-reusable and non-interoperable, creating an M × N integration problem. The WG will produce specification extensions and reference implementations that define interceptors as a new MCP primitive with two types — validators (inspect and return pass/fail decisions) and mutators (transform context payloads) — discoverable and invocable through MCP's existing JSON-RPC patterns across deployment models including in-process, sidecar, and remote service.

## Scope

### In Scope

* **Specification Work**: SEPs defining the interceptor primitive — validator and mutator types, lifecycle event hooks for MCP operations (tool calls, resource reads, prompt gets, sampling, elicitation) and extensible to non-MCP context operations (LLM completions, custom workflows), trust-boundary-aware execution model, priority-based chain ordering, and audit mode semantics.
* **Reference Implementations**: Multi-language SDK libraries for building interceptors, sample interceptors (PII redaction, schema validation, audit logging), a common interceptor sidecar/proxy runtime, and a CLI client for interceptor invocation and testing.
* **Cross-Cutting Concerns**: Transport-level interception points, gateway-based deployment patterns, and interplay with routing and policy layers (see Related Groups).
* **Documentation**: Specification sections covering interceptor authoring, deployment models (in-process, sidecar, remote service), chain configuration, and migration guidance from ad-hoc middleware approaches.

### Out of Scope

* Client-specific hook implementation details (e.g., Claude Code's internal hook execution engine) — the WG standardizes the protocol-level interface, not host internals.
* Transport-layer wire format or session model changes (owned by the Transports WG).
* General-purpose middleware or proxy infrastructure beyond what the MCP protocol requires.

### Related Groups

* **Transports WG** — interceptors operate on MCP message flows whose delivery behavior depends on the transport; coordination needed on transport-level interception points.
* **Gateways IG** — gateways are a key deployment model for interceptors; coordination needed on gateway-based interceptor patterns and shared concerns around routing, policy, and observability.

## Leadership

| Role | Name                     | Organization | GitHub                                       | Term    |
| ---- | ------------------------ | ------------ | -------------------------------------------- | ------- |
| Lead | Sambhav Kothari          | Bloomberg    | [@sambhav](https://github.com/sambhav)       | Initial |
| Lead | Peder Holdgaard Pedersen | Saxo Bank    | [@PederHP](https://github.com/PederHP)       | Initial |
| Lead | Kurt Degiorgio           | Bloomberg    | [@degiorgio](https://github.com/degiorgio)   | Initial |
| Lead | Uk-Jae Jeong             | Bloomberg    | [@jeongukjae](https://github.com/jeongukjae) | Initial |
| Lead | Ola Hungerford           | Nordstrom    | [@olaservo](https://github.com/olaservo)     | Initial |

## Authority & Decision Rights

| Decision Type                       | Authority Level                                        |
| ----------------------------------- | ------------------------------------------------------ |
| Meeting logistics & scheduling      | WG Leads (autonomous)                                  |
| Proposal prioritization within WG   | WG Leads (autonomous)                                  |
| SEP triage & closure (in scope)     | WG Leads (autonomous, with documented rationale)       |
| Technical design within scope       | WG consensus                                           |
| Spec changes (additive)             | WG consensus → Core Maintainer approval                |
| Spec changes (breaking/fundamental) | WG consensus → Core Maintainer approval + wider review |
| Scope expansion                     | Core Maintainer approval required                      |
| WG Member approval                  | WG Member sponsors                                     |

## Operations

| Meeting         | Frequency | Duration   | Purpose                               |
| --------------- | --------- | ---------- | ------------------------------------- |
| Working Session | Biweekly  | 60 minutes | Technical discussion, proposal review |

## Resources

* Experimental extension repository: [modelcontextprotocol/experimental-ext-interceptors](https://github.com/modelcontextprotocol/experimental-ext-interceptors)
* Motivation: [SEP-1763](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1763)

## Deliverables & Success Metrics

### Active Work Items

| Item                                                                  | Status      | Target Date | Champion |
| --------------------------------------------------------------------- | ----------- | ----------- | -------- |
| SEP-1763: Interceptors                                                | Draft       |             | TBD      |
| Sample interceptors (PII redaction, schema validation, audit logging) | In Progress |             | TBD      |
| Common interceptor sidecar runtime                                    | Ideating    |             | TBD      |
| CLI client for interceptor invocation and testing                     | Ideating    |             | TBD      |
| Reference implementation in Go SDK                                    | In Progress |             | TBD      |
| Reference implementation in C# SDK                                    | In Progress |             | TBD      |

### Success Criteria

* An accepted SEP defining the interceptor primitive (validators, mutators), lifecycle event hooks, and trust-boundary-aware chain execution.
* Reference implementations in at least two Tier-1 SDKs (Go, C#).
* A common interceptor sidecar runtime enabling platform teams to deploy interceptors without modifying individual MCP servers.
* CLI tooling for interceptor invocation and testing.
* Demonstrated interoperability across deployment models (in-process, sidecar, remote service).

## Changelog

| Date       | Change          |
| ---------- | --------------- |
| 2026-04-21 | Initial charter |

community/working-groups/registry First recorded · 112 lines, first recorded

# Registry Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Authority & Decision Rights ## Membership ## Emeritus Membership ## Operations ## Resources ## Deliverables & Success Metrics ### Active Work Items ### Success Criteria ## Changelog

The first capture of this source. The page was already there, and this is what it said.

# Registry Charter

> Charter for the MCP Registry Working Group.

## Group Type

**Working Group**

## Mission Statement

The Registry Working Group exists to build and maintain the official MCP Registry — an open catalog and API for publicly available MCP servers — so that clients, sub-registries, and end users can discover, evaluate, and install servers with confidence. The WG owns the registry service, the `server.json` schema, the registry API specification, and the sub-registry ecosystem that further distributes server metadata.

## Scope

### In Scope

* **Registry Service**: Operation, reliability, and evolution of the hosted registry at `registry.modelcontextprotocol.io`, including uptime, monitoring, and incident response.
* **Registry API Specification**: The OpenAPI spec defining how any registry (official or private) exposes server metadata.
* **`server.json` Schema**: The standardized format for describing MCP server identity, packages, runtime configuration, and capabilities — coordinated with the Server Card WG to keep Server Card a coherent subset.
* **Client SDKs**: Generated or hand-maintained client libraries that make it easy for clients and sub-registries to integrate with the registry API.
* **Publishing & Trust**: Authentication flows (GitHub OAuth, GitHub OIDC, DNS/HTTP verification), namespace ownership, moderation tooling, and community-driven flagging.
* **Adoption & Outreach**: Documentation, onboarding guides, and outreach to drive catalog coverage.
* **Issue Triage & Automation**: Labeling system, triage, and contributor workflow for the registry repo.

### Out of Scope

* Any runtime-related MCP protocol specification aspects (owned by Core Maintainers and other WGs).
* Server Card format and discovery mechanism (owned by the Server Card WG; this WG coordinates on `server.json` alignment).
* Ranking/choosing between MCP server implementations on behalf of MCP clients or end-users.
* Hosting, distributing, or executing MCP server code or binaries — the registry is a metadata catalog, not a package registry.
* Any commitment to delivering an enterprise-ready or reusable registry implementation. The codebase supports this instance only and is not intended for external deployments.

### Related Groups

* **Server Card WG** — `server.json` and Server Card must stay aligned; the registry will expose Server Cards + local package-related metadata for published entries. Tight coordination required to avoid schema divergence.

## Leadership

| Role | Name              | Organization | GitHub                                     | Term    |
| ---- | ----------------- | ------------ | ------------------------------------------ | ------- |
| Lead | Radoslav Dimitrov | Stacklok     | [@rdimitrov](https://github.com/rdimitrov) | Initial |

## Authority & Decision Rights

| Decision Type                       | Authority Level                                        |
| ----------------------------------- | ------------------------------------------------------ |
| Meeting logistics & scheduling      | WG Leads (autonomous)                                  |
| Proposal prioritization within WG   | WG Leads (autonomous)                                  |
| SEP triage & closure (in scope)     | WG Leads (autonomous, with documented rationale)       |
| Technical design within scope       | WG consensus                                           |
| Spec changes (additive)             | WG consensus → Core Maintainer approval                |
| Spec changes (breaking/fundamental) | WG consensus → Core Maintainer approval + wider review |
| Scope expansion                     | Core Maintainer approval required                      |
| WG Member approval                  | WG Member sponsors                                     |

## Membership

| Name               | Organization | GitHub                                           | Discord    | Level     | Maintainer? |
| ------------------ | ------------ | ------------------------------------------------ | ---------- | --------- | ----------- |
| Radoslav Dimitrov  | Stacklok     | [@rdimitrov](https://github.com/rdimitrov)       | dimitrovr  | Lead      | Yes         |
| Tadas Antanavicius | PulseMCP     | [@tadasant](https://github.com/tadasant)         | tadasant\_ | WG Member | Yes         |
| Bob Dickinson      | TeamSpark    | [@BobDickinson](https://github.com/BobDickinson) | rddthree   | WG Member | Yes         |
| Preeti Dewani      | Ravenmail    | [@pree-dew](https://github.com/pree-dew)         | pree\_dew  | WG Member | No          |

## Emeritus Membership

| Name         | Organization | GitHub                                     | Discord   | Level     | Maintainer? |
| ------------ | ------------ | ------------------------------------------ | --------- | --------- | ----------- |
| Adam Jones   | Anthropic    | [@domdomegg](https://github.com/domdomegg) | domdomegg | WG Member | Yes         |
| Toby Padilla | GitHub       | [@toby](https://github.com/toby)           |           | WG Member | Yes         |

## Operations

| Meeting         | Frequency | Duration | Purpose                                           |
| --------------- | --------- | -------- | ------------------------------------------------- |
| Working Session | Weekly    | 30 min   | Technical discussion, triage, and proposal review |

Discord: `#registry-dev`

## Resources

* Registry service repository: [modelcontextprotocol/registry](https://github.com/modelcontextprotocol/registry)

## Deliverables & Success Metrics

### Active Work Items

| Item                                                                  | Status      | Target Date | Champion                                 |
| --------------------------------------------------------------------- | ----------- | ----------- | ---------------------------------------- |
| Server Card / `server.json` alignment                                 | In Progress | Q2 2026     | [@tadasant](https://github.com/tadasant) |
| Uptime & monitoring automation                                        | Planned     | Q2 2026     | TBD                                      |
| Issue triage automation & labeling system                             | Planned     | Q2 2026     | TBD                                      |
| Adoption outreach to popular server maintainers                       | Ideating    | Q3 2026     | TBD                                      |
| Cataloging specification support by clients and sub-registry products | Ideating    | Q3 2026     | TBD                                      |
| Client SDK generation / publication                                   | Ideating    | Q3 2026     | TBD                                      |
| Registry API v1 GA                                                    | Ideating    | TBD         | TBD                                      |

### Success Criteria

* Registry uptime ≥ 99.9% with automated monitoring and alerting.
* `server.json` schema and Server Card format aligned with no unintentional divergence.
* Majority of popular, publicly available MCP servers published to the registry.
* At least one client SDK (generated or maintained) available for registry consumers.
* Registry API v1 specification finalized and stable.
* Active sub-registry ecosystem consuming the official registry API.

## Changelog

| Date       | Change                                                                                      |
| ---------- | ------------------------------------------------------------------------------------------- |
| 2026-07-30 | @tadasant stepped down as Lead; @rdimitrov is now sole Lead (@tadasant remains a WG Member) |
| 2026-04-08 | Initial charter                                                                             |

community/working-groups/sdk First recorded · 89 lines, first recorded

# SDK Working Group Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Authority & Decision Rights ## Membership ## Operations ## Deliverables & Success Metrics ### Active Work Items ### Success Criteria ## Changelog

The first capture of this source. The page was already there, and this is what it said.

# SDK Working Group Charter

> Charter for the MCP SDK Working Group.

## Group Type

**Working Group**

## Mission Statement

The 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.

## Scope

### In Scope

* **SDK Tiering**: Operating the [SDK Tiering System](/community/sdk-tiers), including reviewing tier advancement requests, applying relegation criteria, and maintaining the published tier assignments.
* **Official SDK Roster**: Evaluating proposals to add new official SDKs or retire existing ones.
* **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.
* **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.
* **Conformance Integration**: Working with the Conformance Testing project to ensure each official SDK runs the conformance suite and publishes results.
* **Maintainer Coordination**: Providing a forum for per-language SDK maintainers to share implementation experience and surface specification ambiguities back to Core Maintainers.

### Out of Scope

* **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).
* **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.
* **Conformance test authoring**: The conformance test suite itself is owned by the [Conformance Testing](https://github.com/modelcontextprotocol/conformance) project.
* **Third-party and community SDKs**: SDKs outside the [modelcontextprotocol](https://github.com/modelcontextprotocol) organization are not governed by this group.

### Related Groups

* **Transports WG**: Transport implementations are a substantial part of every SDK. The SDK WG coordinates with the Transports WG on rollout sequencing when transport SEPs land.
* **Conformance Testing**: Tier assignments depend on conformance scores. The SDK WG consumes conformance results and feeds back gaps in test coverage.
* **All specification-producing WGs**: The SDK WG is a downstream consumer of accepted SEPs and coordinates reference-implementation timing with the originating group.

## Leadership

| Role | Name             | Organization | GitHub                                                 | Term    |
| ---- | ---------------- | ------------ | ------------------------------------------------------ | ------- |
| Lead | Felix Weinberger | Anthropic    | [@felixweinberger](https://github.com/felixweinberger) | Ongoing |

## Authority & Decision Rights

| Decision Type                            | Authority Level                                |
| ---------------------------------------- | ---------------------------------------------- |
| Meeting logistics & scheduling           | WG Leads (autonomous)                          |
| Proposal prioritization within WG        | WG Leads (autonomous)                          |
| SDK tier advancement or relegation       | WG consensus                                   |
| Cross-SDK design guidance                | WG consensus (advisory to per-SDK maintainers) |
| Per-SDK releases, versioning, API design | That SDK's maintainers (autonomous)            |
| Adding or retiring an official SDK       | WG consensus → Core Maintainer approval        |
| Changes to the tiering criteria          | WG consensus → Core Maintainer approval        |
| Scope expansion                          | Core Maintainer approval required              |
| WG Member approval                       | WG Member sponsors                             |

## Membership

WG Members are the maintainers of each official SDK as recorded in [MAINTAINERS.md](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md) and the corresponding roles in [modelcontextprotocol/access](https://github.com/modelcontextprotocol/access). Maintainers of any official SDK are WG Members by default.

## Operations

| Meeting         | Frequency | Duration | Purpose                                              |
| --------------- | --------- | -------- | ---------------------------------------------------- |
| Working Session | Biweekly  | 45 min   | Release coordination, tier reviews, cross-SDK design |

Communication happens in the `#general-sdk-dev` Discord channel and the SDK Working Group category in [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions).

## Deliverables & Success Metrics

### Active Work Items

| Item                                                | Status      | Target Date | Champion            |
| --------------------------------------------------- | ----------- | ----------- | ------------------- |
| 2026-06-30 spec support across Tier-1 SDKs          | Planning    | 2026 Q3     | Per-SDK maintainers |
| Cross-SDK guidance for stateless transport adoption | In progress | 2026 Q2     | WG Leads            |
| Quarterly tier review                               | Recurring   | Quarterly   | WG Leads            |

### Success Criteria

* All official SDKs have a published tier and a passing conformance run on their default branch.
* Tier-1 SDKs ship support for each released specification version within the timeline their tier requires.
* Tier advancement and relegation decisions are recorded with rationale in GitHub Discussions.

## Changelog

| Date       | Change          |
| ---------- | --------------- |
| 2026-04-28 | Initial charter |

community/working-groups/server-card First recorded · 101 lines, first recorded

# Server Card Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Authority & Decision Rights ## Membership ## Operations ## Resources ## Deliverables & Success Metrics ### Active Work Items ### Success Criteria ### Active Work Items ### Success Criteria ## Changelog

The first capture of this source. The page was already there, and this is what it said.

# Server Card Charter

> Charter for the MCP Server Card Working Group.

## Group Type

**Working Group**

## Mission Statement

The Server Card Working Group exists to define mechanisms that facilitate discovery and usage of MCP servers via common discovery mechanisms, and to provide guidance on how this fits into broader AI standardization efforts around discovery. Concretely, the WG will define what constitutes an MCP Server Card, the standardized document format a Server Card must follow, and how clients discover a Server Card for a given server.

## Scope

### In Scope

* **Specification Work**: SEPs or extensions defining what constitutes an MCP Server Card and the specific format of the Server Card document.
* **Discovery Mechanism**: Specification of how an MCP Server Card document is discovered (well-known URL, resource-based discovery, etc.).
* **Cross-Ecosystem Coordination**: A recommendation to the [AI Card](https://github.com/Agent-Card/ai-card) effort on how to interact with MCP Server Cards.
* **Documentation**: Specification sections and guidance covering Server Card authoring and consumption.

### Out of Scope

* Changes to the MCP initialization handshake or transport layer.
* A general-purpose MCP server registry or catalog (owned by the Registry WG).
* Internationalization of Server Card content until an MCP-wide i18n approach is defined.

### Related Groups

* **Registry WG** — Server Card format should stay as close as possible to a subset of `server.json`; coordination required to avoid divergence.
* **AI Card effort** (external) — ongoing discussion on whether and how an AI Catalog can link directly to an MCP Server Card.

## Leadership

| Role | Name              | Organization | GitHub                                               | Term                         |
| ---- | ----------------- | ------------ | ---------------------------------------------------- | ---------------------------- |
| Lead | David Soria Parra | Anthropic    | [@dsp-ant](https://github.com/dsp-ant)               | 6 months (ends Aug 14, 2026) |
| Lead | Sam Morrow Drums  | GitHub       | [@SamMorrowDrums](https://github.com/SamMorrowDrums) | 6 months (ends Aug 14, 2026) |

## Authority & Decision Rights

| Decision Type                       | Authority Level                                        |
| ----------------------------------- | ------------------------------------------------------ |
| Meeting logistics & scheduling      | WG Leads (autonomous)                                  |
| Proposal prioritization within WG   | WG Leads (autonomous)                                  |
| SEP triage & closure (in scope)     | WG Leads (autonomous, with documented rationale)       |
| Technical design within scope       | WG consensus                                           |
| Spec changes (additive)             | WG consensus → Core Maintainer approval                |
| Spec changes (breaking/fundamental) | WG consensus → Core Maintainer approval + wider review |
| Scope expansion                     | Core Maintainer approval required                      |
| WG Member approval                  | WG Member sponsors                                     |

## Membership

| Name               | Organization | GitHub                                               | Discord | Level     |
| ------------------ | ------------ | ---------------------------------------------------- | ------- | --------- |
| David Soria Parra  | Anthropic    | [@dsp-ant](https://github.com/dsp-ant)               |         | Lead      |
| Sam Morrow Drums   | GitHub       | [@SamMorrowDrums](https://github.com/SamMorrowDrums) |         | Lead      |
| Tadas Antanavicius |              | [@tadasant](https://github.com/tadasant)             |         | WG Member |

## Operations

| Meeting         | Frequency | Duration | Purpose                               |
| --------------- | --------- | -------- | ------------------------------------- |
| Working Session | Weekly    | 60 min   | Technical discussion, proposal review |

Discord: [#server-card-wg](https://discord.com/channels/1358869848138059966/1399986204405141534)

## Resources

* Experimental extension repository: [modelcontextprotocol/experimental-ext-server-card](https://github.com/modelcontextprotocol/experimental-ext-server-card)

## Deliverables & Success Metrics

### Active Work Items

| Item                                                                                                | Status | Target Date | Champion                               |
| --------------------------------------------------------------------------------------------------- | ------ | ----------- | -------------------------------------- |
| [SEP-2127: MCP Server Card](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2127) | Draft  | Apr 3, 2026 | [@dsp-ant](https://github.com/dsp-ant) |

### Success Criteria

### Active Work Items

| Item                                    | Status | Target Date | Champion |
| --------------------------------------- | ------ | ----------- | -------- |
| SEP 2127: MCP Server Cards              | Draft  | End March   | @dsp-ant |
| Reference implementation in Tier-1 SDKs | —      | End April   | TBD      |

### Success Criteria

* Spec changes accepted by Core Maintainers.
* SDK implementations available.
* Real-world clients with reach implementing the proposal.
* Real-world servers with reach implementing the proposal.

## Changelog

| Date       | Change          |
| ---------- | --------------- |
| 2026-03-26 | Initial charter |

community/working-groups/skills-over-mcp First recorded · 140 lines, first recorded

# Skills Over MCP Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Authority & Decision Rights ## Membership ## Operations ## Resources ## Deliverables & Success Metrics ### Active Work Items ### Success Criteria ## Changelog

The first capture of this source. The page was already there, and this is what it said.

# Skills Over MCP Charter

> Charter for the MCP Skills Over MCP Working Group.

## Group Type

**Working Group**

## Mission Statement

The Skills Over MCP Working Group defines how "agent skills" — rich, structured
instructions for agent workflows — are discovered, distributed, and consumed through MCP.
Native skills support in host applications demonstrates strong demand, and the group
emerged from discussion on [SEP-2076 — Agent Skills as a First-Class MCP Primitive](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2076),
which raised open questions about whether existing MCP primitives suffice or what
conventions to standardize. The WG produces specification extensions, reference
implementations, and coordination artifacts because solutions touch the protocol spec,
registry schema, SDK implementations, and client behavior. The WG's current direction
is captured in [SEP-2640 — Skills Extension](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2640)
(Resources-based, Extensions Track).

## Scope

### In Scope

* **Specification Work**: SEPs defining how skills are represented, discovered, and
  consumed within MCP — including the Skills Extension (Extensions Track) and related
  protocol changes
* **Reference Implementations**: SDK components and reference servers demonstrating
  skill discovery and consumption patterns
* **Cross-Cutting Concerns**: Coordination with Registry WG (skills discovery/distribution,
  registry schema changes), Agents WG (skill activation, server metadata consumption),
  Primitive Grouping WG (progressive disclosure patterns), and external projects including
  the [Agent Skills](https://agentskills.io/) spec (content format and well-known URI
  discovery), FastMCP, and PydanticAI
* **Documentation**: Specification sections and guidance covering skill authoring,
  discovery, and consumption

### Out of Scope

* **Registry schema decisions**: Schema ownership belongs to the Registry WG; this WG
  contributes requirements but does not own the schema
* **Client implementation mandates**: We can document patterns but not require specific
  client behavior
* **Plugin/bundle packaging**: Installable bundles (skills + servers + subagents +
  configuration as a single artifact) — surfaced by use cases but belongs to a broader
  packaging effort

### Related Groups

* **Agents WG** — How agents consume server metadata, skill activation
* **Registry WG** — Skills discovery/distribution, registry schema changes
* **Primitive Grouping WG** — Progressive disclosure patterns

## Leadership

| Role | Name            | Organization                | GitHub                                   | Term    |
| ---- | --------------- | --------------------------- | ---------------------------------------- | ------- |
| Lead | Ola Hungerford  | Nordstrom / MCP Maintainer  | [@olaservo](https://github.com/olaservo) | Initial |
| Lead | Peter Alexander | Anthropic / Core Maintainer | [@pja-ant](https://github.com/pja-ant)   | Initial |

## Authority & Decision Rights

| Decision Type                       | Authority Level                                        |
| ----------------------------------- | ------------------------------------------------------ |
| Meeting logistics & scheduling      | WG Leads (autonomous)                                  |
| Proposal prioritization within WG   | WG Leads (autonomous)                                  |
| SEP triage & closure (in scope)     | WG Leads (autonomous, with documented rationale)       |
| Technical design within scope       | WG consensus                                           |
| Spec changes (additive)             | WG consensus → Core Maintainer approval                |
| Spec changes (breaking/fundamental) | WG consensus → Core Maintainer approval + wider review |
| Scope expansion                     | Core Maintainer approval required                      |
| WG Member approval                  | WG Member sponsors                                     |

## Membership

| Name                     | Organization                    | GitHub                                                 | Discord | Level       |
| ------------------------ | ------------------------------- | ------------------------------------------------------ | ------- | ----------- |
| Ola Hungerford           | Nordstrom / MCP Maintainer      | [@olaservo](https://github.com/olaservo)               |         | Lead        |
| Peter Alexander          | Anthropic / Core Maintainer     | [@pja-ant](https://github.com/pja-ant)                 |         | Lead        |
| Yu Yi                    | Google                          | [@erain](https://github.com/erain)                     |         | Participant |
| Sunish Sheth             | Databricks                      | [@sunishsheth2009](https://github.com/sunishsheth2009) |         | Participant |
| Keith A Groves           | Hyix                            | [@keithagroves](https://github.com/keithagroves)       |         | Participant |
| Peder Holdgaard Pedersen | Saxo Bank / MCP Maintainer      | [@pederhp](https://github.com/pederhp)                 |         | Participant |
| Sam Morrow               | GitHub                          | [@SamMorrowDrums](https://github.com/SamMorrowDrums)   |         | Participant |
| Jacob MacDonald          | Google                          | [@jakemac53](https://github.com/jakemac53)             |         | Participant |
| Jonathan Hefner          | Independent / MCP Maintainer    | [@jonathanhefner](https://github.com/jonathanhefner)   |         | Participant |
| Luca Chang               | AWS / MCP Maintainer            | [@LucaButBoring](https://github.com/LucaButBoring)     |         | Participant |
| Bob Dickinson            | TeamSpark.ai / MCP Maintainer   | [@BobDickinson](https://github.com/BobDickinson)       |         | Participant |
| Radoslav Dimitrov        | Stacklok / MCP Maintainer       | [@rdimitrov](https://github.com/rdimitrov)             |         | Participant |
| Juan Antonio Osorio      | Stacklok                        | [@JAORMX](https://github.com/JAORMX)                   |         | Participant |
| Kaxil Naik               | Astronomer / Apache Airflow PMC | [@kaxil](https://github.com/kaxil)                     |         | Participant |
| Cliff Hall               | Futurescale                     | [@cliffhall](https://github.com/cliffhall)             |         | Participant |
| Haoyu Wang               | Google                          | [@helloeve](https://github.com/helloeve)               |         | Participant |
| Sambhav Kothari          | Bloomberg / MCP Maintainer      | [@sambhav](https://github.com/sambhav)                 |         | Participant |

## Operations

| Meeting         | Frequency         | Duration   | Purpose                                                                             |
| --------------- | ----------------- | ---------- | ----------------------------------------------------------------------------------- |
| Working Session | Weekly (Tuesdays) | 60 minutes | Technical discussion, pattern evaluation, proposal review; open to all participants |

Default start time is 9:00 AM Pacific. Sessions may occasionally be scheduled earlier to better accommodate non-US time zones.

Meetings are published at [meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io). Agendas are posted in advance per MCP meeting policy. Meeting notes are published to [Meeting Notes — Skills Over MCP WG](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/categories/meeting-notes-skills-over-mcp-wg).

Discord: [#skills-over-mcp-wg](https://discord.com/channels/1358869848138059966/1464745826629976084)

## Resources

* Experimental findings and reference implementations: [modelcontextprotocol/experimental-ext-skills](https://github.com/modelcontextprotocol/experimental-ext-skills)
* Project board: [Skills Over MCP WG](https://github.com/orgs/modelcontextprotocol/projects/38/views/1)

## Deliverables & Success Metrics

### Active Work Items

Full live tracking is on the [Skills Over MCP WG project board](https://github.com/orgs/modelcontextprotocol/projects/38/views/1). Headline workstreams:

| Item                                                                                                              | Status      | Target Date | Champion                                                                                     |
| ----------------------------------------------------------------------------------------------------------------- | ----------- | ----------- | -------------------------------------------------------------------------------------------- |
| [Skills Extension SEP](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2640) (Extensions Track) | In Review   |             | [@pja-ant](https://github.com/pja-ant)                                                       |
| Skills Extension reference implementation                                                                         | In Review   |             | [@olaservo](https://github.com/olaservo)                                                     |
| Agent Skills spec coordination                                                                                    | In Progress |             | [@jonathanhefner](https://github.com/jonathanhefner), [@pja-ant](https://github.com/pja-ant) |
| Registry skills.json proposal                                                                                     | In Progress |             | [@JAORMX](https://github.com/JAORMX)                                                         |

### Success Criteria

* **Short-term**: Documented consensus on requirements and evaluation of existing approaches
* **Medium-term**: Clear recommendation (convention vs. protocol extension vs. both) — the draft Skills Extension SEP represents the WG's current direction: a formal extension using existing Resources primitives
* **Long-term**: Interoperable skill distribution across MCP servers and clients

## Changelog

| Date       | Change                                                                                                                                                                                                                                                                                                           |
| ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 2026-04-25 | Linked SEP-2640 in Active Work Items; added @helloeve (Google) as Participant                                                                                                                                                                                                                                    |
| 2026-04-16 | Converted from Interest Group to Working Group                                                                                                                                                                                                                                                                   |
| 2026-04-14 | Initial charter (formalized from [experimental-ext-skills](https://github.com/modelcontextprotocol/experimental-ext-skills) repo README, which served as the de facto charter before the charter process was established via [SEP-2149](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2149)) |
| 2026-02-01 | IG formed; experimental repo created                                                                                                                                                                                                                                                                             |