This project follows the MCP SDK Working Group's label conventions (published in SEP-1730). The shared vocabulary lets the MCP ecosystem — and anyone running reports across SDKs — reason consistently about issue state.
Contributors do not need to apply labels when opening an issue or PR; a maintainer will label it during triage. This document exists so everyone understands what the labels mean when they see them.
| Label | Meaning |
|---|---|
bug |
Something isn't working. |
enhancement |
Request for new or expanded functionality. |
question |
Asking for information or clarification. |
When GitHub's native issue types are enabled on the repo, those satisfy the SEP-1730 requirement and these labels are optional.
| Label | Meaning |
|---|---|
needs confirmation |
Unclear whether the issue is still relevant. Often applied to new bug reports until a maintainer can reproduce. |
needs repro |
There isn't enough information to reproduce the problem. Reporter follow-up required. |
ready for work |
Triaged; enough information to start implementing. |
good first issue |
Scoped small enough that a newcomer can reasonably take it on. |
help wanted |
Contributions welcome from anyone familiar with the codebase. |
These labels are applied to actionable work — confirmed bugs or
well-scoped enhancements — not to questions or needs repro items.
| Label | Meaning |
|---|---|
P0 |
Critical. Core-functionality failure preventing basic MCP operations (connect, message exchange, tools / resources / prompts). Or a security vulnerability with CVSS ≥ 7.0. |
P1 |
Significant bug affecting many users, or a high-value feature gap. |
P2 |
Moderate issue or worthwhile feature request. |
P3 |
Nice-to-have. Rare edge case or minor polish. |
Note: P0 response expectations are discussed in SECURITY.md and in the roadmap's tier self-assessment (ROADMAP.md). The SEP-1730 Tier 1 target is seven days to resolution; we are working toward that but do not commit to it yet — see the roadmap for the full context.
Beyond the SEP-1730 scheme, maintainers may apply area labels to help with routing. These are advisory only.
| Example label | Rough area |
|---|---|
area:transport |
src/Client/Transport/ or src/Server/Transport/ |
area:auth |
OAuth on either side of the wire |
area:conformance |
The conformance harness and baseline |
area:webclient |
The webclient/ reference implementation |
area:docs |
Anything under docs/ or repo-root Markdown |
New area labels may be added as the project grows.
Triagers may change a label at any time — for example, reclassifying a
question as a bug once it turns out the SDK is genuinely
misbehaving, or lowering a P1 to P2 as scope becomes clearer. That is
normal and does not reflect on the reporter.