Finding and Evaluating MCP Servers
How to discover, assess and safely integrate MCP servers into agent pipelines.
The Model Context Protocol (MCP) is an open protocol for connecting AI models to external tools, data sources and services. Announced by Anthropic in November 2024, it has since seen broad industry adoption. MCP defines a client/server interface: a host application (the MCP client) connects to servers that each expose tools, resources and prompts the model can invoke.
Governance note: MCP originated under Anthropic stewardship but has attracted contributions from many organisations. Governance structures evolve quickly — verify the current status at modelcontextprotocol.io before relying on any statement about who controls the specification.
Key facts
- MCP, an open protocol from Anthropic dating back to late 2024, gives AI models a standard way to reach outside tools, data, and services.
- MCP's official registry — the natural first stop for discovery — had not exited its preview phase as of mid-2026.
- Servers are also distributed via client-vendor marketplaces, community aggregators (PulseMCP, Smithery, Glama, MCP.so), and directly from vendors.
- Evaluate a server on its transport, auth model, permission/scope minimisation, and maintenance signals before connecting.
- Major security risks include prompt injection via tool descriptions, supply-chain compromise, "rug pull" updates, and over-broad permissions.
- Because an already-approved server can silently change behavior after an update, lock it to a specific version or content hash and manually recheck what its tools claim to do each time a new release ships.
- A major stateless-protocol spec revision shipped as final, on schedule, on July 28, 2026 — see MCP goes stateless for what changed.
Discovering MCP servers
The canonical starting point is the official MCP Registry (registry.modelcontextprotocol.io) — a community-driven open catalog/API for publicly available MCP servers, backed by Anthropic, GitHub, PulseMCP, and Microsoft (launched in preview September 2025; still in preview as of mid-2026). Publish to it with the mcp-publisher CLI (init → edit server.json → login github → publish); it stores metadata only, so the package itself must first be on npm or another artifact registry.
- github.com/modelcontextprotocol/servers now hosts only a small set of reference implementations maintained by the MCP steering group; its README defers to the registry for discovery, and many earlier servers moved to
modelcontextprotocol/servers-archived.
Beyond that, servers are distributed through: client-vendor marketplaces (AI-assistant and IDE vendors increasingly ship curated server lists — check your client's documentation); community aggregators — major ones in 2026 include PulseMCP, Smithery, Glama, and MCP.so (large directories that vary in review rigour — treat as leads, not endorsements); and direct from vendors (many teams publish MCP servers alongside their own products — prefer the official source over a third-party mirror).
Evaluating a server
Transport — the spec has evolved; treat the following as a snapshot and verify at modelcontextprotocol.io: stdio (local subprocess over stdin/stdout — low network surface); HTTP + SSE (legacy remote transport, still widely deployed); Streamable HTTP (newer consolidated remote transport — preferred for new deployments where the client supports it). Confirm the server's transport is supported by your client version.
Auth — Check what credentials the server requires from you and what it holds on your behalf to call upstream APIs. Long-lived third-party tokens stored server-side are a significant blast-radius risk if compromised.
Permission/scope minimisation — Prefer servers that expose only the tools your agent actually needs. Review the declared tool list before connecting; each tool is a potential code-execution or data-access path. Revoke access when done.
Maintenance signals — Recent commit activity, a maintained changelog, and absence of open auth/misbehaviour bugs indicate the server tracks spec changes. Unmaintained servers built against old protocol versions may stop working as clients update.
Security risks
Prompt injection — A server controls the text of its tool descriptions and outputs. A malicious server can embed instructions attempting to redirect model behaviour (exfiltrate context, override system-prompt constraints). Mitigate by only connecting to servers you can review or trust, auditing tool descriptions, and using output sanitisation.
Supply-chain — npm/PyPI packages for MCP servers carry the same risks as any open-source dependency: typosquatted packages, maintainer account takeovers, malicious dependency updates. Mitigate by pinning exact versions with lock files, preferring verified-org publishers, and auditing before production use.
Rug pull — a server you have already approved can push an update that silently changes its tool descriptions or behaviour, and most clients do not re-alert on changed definitions. Real cases include the postmark-mcp package, which silently BCC'd emails to an attacker address after a post-approval update, and the Cursor "MCPoison" issue (CVE-2025-54136); NSA MCP security guidance (2026) treats this as a systemic risk. Mitigate by pinning servers to exact versions/content hashes and re-reviewing tool definitions on every update.
Over-broad permissions — Filesystem access, network egress, or credentials beyond the server's stated purpose are a red flag and amplify every other vulnerability.
Checklist
- Source confirmed (official repo, vendor-published, or reviewed community server).
- Transport identified and compatible with your client version.
- Authentication model understood; credentials stored securely.
- Tool list reviewed; scope limited to what the agent actually needs.
- Package version pinned and checksum verified (if distributed as a package).
- Maintenance status checked (recent activity, no critical open bugs).
- Prompt-injection risk assessed; output sanitisation in place for untrusted servers.
- Tool descriptions/behaviour diff-checked on each server update before loading (rug-pull defense).
- Plan to revoke server access when no longer needed.