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:

  1. Where does the error occur?
  2. What function called that?
  3. 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:

  1. What the problem was
  2. What caused it
  3. How you fixed it
  4. 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:

  1. Found it: Using the SDK, my custom scope was being ignored
  2. Investigated: Traced through oauth_auth.py, found the issue in async_auth_flow
  3. Root cause: The flow was overwriting client_metadata without preserving existing scope
  4. Fix: Check if scope is already set before applying defaults
  5. PR: Linked issue, explained the problem, added test case
  6. 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.

React to this post: