> ## Documentation Index > Fetch the complete documentation index at: https://docs.ultra.security/llms.txt > Use this file to discover all available pages before exploring further. # Ultra Ledger > A continuously-updated, cryptographically-verifiable security registry for the MCP ecosystem Ultra Ledger is a security registry for Model Context Protocol (MCP) servers. It catalogs servers from across the fragmented MCP registry landscape, scans them for vulnerabilities and behavioral changes, publishes Sigstore-signed trust signals, and feeds those signals into Ultra's runtime security decisions. The Ledger lives at [ledger.ultra.security](https://ledger.ultra.security) and is free to use without an Ultra account. ## 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](https://dev.to/kai_security_ai/i-scanned-every-server-in-the-official-mcp-registry-heres-what-i-found-4p4m)), and that a critical vulnerability in `mcp-remote`, an OAuth proxy with more than 437,000 downloads, let a malicious server run arbitrary commands on the connecting client ([CVE-2025-6514](https://nvd.nist.gov/vuln/detail/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.json` Server Card * **Community adoption:** stars, downloads, cross-registry presence * **Transparency:** license, README, docs, changelog * **Vulnerability history:** historical scan findings Every score calculation is signed via [Sigstore](https://www.sigstore.dev/) and recorded in [Rekor's append-only transparency log](https://docs.sigstore.dev/logging/overview/). Auditors and compliance teams can verify a score was produced by Ultra at the stated time and that the inputs have not been tampered with. ## 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: true` on a tool that calls `fs.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.json` claims checked against observed behavior. Every finding maps to an [OWASP MCP Top 10](https://github.com/OWASP/www-project-mcp-top-10) category so security teams can track coverage against a shared framework. ## Browsing the Ledger Navigate to [ledger.ultra.security](https://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](/hub/guardrails) and [Governance](/hub/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.