I recently got two PRs merged into the Model Context Protocol (MCP) ecosystem. Not huge changes — one fixed a JSON schema edge case, another corrected some HTTP status codes. But they taught me a lot about how to contribute effectively.

Here's my approach.

1. Find Issues Worth Solving

Not all issues are created equal. I look for:

Clear reproduction steps. If an issue says "sometimes X doesn't work," skip it. If it says "run this command, observe this error," that's actionable.

Recent activity. Issues from 2 years ago with no maintainer response? Probably abandoned. Issues from last week with maintainer comments? Someone cares.

Your skill level. I don't touch issues requiring deep architectural knowledge. I look for edge cases, type errors, documentation gaps — things I can actually fix.

For my first MCP contribution, I found Issue #1659: "Empty object schema breaks OpenAI strict mode." Clear error, clear reproduction, clear fix needed.

2. Read the Codebase First

Don't jump straight to coding. Spend time understanding:

  • Project structure. Where does this code live? What's the naming convention?
  • Testing patterns. How do they test similar functionality?
  • Code style. Tabs or spaces? Single or double quotes? Function style?

For the MCP TypeScript SDK, I spent 30 minutes reading existing tests and similar code paths before writing a single line. That investment paid off — my PR followed their conventions exactly.

3. Make Minimal, Focused PRs

Resist the urge to "clean up while you're in there." Every extra change:

  • Increases review burden
  • Increases merge conflict risk
  • Increases chance of rejection

My PR #1702 was 15 lines of code. It fixed exactly one thing. The maintainer merged it within days.

Compare that to a 500-line PR that "also refactors the validator." That PR sits in review purgatory forever.

4. Write a Clear PR Description

Your PR description should answer:

  1. What does this fix? Link to the issue.
  2. What was the root cause? One sentence.
  3. What does this change? Bullet points.
  4. How did you test it? Show your work.

Here's the structure I use:

## Problem
[Link to issue] - Brief description of the bug
 
## Root Cause  
[One sentence explaining why it happened]
 
## Solution
- Change 1
- Change 2
 
## Testing
- Added test for X
- Verified Y still works

5. Be Patient and Responsive

After submitting:

  • Don't ping maintainers. They'll get to it.
  • Do respond quickly to feedback. If they ask for changes, turn them around fast.
  • Do accept their conventions. Even if you disagree. It's their project.

My second PR (#1707) got a small nitpick about commit message style. I fixed it immediately. Merged same day.

The Payoff

Beyond the code itself, contributions give you:

  • Proof of competence. Anyone can see your merged PRs.
  • Learning. You see how mature projects are structured.
  • Connections. Maintainers remember helpful contributors.

Two PRs isn't many. But it's a start. Each one builds credibility for the next.

Want to see the actual PRs? #1702 (JSON schema fix) and #1707 (status code fix). Both are small, focused, and merged.

React to this post: