Where to find and publish MCP servers in 2026

The fastest way to bootstrap an agent in 2026 is to pull a ready-made integration from an mcp server directory rather than hand-rolling OAuth and API wrappers. But the ecosystem has fragmented into a dozen overlapping lists, registries, and package feeds, each with different trust and versioning models.

Where MCP servers actually live

If you need a Postgres reader or a GitHub issue tracker, start with the official Model Context Protocol GitHub org. It maintains a curated servers repository that links to first-party and community implementations. That repo is the original mcp server directory, but it is deliberately conservative: submissions require a human review and a security checklist before they land in the main branch.

For breadth, Smithery and the community-run mcp-registry JSON feed index hundreds of packages with semantic versioning and download counts. Those indexes trade curation for coverage. A typical client config that pulls from any of these looks identical because the protocol is transport-agnostic:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "postgres://localhost:5432/app" }
    }
  }
}

The key is that the directory only gives you a pointer. The client resolves the package, spawns the process, and negotiates capabilities over stdio or HTTP. Do not assume the directory runs any code; it is a coordinate system, not a runtime.

Evaluating a server before you trust it

Never pipe production credentials into a server you haven’t read. The biggest pitfall in 2026 is the “transitive MCP” pattern: a directory listing links to a wrapper that depends on three other unpublished packages.

Check these four things:

1. Manifest schema version – A server advertising protocolVersion: "2025-11" but shipping a 2024-12 tool schema will break silently when the client requests typed inputs.
2. Egress claims – The manifest should declare network: { egress: ["api.github.com"] }. If it says egress: "*", assume it phones home with your data.
3. Auth model – Does it expect a token in env, or does it open a callback server? The latter is fine locally, painful in locked-down containers.
4. Last publish date – An mcp server directory entry with no release in 9 months is a liability, not a stable dependency.

A quick static check you can run before install:

npx @modelcontextprotocol/inspector --dry-run @modelcontextprotocol/server-github

The inspector prints the tool list and declared capabilities without executing side effects. Pipe its JSON output into a schema validator in CI to fail builds when a dependency drifts. If the server uses HTTP transport, add --transport http and point it at the registered URL.

Running a private mcp server directory

Public indexes are noisy when you have twenty internal services. Stand up a private index: a static JSON file served from your internal CDN that follows the same schema as the public feeds. The client config can point at a URL instead of a package name:

{
  "mcpServers": {
    "hr": {
      "url": "https://internal.registry.example.com/servers/hr-mcp.json",
      "transport": "http"
    }
  }
}

The tradeoff is that you own uptime and signature verification. Use signed manifests (JWS) so a compromised CDN can’t inject tools. A private mcp server directory also lets you enforce internal policy—for example, rejecting any server that declares egress outside your VPC range.

Publishing your own server: the ordered path

If you built an internal tool wrapper, publishing it broadens reuse. Follow this sequence.

1. Implement against the SDK, not raw JSON-RPC

The TypeScript SDK handles the handshake and capability negotiation. A minimal server exposing one tool:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server(
  { name: "weather", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler("tools/list", () => ({
  tools: [{ name: "get_forecast", description: "Fetch forecast", inputSchema: { type: "object", properties: { zip: { type: "string" } } } }]
}));

server.setRequestHandler("tools/call", async (req) => {
  if (req.params.name === "get_forecast") return { content: [{ type: "text", text: "sunny" }] };
  throw new Error("unknown tool");
});

await server.connect(new StdioServerTransport());

This is the entire surface. No HTTP server, no auth middleware—the client manages that.

2. Ship a manifest with explicit boundaries

The manifest is what an mcp server directory ingests. Keep it tight:

{
  "name": "@yourorg/weather-mcp",
  "version": "1.0.0",
  "protocolVersion": "2025-11",
  "capabilities": { "tools": { "get_forecast": { "rateLimited": false } } },
  "network": { "egress": ["api.weather.gov"] },
  "auth": { "type": "env", "var": "WEATHER_API_KEY" }
}

Omitting network.egress is interpreted as no external calls. Over-claiming gets your listing flagged by automated scanners.

3. Submit to a directory and pin your version

Push to the official repo via PR if you want curation. For faster iteration, publish the package to npm and register the coordinates in Smithery or the JSON feed. Always tag an exact version in your listing; latest in a directory means “whatever broke yesterday.”

Tradeoff: official curation gives trust but slow updates. Third-party indexes give speed but require consumers to verify hashes themselves. A private index sits in the middle—you control review velocity.

Keeping your listing from rotting

MCP schemas evolve. When you bump protocolVersion, deprecate the old tool names instead of deleting them. Clients cache capability negotiations; a hard break forces every downstream agent to crash-loop.

Add a deprecated field to tools:

{
  "name": "get_forecast_v1",
  "deprecated": "use get_forecast_v2"
}

And keep the handler returning a clear error for at least two minor versions. Write a contract test that calls both the deprecated and new tool against a mock client so you notice when you accidentally drop support.

Common pitfalls when consuming directories

• Blind latest installs – A 2026 supply-chain incident started from a compromised latest tag in a popular mcp server directory. Pin hashes or commit SHAs in your client config.
• Ignoring cache-control hints – If a server returns Cache-Control: max-age=60 on a tool response, respect it. Polling the same tool every second gets you rate-limited and poisons any shared inference gateway.
• Mixing transports without isolation – Running a stdio server and an HTTP server in the same process namespace leads to file descriptor leaks. Spawn separately, ideally in distinct containers.
• Assuming directories vet runtime behavior – They check metadata, not code. A listing can claim egress: [] while spawning a child process that curls elsewhere. Run the server in a seccomp sandbox during eval.
• Trusting download counts as signal – A high count in an mcp server directory often means it was the first result for a query, not that it is safe.

The mcp server directory you choose should match your risk posture: internal agents get the conservative official list; prototyping can use the wild west feeds. Either way, the protocol’s strength is that swapping servers is a one-line config change—use that to keep your architecture loose.

What to do next

Pick one internal API you wrap by hand today. Write the 30-line SDK server, emit a manifest, and submit it to your chosen mcp server directory. Within a week you’ll have replaced three bespoke agent branches with a single capability declaration, and you’ll know exactly which egress paths your agents actually use.