Why it exists
The MCP ecosystem grew fast and fragmented. The official MCP Registry hosts metadata for thousands of servers but explicitly delegates security scanning to subregistries. Ten-plus parallel registries and directories (Smithery, Glama, mcp.so, PulseMCP, Cursor Directory, and more) each carry inconsistent quality signals, and none provide deep security analysis. Recent research found that 41% of the 518 servers in the official MCP Registry ship with no authentication at all (Kai Security AI), and that a critical vulnerability inmcp-remote, an OAuth proxy with more than 437,000 downloads, let a malicious server run arbitrary commands on the connecting client (CVE-2025-6514).
Ultra Ledger is a security-focused subregistry: it catalogs servers across the ecosystem and publishes signals you can verify.
What’s in the Ledger
Every MCP server indexed by the Ledger has:| Surface | What it shows |
|---|---|
| Trust Score | A 0–100 score derived from eleven security signals. Sigstore-signed and recorded in Rekor’s transparency log. |
| Tool inventory | Every tool the server exposes, with risk level, annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint), and annotation verification status. |
| Permission analysis | Network, filesystem, env-var, shell, and database access, with scope and risk assessment. |
| Poisoning scan | Full-schema prompt-injection detection across every JSON schema field, not just description. |
| Version history | Manifest hashes per version, version diffs that surface added or removed tools, permission expansion, and annotation changes. |
| Provenance chain | Append-only record of every event (indexed, scanned, score change, flag added) signed via Sigstore. |
| Registry coverage | Which of the 10+ public registries the server appears in. |
| Author profile | Verified identity (GitHub org, DNS challenge, HTTP challenge), other servers by the same author, reputation score. |
Trust Score
The Trust Score summarizes the scan output as a 0–100 value, calculated from eleven security signals:- Permission scope: least-privilege adherence in declared permissions
- Code quality: linting, dependency hygiene, known vulnerability patterns
- Author reputation: verified identity, track record, prior servers
- Version stability: change frequency, breaking changes, suspicious diffs
- Annotation accuracy: whether self-declared tool annotations match verification
- Tool description safety: prompt-injection risk across schema fields
- Auth implementation: OAuth quality, credential management, PKCE
- Spec compliance: MCP spec adherence, presence of
.well-known/mcp.jsonServer Card - Community adoption: stars, downloads, cross-registry presence
- Transparency: license, README, docs, changelog
- Vulnerability history: historical scan findings
Annotation verification
The MCP spec defines tool annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) and explicitly states they are “untrusted unless obtained from a trusted server.” Ultra Ledger verifies them and surfaces one of three badges on every tool:
- Verified: annotations match what static analysis observes
- Unverified: no annotations present or verification not yet run
- Mismatch: declared annotations contradict the tool implementation (e.g.,
readOnlyHint: trueon a tool that callsfs.writeFile)
Scanners
Each indexed version runs through a fixed scanner pipeline that inspects:- Manifest and permissions: declared tools, transport config, and env vars, with least-privilege gaps in the requested permission scope.
- Dependencies: known CVEs via OSV and the GitHub Advisory Database.
- Secrets: hardcoded credentials, API keys, and private keys.
- Prompt injection: full-schema scanning across every JSON field, not just
description, plus tool descriptions that reference, redirect to, or override other tools. - Command injection: taint analysis from tool inputs to dangerous execution sinks.
- Unicode obfuscation: invisible characters such as zero-width spaces, RTL/LTR overrides, and homoglyphs.
- Annotations and Server Card: declared tool annotations and
.well-known/mcp.jsonclaims checked against observed behavior.
Browsing the Ledger
Navigate to ledger.ultra.security and use:- Search: filter by score range, tags, transport type, source registry, risk level, or annotation status. Sort by trust score, popularity, recency, or recent flags.
- Server detail: visit
/s/{slug}for any server. Shows the Trust Score breakdown, every tool with its risk level and verification badge, full version history with expandable diffs, scan timeline, and provenance chain. - Registries: a comparison view of every public MCP registry the Ledger ingests from, with capabilities (search, publishing, security scanning), pricing, and coverage notes.
- Feed: a chronological stream of recently flagged servers and score changes, filterable by severity. Subscribe via RSS/Atom.
- Transparency: browse signed events and verify any attestation against Rekor.
How Ultra uses the Ledger
When Ultra evaluates a tool call at runtime, it consults the Ledger Trust Score for the upstream MCP server alongside its other security checks. Hub deployments cache scores locally and receive webhook updates when a score changes, so policy decisions stay current without round-tripping to the Ledger on every request. Future Ultra Hub releases will let you express score-based policy directly (for example, “block any tool call to a server with a Trust Score below 60, alert on 60–80”). The current release surfaces Ledger signals as informational context in audit events and the dashboard.What the Ledger is not
- Not a runtime enforcer. The Ledger publishes signals; enforcement happens in Ultra Hub via Guardrails and Governance.
- Not a hosted registry. The Ledger indexes servers from other registries and source repositories; it does not host server code or accept direct publishing.
- Not an audit replacement. Trust Scores raise or lower confidence quickly; they do not replace a manual security review for high-risk integrations.