Log inGet started
← Level 4
Level 4· Lektion 6 von 11

MCP discovery, how servers are found

Directories, marketplaces, .well-known/mcp. How the MCP ecosystem actually works.

Why this is its own lesson

You know what MCP is, how to set up servers, and how memory is portable. What's missing: where do you find good servers? And when you build your own in Level 6, how does anyone find it?

The three directories that matter

1. modelcontextprotocol.io (spec + reference servers), the official spec site, with a curated list of reference servers at github.com/modelcontextprotocol/servers. Not a classic listing directory, but the source the spec and Anthropic's own docs point to.

2. Claude Connectors (in Claude Desktop + claude.ai), built-in connector lists from 2026. One-click install, pre-configured OAuth.

3. MCPize Marketplace (mcpize.com), commercial, specialized in hosted HTTP servers.

Alongside there are community lists on GitHub (modelcontextprotocol/servers and awesome-mcp-servers).

The protocol under the hood, RFC 9728

For a while there was a rumor about a .well-known/mcp endpoint. It doesn't exist. What the official MCP spec (state 2025-06-18) actually defines is /.well-known/oauth-protected-resource per RFC 9728, OAuth Protected Resource Metadata. That's the discovery mechanism for HTTP MCP servers secured with OAuth 2.1.

When a client hits your MCP server domain, it asks for OAuth metadata first:

https://your-domain.com/.well-known/oauth-protected-resource

Response is JSON per RFC 9728:

{
  "resource": "https://your-domain.com/mcp",
  "authorization_servers": [
    "https://your-domain.com"
  ],
  "scopes_supported": ["mcp:tools"],
  "bearer_methods_supported": ["header"]
}

The client now knows the authorization server, runs the OAuth 2.1 flow with PKCE, and then talks to the actual MCP endpoint (/mcp) with a bearer token.

Current spec version is 2025-06-18. Earlier drafts (2024-11-05, 2025-03-26) are obsolete. Building a .well-known/mcp endpoint means building something no client will ever fetch.

Stdio servers (npm) vs HTTP servers (discovery)

Stdio servers run locally with the user (npx -y my-server). Discovery via npm + docs + directory listing.

HTTP servers run centrally. Should expose .well-known/mcp so users only type the domain.

For publishers, where to list

When you build your own MCP server in Level 6, discovery is half the battle:

  • npm publish (10 minutes)
  • GitHub README + awesome-mcp-servers PR (30 minutes)
  • modelcontextprotocol/servers pull request (GitHub PR to the official reference list, a few days of review)
  • MCPize Marketplace (1 hour setup)
  • Claude Connector (submission + Anthropic review)

Practice, two servers to look at

  1. Sequential Thinking (Anthropic, stdio + npm).
  2. Brave Search MCP (stdio + npm).

Both have READMEs that exemplify how to document MCP servers.

What you have now

The ecosystem picture. As a user you know where to find servers. As a future publisher you know where to put yours.

Update 2026-04-28: hook bundles as a distribution class

With Claude Code v2.1.118 (type: "mcp_tool" hooks, see Lesson 10), a new distribution class emerges: hook-recipe plugins. Instead of publishing a whole MCP server, users publish pre-configured hook bundles for existing servers (Memory, CRM, GEO, etc.). One claude plugin install studiomeyer-memory-hooks and the user has all 4 Memory hooks active without manually editing settings.json.

Marketplaces like studiomeyer-marketplace list these alongside MCP servers. Each plugin needs: plugin.json, README.md with idempotency check + GDPR note, tests/ with smoke test. The five bundles for our SaaS MCPs are recipes in Phase 16 (/recipes/16.1-mcp-tool-hook-intro through 16.5-academy-hook-bundle). Copy-paste them into settings.json today, plugin packaging is in the pipeline.

Sources

You're reading without an account. Login saves your progress so you can pick up where you left off. Log in →
← Same memory, three tools. ClauCapstone, your portable memory→