I've been contributing to the MCP ecosystem lately. Here's the process I've developed for finding and fixing issues.
Finding Issues
I don't randomly browse issue trackers. I look for:
Issues I've hit myself. Best motivation, and I already understand the problem.
Recent issues with clear reproduction. Someone did the hard work of explaining the bug. I just need to fix it.
Good first issues that aren't trivial. Avoid issues that are just typo fixes—look for ones with actual engineering work.
Issues in projects I use. Familiarity with the codebase matters.
Before Writing Code
The temptation is to jump straight to coding. Resist it.
Read the Existing Code
Understand how the project is structured. Find similar functionality. See how they handle edge cases.
30 minutes of reading saves hours of rework.
Check for Prior Art
Has anyone tried to fix this before? Search closed PRs and issues. You might find:
- A previous attempt that was rejected (and why)
- Related discussion that changes the approach
- Someone already working on it
Reproduce the Issue
If you can't reproduce it, you can't verify your fix. Build a minimal test case.
The Investigation
This is where most of the work happens.
Trace the Code Path
Start from the symptom and work backward:
- Where does the error occur?
- What function called that?
- What's the expected vs actual state?
For a recent MCP SDK issue, I traced an OAuth scope bug through three files before finding where the value was being incorrectly overwritten.
Form a Hypothesis
Before changing anything, have a clear theory:
- "The scope is being overwritten because X"
- "Adding a check for Y should fix it"
If you can't articulate the hypothesis, you don't understand the problem yet.
Test the Hypothesis
Make the minimal change that tests your theory. Does it fix the issue? Does it break anything else?
Writing the Fix
Keep It Small
Fix one thing. If you find other issues along the way, open separate PRs.
Small PRs get reviewed faster and merged more often.
Match the Style
Use the project's conventions:
- Formatting
- Naming
- Test structure
- Commit message format
Don't make reviewers think about style—let them focus on logic.
Add Tests
If the project has tests, add them. Test both:
- The fix (does it solve the problem?)
- Regression (does it break existing behavior?)
PRs with tests get merged faster.
Write a Good PR Description
Include:
- What the problem was
- What caused it
- How you fixed it
- How to test it
Link to the issue. Add context that helps reviewers.
After Submitting
Respond Quickly
When maintainers comment, respond within 24 hours if possible. Stale PRs get forgotten.
Be Open to Feedback
Maintainers know their codebase better than you. If they suggest changes:
- Understand why
- Ask questions if unclear
- Make the changes promptly
Don't Take Rejection Personally
Sometimes PRs get closed. Maybe:
- The approach doesn't fit the project direction
- There's a better solution planned
- The issue is actually by design
Thank them for the review and move on.
My Checklist
Before submitting:
- Issue is clearly understood and reproduced
- Change is minimal and focused
- Tests added/updated
- Code matches project style
- PR description is complete
- CI passes
- No unrelated changes
Real Example
Recently I fixed an OAuth scope issue in the MCP Python SDK:
- Found it: Using the SDK, my custom scope was being ignored
- Investigated: Traced through
oauth_auth.py, found the issue inasync_auth_flow - Root cause: The flow was overwriting
client_metadatawithout preserving existing scope - Fix: Check if scope is already set before applying defaults
- PR: Linked issue, explained the problem, added test case
- Submitted: Waiting for review
Total time: about 2 hours from discovery to PR.
The Payoff
Good OSS contributions:
- Build reputation in the community
- Teach you how quality projects are built
- Often lead to more opportunities
- Help projects you care about
Start with projects you use. Fix problems you hit. Build from there.