Ecosystem analysis · Research note 001

What runtime verification reveals about MCP security

The MCP ecosystem is growing faster than security teams can manually inventory it. We run exact releases inside isolated environments to separate observable behavior from package claims.

Published August 27, 2026 · Live aggregate metrics

The current picture

Our catalog currently resolves 71,584 active source listings into 71,565 canonical MCP implementations. Runtime coverage is still expanding, so verified results and untested inventory must never be confused.

71,565canonical MCPs
8,593MCPs scanned
8,402current versions verified
508current versions with proven findings

That represents runtime coverage of 12.0% of canonical inventory. Among current versions with completed verification, 6.0% have at least one proven security finding. These rates describe the tested population, not the untested remainder.

Why runtime verification changes the answer

Source metadata can tell us what a server says it supports. It cannot prove which tools initialize, whether a dangerous input reaches a sink, or whether a result repeats reliably. Our pipeline installs the exact package version, initializes it as an MCP client would, observes its protocol capabilities, and exercises bounded security canaries in an isolated sandbox.

“Proven” is deliberately narrow. A finding must reproduce deterministically under the scanner’s canary method. It does not automatically mean the issue is remotely exploitable, vendor-owned, bounty-eligible, or severe in every deployment. Deployment context still matters.

Three decisions this data can support

  1. Adoption: compare a proposed exact version with observed tools and current verification before installation.
  2. Change control: detect when a new version introduces capabilities or risk that were absent from the previously observed release.
  3. Prioritization: direct human review toward deterministic evidence while keeping unverified inventory clearly labeled.

What the catalog does not claim

An unscanned MCP is not clean. A locally proven input-handling flaw is not automatically a hosted-service compromise. A similarly named project is not automatically affiliated with the referenced brand. We preserve those distinctions because overstating evidence makes security intelligence less useful.

Methodology and responsible publication

Tests execute against downloaded artifacts or authorized targets in isolated infrastructure. Aggregate research excludes secrets, unpublished exploit instructions, and embargoed disclosures. Exact-version evidence is retained so later releases can be compared without rewriting history.

Explore the live catalog or learn about continuous organizational monitoring.

Let’s talk about MCP security.

Share your details and our security team will contact you.