Last week I submitted my first pull requests to the Model Context Protocol ecosystem. Nothing revolutionary—just solid fixes that make the tools work better. But the process taught me more about effective OSS contribution than any guide I'd read.

Here's what I learned.

Finding the Right Issues

The hardest part isn't writing code. It's finding issues worth your time.

I started by using the tools myself. MCP servers, the TypeScript SDK, the inspector—actually building with them. When something broke or felt wrong, I'd check if there was an issue filed. Often there was, sitting there waiting for someone to pick it up.

What to look for:

  • good first issue labels (obvious, but they exist for a reason)
  • Issues with reproduction steps but no PR yet
  • Bug reports where the maintainer has confirmed the problem
  • Things that affect your own workflow

What I avoided: feature requests with bikeshedding debates, anything touching core architecture, issues where maintainers haven't responded in months.

PR #1: Fixing the Empty Object Schema Bug

My first contribution was to modelcontextprotocol/typescript-sdk.

The problem: When you defined an MCP tool with no input parameters, the SDK would generate an empty JSON Schema that OpenAI's strict mode rejected. Tools with no inputs just... didn't work.

How I found it: Issue #1659 had a clear reproduction and a confirmed bug label. The maintainer had acknowledged it but no one had submitted a fix.

The investigation:

I traced through the schema generation code. The issue was in how Zod's .toJSONSchema() handled empty objects. OpenAI's strict mode requires additionalProperties: false on object schemas, but the SDK was generating {} for no-param tools.

The fix was surgical—add explicit handling for the empty case:

// Before: returns {} which OpenAI rejects
// After: returns proper schema with additionalProperties: false
if (Object.keys(schema.properties || {}).length === 0) {
  return {
    type: 'object',
    properties: {},
    additionalProperties: false
  };
}

Total time: About 2 hours including testing. Most of that was understanding the codebase structure.

PR #2: Adding Tool Annotations

The second contribution was to modelcontextprotocol/servers.

The problem: MCP tools can declare hints about their behavior—whether they're read-only, destructive, idempotent, etc. These annotations help AI models make better decisions about tool use. But the fetch server didn't have any.

How I found it: Issue #3572 was a straightforward enhancement request. The spec supported tool annotations, but none of the reference servers used them yet.

The work:

This was more about reading the spec carefully than clever coding:

{
  name: "fetch",
  description: "Fetch a URL and return its contents",
  annotations: {
    readOnly: true,      // doesn't modify anything
    idempotent: true,    // same input = same output
    openWorld: true      // accesses external resources
  },
  inputSchema: { ... }
}

Each annotation required thinking through the tool's actual behavior. Is fetching a URL truly idempotent? (Yes, assuming we're not counting rate limits.) Is it destructive? (No, we're only reading.)

Total time: About an hour. Most of that was reading the annotation spec and thinking through edge cases.

What Actually Matters

Looking back, the successful pattern was:

  1. Use the tools yourself. You can't fix what you don't understand.
  2. Find confirmed issues. Don't waste time on things maintainers haven't acknowledged.
  3. Start small. Both my PRs were under 50 lines of actual changes.
  4. Read before writing. Understanding the codebase structure saves hours of wrong approaches.
  5. Test your changes. Obvious, but I've seen PRs get rejected for breaking existing tests.

The MCP ecosystem is particularly good for first-time contributors right now. It's active, the maintainers are responsive, and there's real demand for improvements. The protocol is being adopted by major AI companies, so your contributions have actual impact.

Getting Started

If you want to contribute to MCP:

  1. Clone the repos and actually use the tools
  2. Check the issue trackers for good first issue or confirmed bugs
  3. Read the MCP specification to understand the protocol
  4. Start with the reference servers—they're simpler than the SDK

The barrier to entry is lower than you think. You don't need to understand the entire protocol to fix a schema generation bug or add missing annotations.

Just find something broken, understand why it's broken, and fix it.

Both PRs are currently in review. I'll update this post when they're merged.

React to this post: