The MCP ecosystem has moved past the scarcity phase. The hard part is no longer finding a server for a workflow. The hard part is knowing whether that server is safe enough, maintained enough, and clear enough to put near a real agent.
AgentNDX now tracks 1,288 MCP servers. Of those, 341 are verified. That is 26 percent. The other 947 are not automatically bad, abandoned, or unusable. Many come from credible repos and known platforms. But listed and verified are different claims, and the difference matters more as agents get access to production systems.
What Verification Means
A listed server means the project exists, the metadata is usable, and the server appears relevant to agent workflows. A verified server means someone has done the harder work: check the install path, confirm the connection model, inspect the claimed capabilities, and make sure the listing matches what the server actually does.
That second step is slower because MCP servers are not static documents. They are executable integrations. Some need API keys. Some need OAuth apps. Some touch paid services. Some only work in a local stdio setup. Others expect a hosted HTTP endpoint. A directory can collect metadata quickly, but verification requires running into the messy edges that developers will hit later.
This is why the trust gap is normal. It is also why it cannot be ignored.
The Current Numbers
Here is the current AgentNDX snapshot as of September 11, 2026:
| Metric | Count | Share |
|---|---|---|
| Total MCP servers | 1,288 | 100% |
| Verified servers | 341 | 26% |
| Unverified servers | 947 | 74% |
| Active health status | 1,206 | 94% |
| Unknown health status | 82 | 6% |
Transport is split between local and networked use:
| Transport | Servers | Share |
|---|---|---|
| stdio | 710 | 55% |
| HTTP | 574 | 45% |
| SSE | 4 | <1% |
Auth tells the production story more clearly:
| Auth Type | Servers | Share |
|---|---|---|
| API key | 720 | 56% |
| None | 290 | 23% |
| OAuth | 272 | 21% |
| x402 | 6 | <1% |
API keys still dominate. OAuth is present but not yet the default. x402 exists, but it is still early. For developers choosing servers, that means trust is not just about whether a server works. It is about whether its auth model fits the risk of the workflow.
Where Verification Is Hardest
The verification rate is fairly even across large categories, but a few patterns stand out.
Data has the most servers, with 372 listed and roughly 101 verified. That category includes databases, warehouses, search tools, crawlers, and structured APIs. It is the center of gravity for MCP because agents need context before they can act. But data integrations are also harder to verify cleanly. You often need accounts, sample datasets, credentials, and realistic permission boundaries.
Infrastructure has 212 servers and about 57 verified. These are valuable, but the risk is higher. An agent connected to cloud infrastructure, deploy tooling, DNS, or container control can do real damage if the server exposes broad write permissions. A working install is only the first question. The better question is what the agent can do after it connects.
Identity remains small, with 25 servers and about 7 verified. That category should probably be bigger by now. Agent systems need identity, scoped access, audit trails, and permission boundaries, but the directory data still shows far more work on data access than access control.
How to Read a Directory Listing
A good MCP directory listing should help developers make a risk decision quickly. Start with the basics: category, transport, auth type, install command, verified status, and health. Then look for fit.
If you need local file access, something like Filesystem MCP can be the right tool, but it should be configured with narrow path permissions. If you need repository automation, GitHub MCP is useful, but the token scope matters more than the install command. If you need browser automation, Playwright MCP gives agents a real browser surface, so you should treat it like a powerful operator, not a harmless scraper.
For hosted or data-heavy workflows, compare the trust signals before wiring the server into a long-running agent. PostgreSQL MCP, Supabase MCP, and AgentNDX all sit in the broader data layer, but they carry different auth and deployment assumptions. Same category does not mean same risk.
The Next Directory Problem
Discovery was the first directory problem. Verification is the second. The third is ongoing trust.
A server can be verified in April and break in September. A repo can change its install command. A platform can change OAuth scopes. A package can move from stdio to HTTP. A health check can pass while the most important tool call fails. Directories need to track more than existence.
The next useful trust layer will look closer to a package registry plus an uptime monitor plus a security checklist. Install verified. Tool schema checked. Auth model labeled. Last health check shown. Write operations flagged. Maintainer activity tracked. Maybe even example agent configs that are known to work.
That is where MCP discovery is heading. Not bigger lists. Better confidence.
FAQ
Q: Does unverified mean unsafe? A: No. Unverified means AgentNDX has not completed the hands-on check yet. Treat it as an unknown, not a rejection.
Q: Should production agents only use verified MCP servers? A: Prefer verified servers when the workflow touches production data, write operations, money, infrastructure, or customer systems. For local experiments, unverified servers can still be useful if you inspect the repo and run them in a safe sandbox.
Q: What is the fastest way to compare trust signals? A: Check verified status, health, auth type, transport, install command, and the scope of exposed tools. A narrow read-only server is a different risk profile from a broad write-capable server with a long-lived API key.