What Is an MCP Registry? How Hosted Registries Serve Every AI Client

I built an MCP server for our internal Postgres database in an afternoon. It worked perfectly in Claude Desktop. Then a teammate opened it in Cursor and hit a schema mismatch. Our CI pipeline (running on OpenAI's function-calling API) couldn't parse the tool definitions at all. Our mobile developer, using Gemini, got a third failure mode.

That's the MCP registry problem in a sentence: there's no shortage of MCP servers, but getting them to work across every AI client your team actually uses is a different problem entirely. You don't just need a list. You need a place that hosts the servers, keeps them alive, and speaks every client's protocol.

What an MCP registry actually is

The official Model Context Protocol registry at registry.modelcontextprotocol.io is a metadata index. It lists server names, namespaces, and pointers to packages on npm or GitHub. It doesn't host anything. You still need to install, run, and maintain each server yourself. Think of it as npm's package index, not npm's CDN.

A hosted MCP registry is different. It actually runs the servers. You connect to a URL and the tools are live: authenticated, always-on, already handling the protocol translation. Aerostack is this kind of registry, with 254 MCP servers hosted and served through a single workspace gateway.

The distinction matters because most "MCP marketplace" and "MCP directory" sites are also just metadata. They'll link you to a GitHub repo. From there you're on your own: clone it, configure it, deploy it, keep it running, handle auth. For a single developer experimenting with one tool that's fine. For a team running a dozen integrations it's a maintenance tax that compounds every time a server drifts or a credential rotates.

The multi-client problem no registry solves by default

Claude Desktop, Cursor, VS Code Copilot, Windsurf, and Cline all speak MCP's JSON-RPC protocol natively. A standard MCP server works with all of them without modification. But OpenAI's API expects tool definitions in a completely different envelope: every tool wrapped in { type: "function", function: { name, description, parameters } }. Gemini uses uppercase type names and its own conventions for enums and defaults. Semantically identical tools, but different serialization on every platform.

If you're running separate servers per client, you're maintaining three schema definitions for every tool you add. A parameter rename in your database MCP means three PRs. A bug fix means three deploys. Over a few months with a handful of integrations, that drift becomes invisible debt. I've seen it firsthand: a production OpenAI agent calling a tool with a stale parameter name because someone fixed the MCP source but forgot to regenerate the function-calling wrapper.

The same cross-client friction shows up well beyond IDE tooling. When you're wiring MCP tools into a Slack bot backed by MCP servers — or a Discord integration, or any automated agent pipeline — each platform adds its own tool-dispatch layer on top. You're no longer just bridging Claude and Cursor. You're bridging LLM clients, chat platforms, and REST endpoints, each with slightly different expectations for how tool schemas need to arrive. An MCP registry that handles format translation at the gateway removes all of that from your stack: you define tools once in the registry, and every consumer — IDE, bot, agent, or direct API call — receives the correct envelope for its platform. Maintaining per-client wrappers scales worse than linearly; a central registry layers it flat.

How Aerostack's MCP registry works

When you create a workspace and add MCP servers, those tools become available through the workspace gateway. The gateway serves every tool in three formats from a single URL:

• MCP native: JSON-RPC tools/list for Claude, Cursor, Cline, Continue, Windsurf, VS Code Copilot, and any MCP-compatible client.
• OpenAI function-calling: each tool wrapped in the function envelope that OpenAI's API expects, with the correct parameter schema format.
• Gemini tool definitions: uppercase type names, Gemini's enum conventions, and the specific schema shape Google's API validates.

The MCP servers themselves don't change. You don't maintain three versions of your tool definitions. The workspace gateway handles the translation at request time, with no latency budget impact worth measuring.

Here's a concrete example. Your workspace has a GitHub MCP with a search_code tool. Different clients get the same semantic tool in their native format:

MCP client (Claude / Cursor) receives:

{
  "name": "github-mcp__search_code",
  "description": "Search code across GitHub repositories",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "Search query" },
      "repo": { "type": "string", "description": "owner/repo to scope the search" }
    },
    "required": ["query"]
  }
}

