You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+82-17Lines changed: 82 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,8 +1,53 @@
1
1
# Contributing to MCP TypeScript SDK
2
2
3
-
We welcome contributions to the Model Context Protocol TypeScript SDK! This document outlines the process for contributing to the project.
3
+
Welcome, and thanks for your interest in contributing! We're glad you're here.
4
4
5
-
## Branches
5
+
This document outlines how to contribute effectively to the TypeScript SDK.
6
+
7
+
## Issues
8
+
9
+
### Discuss Before You Code
10
+
11
+
**Please open an issue before starting work on new features or significant changes.** This gives us a chance to align on approach and save you time if we see potential issues.
12
+
13
+
We'll close PRs for undiscussed features—not because we don't appreciate the effort, but because every merged feature becomes an ongoing maintenance burden for our small team of maintainers. Talking first helps us figure out together whether something belongs in the SDK.
14
+
15
+
Straightforward bug fixes (a few lines of code with tests demonstrating the fix) can skip this step. For complex bugs that need significant changes, consider opening an issue first.
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://modelcontextprotocol.io/community/sep-guidelines) first)
23
+
24
+
### Writing Good Issues
25
+
26
+
Help us help you:
27
+
28
+
- Lead with what's broken or what you need
29
+
- Include code we can run to see the problem
30
+
- Keep it focused—a clear problem statement goes a long way
31
+
32
+
We're a small team, so issues that include some upfront debugging help us move faster. Low-effort or obviously AI-generated issues will be closed.
|[`good first issue`](https://github.com/modelcontextprotocol/typescript-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)| Newcomers | Can tackle without deep codebase knowledge |
39
+
|[`help wanted`](https://github.com/modelcontextprotocol/typescript-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)| Experienced contributors | Maintainers probably won't get to this |
40
+
|[`ready for work`](https://github.com/modelcontextprotocol/typescript-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22ready+for+work%22)| Maintainers | Triaged and ready for a maintainer to pick up |
41
+
42
+
Issues labeled `needs confirmation`, `needs repro`, or `needs design` are **not** ready for work—wait for maintainer input before starting.
43
+
44
+
Before starting work, comment on the issue so we can assign it to you. This lets others know and avoids duplicate effort.
45
+
46
+
## Pull Requests
47
+
48
+
By the time you open a PR, the "what" and "why" should already be settled in an issue. This keeps PR reviews focused on implementation rather than revisiting whether we should do it at all.
49
+
50
+
### Branches
6
51
7
52
This repository has two main branches:
8
53
@@ -14,7 +59,33 @@ This repository has two main branches:
14
59
- For **new features** or **v2-related work**: base your PR on `main`
15
60
- For **v1 bug fixes** or **patches**: base your PR on `v1.x`
16
61
17
-
## Getting Started
62
+
### Scope
63
+
64
+
Small PRs get reviewed fast. Large PRs sit in the queue.
65
+
66
+
We can review a few dozen lines in a few minutes. But a PR touching hundreds of lines across many files takes real effort to verify—and things inevitably slip through. If your change is big, break it into a stack of smaller PRs or get clear alignment from a maintainer on your approach in an issue before submitting a large PR.
67
+
68
+
### What Gets Rejected
69
+
70
+
PRs may be rejected for:
71
+
72
+
-**Lack of prior discussion** — Features or significant changes without an approved issue
73
+
-**Scope creep** — Changes that go beyond what was discussed or add unrequested features
74
+
-**Misalignment with SDK direction** — Even well-implemented features may be rejected if they don't fit the SDK's goals
75
+
-**Insufficient quality** — Code that doesn't meet clarity, maintainability, or style standards
76
+
-**Overengineering** — Unnecessary complexity or abstraction for simple problems
77
+
78
+
### Submitting Your PR
79
+
80
+
1. Follow the existing code style
81
+
2. Include tests for new functionality
82
+
3. Update documentation as needed
83
+
4. Keep changes focused and atomic
84
+
5. Provide a clear description of changes
85
+
86
+
## Development
87
+
88
+
### Getting Started
18
89
19
90
This project uses [pnpm](https://pnpm.io/) as its package manager. If you don't have pnpm installed, enable it via [corepack](https://nodejs.org/api/corepack.html) (included with Node.js 16.9+):
20
91
@@ -30,23 +101,15 @@ Then:
30
101
4. Build the project: `pnpm build:all`
31
102
5. Run tests: `pnpm test:all`
32
103
33
-
##Development Process
104
+
### Workflow
34
105
35
106
1. Create a new branch for your changes (based on `main` or `v1.x` as appropriate)
36
107
2. Make your changes
37
108
3. Run `pnpm lint:all` to ensure code style compliance
38
109
4. Run `pnpm test:all` to verify all tests pass
39
110
5. Submit a pull request
40
111
41
-
## Pull Request Guidelines
42
-
43
-
- Follow the existing code style
44
-
- Include tests for new functionality
45
-
- Update documentation as needed
46
-
- Keep changes focused and atomic
47
-
- Provide a clear description of changes
48
-
49
-
## Running Examples
112
+
### Running Examples
50
113
51
114
See [`examples/server/README.md`](examples/server/README.md) and [`examples/client/README.md`](examples/client/README.md) for a full list of runnable examples.
52
115
@@ -102,20 +165,22 @@ v1.x releases are published with `release-X.Y` npm tags (e.g., `release-1.25`),
0 commit comments