DEV Community

Tracepilot
Tracepilot

Posted on

The MCP Server Directory Problem Nobody's Talking About

#ai #debugging #python

The MCP Server Directory Problem Nobody's Talking About

Here's what's breaking: you built an MCP server. It works. You want people to find it. But discovery is a mess.

GitHub search returns 47 pages of random repos. Twitter threads get buried. Discord channels scroll past in hours. Your server sits in a repo with 3 stars and zero users.

This sucks. I know. I've been there.

Why Discovery Matters (And Why It's Broken)

MCP (Model Context Protocol) is growing fast. Every week there's a new server for databases, APIs, file systems, you name it. But the ecosystem is fragmented.

Here's the technical reality:

  • No centralized registry exists
  • GitHub topics are inconsistent (mcp-server, mcp-server-tool, mcp)
  • Package managers don't index MCP servers specifically
  • Search engines return noise, not signal

Guess what happens next? Developers waste hours finding the right server. Or worse — they build one that already exists.

The Manual Fix: What You'd Do Without a Directory

Let's say you want to find an MCP server for PostgreSQL. Here's your workflow:

# Step 1: Search GitHub
gh search repos "mcp postgresql" --limit 50

# Step 2: Manually inspect each repo
# Check README, check if it's active, check if it works with your stack

# Step 3: Try to install
npx @modelcontextprotocol/server-postgres

# Step 4: It fails. No docs. No examples. Back to step 1.
Enter fullscreen mode Exit fullscreen mode

Sound familiar? You've spent 30 minutes and found maybe 3 viable servers.

Or if you're submitting your own server:

# Create a GitHub repo
# Write docs
# Post on Hacker News
# Tweet about it
# Pray someone finds it
Enter fullscreen mode Exit fullscreen mode

That's not a workflow. That's a gamble.

The Real Fix: A Directory That Actually Works

mcp.so is trying to solve this. They're building a curated directory of MCP servers. The idea is simple: one place to find and submit servers.

Here's how you submit yours right now:

1. Go to the GitHub issue

URL: https://github.com/chatmcp/mcpso/issues/1

2. Leave your server link 

## My MCP Server

**Name:** postgres-mcp  
**Description:** MCP server for PostgreSQL databases with schema introspection and query execution  
**Link:** https://github.com/yourname/postgres-mcp  
**Category:** Database  
**Stack:** Node.js, PostgreSQL
Enter fullscreen mode Exit fullscreen mode

3. Wait for it to appear

The maintainers review and add it to the directory.

That's it. No API. No auth. Just a GitHub issue.

Why This Pattern Works (And When It Doesn't)

The GitHub issue submission pattern has tradeoffs:

Pros:

  • Low friction — anyone with a GitHub account can submit
  • Transparent — you can see all submissions
  • Community vetted — issues get comments, feedback

Cons:

  • Manual review — takes time
  • No automation — no CI/CD, no validation
  • Scales poorly — 1000 servers = 1000 issues

For a v1, it's fine. For production, you'd want something better.

What I'd Build Instead

If I were building this, here's what the submission flow would look like:

// mcp-directory/submit.ts
interface MCPServerSubmission {
  name: string;
  description: string;
  repository: string;       // GitHub URL
  packageName?: string;     // npm package
  category: 'database' | 'api' | 'filesystem' | 'ai' | 'other';
  stack: string[];          // ['node', 'python', 'go']
  mcpVersion: string;       // '2024-11-05'
  tools: string[];          // ['query', 'introspect', 'migrate']
  verified: boolean;        // Auto-verified via GitHub Actions
}

async function submitServer(submission: MCPServerSubmission) {
  // 1. Validate the repository exists
  const repo = await validateGitHubRepo(submission.repository);

  // 2. Check if it actually implements MCP
  const mcpConfig = await fetchMCPSchema(submission.repository);

  // 3. Run basic tests
  const testResults = await runMCPServerTests(mcpConfig);

  // 4. Submit to directory
  const entry = await createDirectoryEntry({
    ...submission,
    verified: testResults.passed,
    submittedAt: new Date().toISOString()
  });

  return entry;
}
Enter fullscreen mode Exit fullscreen mode

But that's overengineering for a v0. The GitHub issue works. Use it.

How TracePilot Fits (Yes, There's a Connection)

You're building MCP servers. They call LLMs. Those LLM calls fail in weird ways.

TracePilot captures every LLM call in your MCP server — input, output, tokens, latency. When something breaks, you fork the execution at the exact step and replay with a fix.

// Your MCP server + TracePilot
import { TracePilot } from 'tracepilot-sdk';

const tp = new TracePilot(process.env.TRACEPILOT_API_KEY);

server.tool('query-database', {
  // ... schema
}, async (args) => {
  return await tp.wrapOpenAI(
    () => llm.generateSQL(args.question),
    [{ role: 'user', content: args.question }]
  );
});
Enter fullscreen mode Exit fullscreen mode

Your MCP server gets discovered on mcp.so. Your LLM calls get debugged with TracePilot. Two problems, one afternoon.

Go Submit

Submit your MCP server here. Leave the link. Get visibility.

And while you're at it, add TracePilot to your server. You'll thank me when it breaks at 2 AM.

Debugging AI agents shouldn't feel like reading The Matrix.
Join other engineers who are building reliable autonomous workflows in our community: TracePilot Discord

Top comments (0)