OpenAI API receives:

{
  "type": "function",
  "function": {
    "name": "github-mcp__search_code",
    "description": "Search code across GitHub repositories",
    "parameters": {
      "type": "object",
      "properties": {
        "query": { "type": "string", "description": "Search query" },
        "repo": { "type": "string", "description": "owner/repo to scope the search" }
      },
      "required": ["query"]
    }
  }
}

Gemini API receives:

{
  "name": "github-mcp__search_code",
  "description": "Search code across GitHub repositories",
  "parameters": {
    "type": "OBJECT",
    "properties": {
      "query": { "type": "STRING", "description": "Search query" },
      "repo": { "type": "STRING", "description": "owner/repo to scope the search" }
    },
    "required": ["query"]
  }
}

Same tool. Same semantics. Each client gets the envelope it validates. That's what "publish once" actually means.

Which MCP servers are in the registry

The Aerostack catalog currently lists 254 MCP servers across categories: developer tools (GitHub, GitLab, Linear, Jira), databases (Postgres, Supabase, Snowflake, ClickHouse), communication (Slack, Notion, HubSpot), and cloud (AWS, Azure, GCP). Most are the official upstream servers with Aerostack acting as the mcp server registry layer: handling auth, uptime, and protocol translation so you don't have to.

A few of the most-used servers from the registry:

Registry vs directory: a quick comparison

Setting up your workspace in 60 seconds

I've written the full walkthrough in the workspaces guide, but the short version: create a workspace, pick servers from the catalog, copy the URL, and paste it into your client config.

// Claude Desktop — claude_desktop_config.json
{
  "mcpServers": {
    "aerostack": {
      "url": "https://mcp.aerostack.dev/ws/{your-workspace-id}"
    }
  }
}

For Cursor, Windsurf, and Cline the config is one line per client (they all accept a URL). For the OpenAI API or Gemini API, you hit the workspace URL with a format query parameter. The 60-second workspace setup guide has the client-specific snippets.

What changes when you add or update a server

This is the operational difference I didn't fully appreciate until I'd been running the workspace for a few weeks. When you add a new MCP server to your workspace, every connected client sees it on the next tools/list call. No reconfiguring clients. No redeploying anything.

When you fix a bug in a tool (wrong SQL query structure, missing parameter), every client gets the fix simultaneously. When you rotate credentials, the workspace handles the re-auth and clients keep working. The credentials never sit in any client config. They live in the workspace, encrypted, used by the gateway on behalf of each request.

Compare that to the per-client setup pattern: Claude Desktop has the credentials, Cursor has its own copy, your production app has a third. Rotate a Postgres password and that's three places to update. Miss one and you get a 3 AM incident.

Private MCP registries for teams

Public catalog servers are useful for general tooling. But most teams also have internal MCPs: the kind wrapping a private API, an internal database, or a custom LLM-driven workflow. The workspace gateway supports both public catalog servers and custom MCP endpoints, all served through the same URL. If you're thinking about how to host an MCP server for internal use, the workspace is where it lives after it's built.

Access control is per-workspace. You create a workspace for your engineering team with dev-database tools. A separate workspace for customer-facing agents with read-only tools. Different clients connect to different workspaces, scoped to exactly the tools each context needs.

The MCP registry landscape: where Aerostack fits

It's worth being clear about where Aerostack fits relative to the other MCP registry projects, since the space is moving fast. I find the accordion below useful for orienting teams that ask me which registry to use.

There are valid reasons to run your own MCP servers. If you have a highly customized tool that needs to live on your infra for compliance reasons, self-managed makes sense. If you're experimenting with a new protocol extension that isn't in any registry yet, local is fine.

Where a hosted registry earns its place: when you're running more than two or three integrations, when multiple clients need access, when your team doesn't want to own another service's uptime, or when credential management is starting to feel like a second job. I'd use self-managed for one custom private tool; hosted registry for everything else.

Frequently asked questions about MCP registries

Frequently asked questions