modelcontextprotocol organization.
To build with MCP, start with the server and client guides, the SDK list or the MCP Registry.
If you want to invest some time in our discussions, the protocol work is organized in working groups and interest groups. Their meetings are open to anyone and are listed on meet.modelcontextprotocol.io. Meetings and channels sets out how a meeting is announced and minuted. No invitation or role is needed to attend or speak at a meeting, to comment on a pull request, or to open an issue or a discussion.
These same working groups and interest groups are represented in the Discord space.
Where to start
1
Join Discord
Contributors talk about the protocol on Discord.
2
Find your group
Pick the working group or Discord channel that covers your area. If none fits, use
#general.The specification repository also labels issues good first issue and help wanted when they are sized for a first change.The sections below cover each kind of change.3
Talk to the lead
Each group’s page names its leads. Post what you want to work on in the group’s channel.
Report a problem
Report a vulnerability in private. For a bug, typo or unclear text in the specification or these docs, open an issue. For an SDK or tool, open it in that repository. Please don’t post usage questions in the repositories. We stopped taking them there because of spam.Change the specification or docs
You need write access to open a pull request on the specification repository. We prefer you begin with an issue and follow the steps for a bug below.1
Raise the change
Report a bug in an issue. Raise anything else in your group’s channel or
#general.2
Push a branch
Push to a fork, or to a working group repository you can write to. Specification fixes go in
draft/. Keep each change to one concern. CONTRIBUTING.md covers setup and checks.3
Ask for a pull request
Link the branch in that issue or channel and ask a maintainer to open a pull request that credits you.
Work on an SDK or tool
Inspector and the reference servers accept issues only.1
Read the contributing guide
Each repository sets its own rules, and some close pull requests that have no assigned issue. If a repository has no guide, ask in its channel, such as
#python-sdk-dev.2
Pick an issue
Look for
good first issue or help wanted, or open a new one. Ask to be assigned if the guide requires it.3
Open a pull request
For anything larger than a small bug fix, agree on the approach in the issue before you write code.
Propose a protocol change
Protocol changes go through a SEP. Bug fixes and clarifications do not need one.1
Discuss the idea
Raise it in your group’s channel. The SEP pull request must link to that discussion.
2
Build a prototype
See Prototype Requirements. Consider shipping the idea as an extension where its shape allows.
3
Find a sponsor
See Sponsors.
4
Write the SEP
Follow the workflow. Without write access, ask your sponsor to open the pull request.
Other ways to help
- Review open SEPs and draft specification pull requests.
- Reproduce reported bugs.
- Test SDK release candidates against the draft specification.
- Write conformance scenarios. A Standards Track SEP with observable protocol behavior needs one to reach Final.
Growing your role
To take on a bigger role, see the Contributor Ladder. Governance covers who decides what, and MAINTAINERS.md lists the current maintainers.Ground rules
- The Code of Conduct applies in every repository, channel and meeting.
- Disclose any AI assistance in the pull request or issue.
- AI agents must follow AGENTS.md, which limits when they can open issues and pull requests.
- Contributions are licensed under Apache-2.0 for code and specifications and CC-BY-4.0 for other documentation.