Hundreds of AI Agents Now Ship MCP Servers. How Many Can You Actually Trust?

The Model Context Protocol went from a niche idea to table stakes in under a year. Agents that ship an MCP server can plug into your files, your databases, your cloud, and each other. That same reach is exactly why MCP became the headline AI security story of 2026: Trend Micro found 492 MCP servers exposed to the public internet with no authentication at all, and a single command-injection bug in one popular MCP utility (CVE-2026-0755, CVSS 9.8) let unauthenticated attackers run arbitrary code.

Most of that coverage is about runtime security — prompt injection, tool poisoning, over-permissioned connectors. Those matter. But there's a more basic question that comes first, and almost nobody is asking it:

How many agents ship MCP servers now

We scan every agent we track for MCP server code and documentation. As of this week, 122 of the 272 agents (45%) implement or declare an MCP server, and 72 of them (26%) have a confirmed implementation in the codebase. A year ago this number was a rounding error.

Here's the uncomfortable part. Of those 122 MCP-shipping agents, 93 (76%) publish no build provenance. The median OSSF Scorecard among them is 5.5/10. So the components most likely to be handed broad system access are, as a group, no more verifiable than the rest of the ecosystem — arguably less, because the most-installed ones skew worst.

Popular MCP-shipping agents with no provenance

None of this means these projects are compromised or unsafe. It means an independent observer can't cryptographically confirm the published artifact matches the public repo — and for software you're about to hand tool access, that gap is worth knowing about.

The ones doing it right

A handful of MCP-shipping agents do publish provenance, and they cluster at the top of the trust rankings — not because we reward MCP, but because teams that ship attestations also tend to sign commits, run OSSF Scorecard, and maintain disclosure policies. Trust signals travel together.

Why MCP raises the stakes

A poisoned build of a logging library exfiltrates data. A poisoned build of an MCP server inherits every credential and tool the server brokers — which is frequently your databases, your cloud, and your file system at once. MCP servers are credential concentrators by design, which is what makes the missing-provenance gap more consequential here than almost anywhere else in the dependency tree.

Provenance won't stop a maintainer account from being compromised. What it does is make tampering detectable: the published artifact carries a signed link to the exact commit, build system, and workflow that produced it. Without that link, a swapped package and a legitimate one look identical from the outside.

Data from HVTracker signals as of June 21, 2026. MCP detection is based on server code and documentation found in each repository. Provenance is checked via npm registry attestations and PyPI PEP 740 metadata. Full methodology. Related: why provenance catches the 2026 registry attacks.