Discovering and Evaluating Public MCP Servers

MCP server access for AI agent web data should deliver clean Markdown or schema-driven JSON. For live web-data pipelines, the choice depends on maintenance, authentication, security posture, and operational cost (not a registry listing). Discovering a public MCP server is easy. Evaluating it is what separates useful infrastructure from a liability.

Why the MCP server ecosystem is structurally different from any previous open tool marketplace

Anthropic open-sourced MCP in late 2024 to solve the N×M integration problem. Instead of every AI client needing bespoke code for every tool, each client implements MCP once, making servers reachable through a shared protocol. That removes a large amount of repetitive integration work. It also makes a newly published server available to a much wider set of clients without separate integrations for each one.

By December 2025, MCP had been donated to the Linux Foundation’s Agentic AI Foundation, with Anthropic, OpenAI, and Block as co-founders and Platinum membership from AWS, Google, Microsoft, Bloomberg, Cloudflare, and others. As of July 2026, the Python and TypeScript SDKs together exceeded tens of millions of downloads per month, up from roughly 2 million at launch. Claude Code, Cursor, Windsurf, VS Code Copilot, and JetBrains AI all support it. Yet anyone can publish a server without a review, security audit, or promise to maintain it, so the groups that govern the protocol have not approved each server that uses it.

Where servers are actually listed and what each registry does and does not verify

The official MCP Registry is community-maintained, open, and implements the MCP Registry Specification. Its namespace convention, such as io.github.username/server-name, prevents naming collisions and ties names to ownership in that narrow sense. Ownership is not a security review. The registry provides no access control, environment separation, or audit trail, and its open publishing model does not make it a curated store.

Smithery.ai operates as a publisher platform with its own CLI, @smithery/cli, and a managed authentication layer. Smithery handles OAuth flow, credential storage, and token refresh, reducing work around connecting to authenticated services.

AI Agents Listing takes a different approach to discovery. Solo founder Nick in Vancouver launched it on September 6, 2026, combining agents, MCP servers, and skills in one catalog. It reviews every listing by hand and exposes the catalog over MCP so agents can query it directly without a login. Human review adds a distinct discovery signal. It should not, however, be treated as evidence of a security audit when no such audit is specified.

These catalogs also overlap rather than forming separate pools of vetted software. Glama, PulseMCP, mcp.so, and Smithery re-scan and cache what the official registry exposes, making them downstream copies of that source of truth. Copies can lag behind their source. As of October 5, 2026, Glama’s page for one surveyed server still showed a pre-rename brand weeks after the app had changed names. A listing therefore establishes discoverability, but its metadata may not even describe the server’s current identity.

What a large-scale analysis of public servers actually found about their security posture

Large-scale analysis of public MCP servers has identified unauthenticated endpoints, dangling domains, and infrastructure in unexpected jurisdictions across tens of thousands of servers. Those findings concern exposure and deployment, rather than whether a particular model will follow a malicious instruction. Controlled testing addresses that separate question. Palo Alto Networks Unit 42 evaluated 45 real-world MCP servers using the MCPTox benchmark across 20 LLM agents, measuring an average attack success rate of 36.5% and a rate as high as 72.8%.

The distinction from a traditional API lies in who chooses the action. Developers ordinarily control API calls, while MCP lets an LLM decide which tools to invoke, when to invoke them, and what parameters to supply. Tool metadata becomes part of that decision. As a result, the attack surface combines prompt injection, supply-chain compromise, and confused deputy problems, in which an agent’s legitimate access can serve an attacker’s instructions. Evaluating returned data alone does not cover the descriptions and schemas the model reads before making a call.

The Sandworm_Mode campaign, active by February 2026, showed how a supply-chain attack could reach that surface. Malicious npm packages mimicked popular utilities and installed rogue MCP servers targeting Claude Code, Claude Desktop, Cursor, VS Code Continue, and Windsurf. The campaign used prompt injection to exfiltrate SSH keys, AWS credentials, and npm tokens. The malicious instructions arrived through the toolchain itself.

OX Security identifies a further limit on inspection. A remote MCP server can run backend code that differs entirely from the code in its public repository.

The token cost problem that security-focused evaluation tends to overlook

