# Connecting and Governing MCP Servers: Registries, Gateways, and Tool Sprawl

> As MCP servers multiply, discovery, trust, and tool sprawl become the problem. How registries, gateways, and curation keep a growing fleet secure and usable.

One MCP server is easy; twenty is a governance problem: discovery (which servers exist and are trustworthy), tool sprawl (too many tools bloat context and confuse the model), and security (every third-party server is supply-chain risk). Registries solve discovery, gateways add a control point for auth and tool filtering, and curation keeps the tool list small and sharp.

The pitch for MCP is decoupling: [write a server once](/guides/advanced/building-an-mcp-server) and any client can use it. That pitch works beautifully for the first server, and the fifth. By the twentieth — internal servers, vendor servers, community servers, each exposing a handful of tools — the very thing that made MCP easy becomes the thing you have to manage. Connecting servers is solved. **Governing** them is the actual job: which servers exist and can you trust them, how many tools is too many, and who is allowed to plug what into your agents.

## The three problems that show up at scale

1. **Discovery and trust.** Where do servers come from? A URL in a README is not provenance. You need to find servers, know who published them, and pin a known-good version.
2. **Tool sprawl.** Every connected server adds tools to the model's list, and every tool costs context and competes for the model's attention. Twenty servers can mean a hundred tools the model has to read past to find the right one — slower, pricier, and more error-prone.
3. **Security surface.** Each server is code you're running and credentials you're handing out. A careless or malicious server is a data-exfiltration or harmful-action path. More servers, wider surface.

Registries address the first, gateways the second and third, and curation ties them together.

## Registries: solving discovery and provenance

A **registry** is a catalog of MCP servers you can search, evaluate, and install from — the difference between "I found a gist" and "I installed a known server at a pinned version."

- **The official MCP Registry** provides an open, standard catalog with provenance, so clients and tools can discover servers programmatically rather than by word of mouth.
- **[Smithery](/tools/smithery)** and similar platforms add a curated registry on top of discovery — often with hosting and one-command installation — so you can go from "I need a Postgres server" to a running, versioned connection quickly.
- **Vendor registries** let an organization publish an internal catalog of approved servers, which is how you give developers a paved road instead of a free-for-all.

The governance win is **provenance and pinning**: know who published a server, and depend on a specific version you've vetted rather than whatever `latest` becomes tomorrow.

## Gateways: a single control point

A **gateway** sits between your clients and your MCP servers and presents many servers through one governed entry point. Instead of configuring auth, limits, and allow-lists in every client, you enforce them **once** at the gateway:

- **Central authentication** — clients authenticate to the gateway; the gateway holds the credentials to the upstream servers.
- **Allow-listing** — which servers and which tools are reachable at all, decided centrally.
- **Tool filtering and namespacing** — expose only the tools that matter, and rename to avoid collisions when two servers both ship a `search` tool.
- **Rate limiting and quotas** — protect upstreams and bound cost.
- **Audit logging** — one place that records who called which tool with what arguments, which is what makes an MCP fleet auditable at all.

> [!TIP]
> A gateway is also the cleanest place to fight tool sprawl: rather than connecting ten servers directly to every agent, point agents at the gateway and let it expose a curated, task-appropriate slice of tools. The model sees a short, sharp list; the full fleet stays available behind the gateway.

## Curation: treat the tool list as scarce

Even with registries and a gateway, the highest-leverage habit is **not exposing everything**. The model's tool list is a budget. Each tool you add:

- consumes context (its name, description, and schema are in the prompt), and
- adds a wrong option the model can pick.

So scope tools to the task. An agent that triages issues needs the issue tools, not your deploy tools and your analytics tools too. Connect servers per-agent or per-workflow, prune what's unused, and periodically read your own tool list the way the model does — if *you* can't tell which tool to use from the names alone, neither can the model.

## Security: every server is supply chain

A connected MCP server runs code and is trusted with credentials and tool access. That makes the fleet a supply-chain problem:

- **Vet provenance.** Prefer open, audited servers from known publishers; a registry with provenance beats a random repo.
- **Pin versions.** Depend on a specific, reviewed version, not `latest`.
- **Least-privilege credentials.** Scope every token to the minimum the server needs; assume a server can do anything its credentials allow.
- **Require approval to add.** In shared projects, adding a server should be a reviewed action, not a silent config change. (Claude Code already prompts each teammate to approve a project-scoped server from `.mcp.json` before its tools activate.)
- **Isolate where you can.** Run untrusted servers with constrained network and filesystem access.

> [!WARNING]
> A malicious MCP server doesn't need an exploit — it just needs to be *connected*. If it's handed a token and a tool surface, it can use them. The defenses are organizational as much as technical: provenance, pinning, least privilege, and an approval gate before anything joins the fleet.

## Putting it together

At one server, you connect. At twenty, you **govern**: a registry for discovery and provenance, a gateway for central auth, allow-listing, audit, and tool filtering, and a discipline of curating the tool list down to what each task needs. Do that and MCP's "plug in everywhere" stays an asset instead of becoming an unbounded, unaudited attack surface.

To build and harden the servers themselves, see the [mcp-server-engineer](/agents/developer-tools/mcp-server-engineer); to deploy one remotely and at scale, [Deploying a Remote MCP Server](/guides/mcp/deploy-remote-mcp-server); and to add one to a project the safe way, the [Add MCP Server](/commands/workflow/add-mcp-server) command.

---

_Source: https://agentscamp.com/guides/mcp/govern-mcp-servers — Guide on AgentsCamp._