|
2 | 2 |
|
3 | 3 | We welcome contributions to the Model Context Protocol TypeScript SDK! This document outlines the process for contributing to the project. |
4 | 4 |
|
| 5 | +## Before You Start |
| 6 | + |
| 7 | +### Bug Fixes |
| 8 | + |
| 9 | +Bug fixes are welcome! For straightforward bugs, feel free to open a PR directly. For complex bugs that require significant changes, consider opening an issue first to discuss the approach. |
| 10 | + |
| 11 | +### New Features and Enhancements |
| 12 | + |
| 13 | +**Please open an issue before starting work on new features or significant enhancements.** This means having an actual discussion and getting alignment—not just opening an issue moments before submitting a PR. |
| 14 | + |
| 15 | +We will close pull requests for features that weren't previously discussed, regardless of the effort invested. This isn't because we don't appreciate the contribution—it's because code is cheap to produce but expensive to maintain, and every merged feature creates long-term maintenance burden. PRs are not the place to iterate on ideas; that's what issues are for. |
| 16 | + |
| 17 | +What counts as "significant"? |
| 18 | + |
| 19 | +- New public APIs or classes |
| 20 | +- Architectural changes or refactoring |
| 21 | +- Changes that touch multiple modules |
| 22 | +- Features that might require spec changes (these need a [SEP](https://github.com/modelcontextprotocol/modelcontextprotocol) first) |
| 23 | + |
| 24 | +### Writing Effective Issues |
| 25 | + |
| 26 | +Good issues are clear and concise: |
| 27 | + |
| 28 | +- State the problem directly |
| 29 | +- Include a minimal reproducible example when applicable |
| 30 | +- Skip unnecessary background—get to the point |
| 31 | + |
| 32 | +Issues that appear to transfer burden to maintainers without effort to validate the problem will be closed. LLM-generated issues that are clearly low-effort will be closed immediately. |
| 33 | + |
| 34 | +### Good Candidates for Contribution |
| 35 | + |
| 36 | +Issues labeled [`good first issue`](https://github.com/modelcontextprotocol/typescript-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) or [`help wanted`](https://github.com/modelcontextprotocol/typescript-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) are great places to start. Issues labeled [`ready for work`](https://github.com/modelcontextprotocol/typescript-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22ready+for+work%22) have been triaged and are ready for implementation. |
| 37 | + |
| 38 | +Issues labeled `needs confirmation` or `needs maintainer action` are **not** good candidates—please wait for maintainer input before starting work on these. |
| 39 | + |
| 40 | +### Pull Request Scope |
| 41 | + |
| 42 | +Keep PRs focused and small. A PR that changes 50 lines across 3 files can be reviewed in minutes. A PR that changes 500 lines across 20 files requires hours of careful analysis, creates review bottlenecks, and often hides issues. |
| 43 | + |
| 44 | +If your change is large, consider breaking it into smaller, incremental PRs. |
| 45 | + |
| 46 | +### What Gets Rejected |
| 47 | + |
| 48 | +PRs may be rejected for: |
| 49 | + |
| 50 | +- **Lack of prior discussion** — Features or significant changes without an approved issue |
| 51 | +- **Scope creep** — Changes that go beyond what was discussed or add unrequested features |
| 52 | +- **Misalignment with SDK direction** — Even well-implemented features may be rejected if they don't fit the SDK's goals |
| 53 | +- **Insufficient quality** — Code that doesn't meet clarity, maintainability, or style standards |
| 54 | +- **Overengineering** — Unnecessary complexity or abstraction for simple problems |
| 55 | + |
5 | 56 | ## Getting Started |
6 | 57 |
|
7 | 58 | 1. Fork the repository |
|
0 commit comments