A secure server can still be expensive to use. When every connected server loads its full tool schema into the agent’s context window, the session pays that overhead whether or not the tools are invoked. Six servers touching GitHub, a database, Slack, Jira, cloud infrastructure, and monitoring can load tens of thousands of tokens of schema alone. The agent has read the whole menu before it knows if it wants lunch. At thousands of runs per day, that upfront cost becomes an operational constraint.

Scalekit’s benchmark using Claude Sonnet 4 for GitHub operations found that MCP consumed substantially more tokens than equivalent CLI calls. MCP also had a lower success rate, with a meaningful share of attempts timing out. That comparison shows why protocol convenience and task efficiency need separate evaluation, particularly when retry loops on a failing server add cost. A server’s availability in the ecosystem says nothing about whether it is an economical route to a particular result.

Progressive disclosure offers a concrete way to reduce schema overhead. Where supported, servers can be configured to expose only the tools relevant to the session’s task. This narrows what the agent must load. Tool count, round-trip latency, and behavior during failures still need testing because schema size is only one part of the cost. No registry currently tracks when a server’s tools change, so a good benchmark result cannot establish that later sessions will have the same overhead or reliability.

Which MCP servers fit live web-data pipelines, and why does vendor hosting change the choice?

The servers appearing most frequently in production setups share observable traits, including active maintenance, defined authentication, and scoped permissions. Those traits say more about a server than how long a directory is or whether the server is listed in it. Vendor-hosted servers move several checks to the point when the user signs in. Their emergence in 2026 gives teams a structurally different option from independently maintained connectors, because the vendor patches the service and the user’s existing account permissions apply.

Vendor hosting also changes how credentials are handled. These servers use OAuth, so no API key sits in a config file, and access follows the permissions of the connected account. Write scope still needs to be checked before the server is connected to production data.

For teams building pipelines that consume live web data, output format adds another concrete requirement. Clean Markdown or schema-driven JSON is a prerequisite for feeding LLM context windows reliably. The interface must fit the downstream task. The preferred format for AI-ready data has shifted from ad-hoc scripts toward standardized JSON-RPC services, making structured output part of the integration contract.

These requirements distinguish two questions that are easy to blur. Vendor hosting addresses who maintains the service and how account access applies, while structured output addresses whether the result is suitable for the pipeline. Neither substitutes for the other. A web-data server can format data well yet fail the security checks, just as an authenticated service can expose too many tools or take too long to respond.

A concrete evaluation checklist and when to skip a server entirely

The practical checklist follows four dimensions in sequence, namely maintenance, authentication, security posture, and operational cost. Commits in recent weeks and a changelog that documents changes to behavior or scope are the starting point. Without those records, it is hard to tell whether the server is being patched or what has changed. Cross-check the registry listing against the source repository because cached metadata can lag for weeks. For production SaaS integrations, prefer vendor-hosted servers, where the vendor patches the service and existing account permissions apply.

Next, inspect authentication and permission scope together. Prefer OAuth over static API keys, which most authenticated servers use and which have no expiry or scope limit by default if leaked. Then establish whether the server can write. That single distinction determines how much damage a confused prompt can do, so it belongs before the connection to production data. Authentication answers who can connect. Scope answers what that connection permits.

Scan tool names, descriptions, and JSON schemas for tool-description injection, because response-only testing will miss that vector. Check where the infrastructure resolves against the jurisdictions your security policy covers. That location can change after initial review. Also check domain registration status, since expired domains on active listings are a documented supply-chain risk and can be registered by anyone for a few dollars.

Repository inspection adds evidence, but not certainty about remote execution. Treat a server without a public repository, or with one that does not match its declared functionality, as unreviewed. Then measure the operational costs before committing it to a pipeline. Count the tools the server exposes, test round-trip latency, and use progressive disclosure where possible so the session gets only the tools it needs. Slow responses and retry loops can make a cost that seems small per request add up with repeated use.

A server with no commits in 30+ days and no changelog, or one without authentication that connects to anything beyond read-only public content, should be skipped. Skip it if its infrastructure resolves outside an approved jurisdiction, or its domain registration is expired or recently transferred. The same applies when there is no public repository, the repository does not match the declared tool set, or token overhead is disproportionate to the task and no scoping mechanism exists. A searchable listing does not overrule a failed check.