Read the public drift ledger and dashboard
You can read the public drift ledger and dashboard: what the crawler saw change, how to spot a safety-relevant diff, and what the coverage numbers do (and do not) mean.
The ledger is public proof of the problem the gate solves. mcpindex crawls the public MCP registry every day and records which tool contracts silently change between snapshots. No login, no per-user data, and no server pays to be listed. Here is how to read it. The deduped, citable analysis of the same corpus lives at The MCP Drift Report.
- 01
Open the drift ledger#
Start with the headline. The top of the ledger is a fraction of tools, not a product of tools times changes: N tools changed a contract field we publish, of M tools observed drifting. The remainder changed in ways we record but do not publish (mostly description-only edits). Servers affected and safety-relevant counts sit just below.
Open the drift ledger — the big count ('N tools changed a contract field we publish'), then 'of M tools observed drifting', then Servers affected and Safety-relevant contract changes.
- 02
Read an event row#
Each row in the Events table is one observed contract change, and it is deliberately fingerprint-only:
Column What it means Tool fingerprint A content hash of the tool, not its name Server fingerprint A content hash of the server (a dash if none was recorded) Last seen When the crawler last saw this contract What changed The change kinds: a new required param, an annotation flip, a narrowed constraint Safety Tagged when the change touched a safety-relevant field mcpindex reports that a contract changed without publicly naming a specific server.
- 03
Spot a safety-relevant change#
The Safety column flags a change that touched a safety-relevant field, an annotation flipping to destructive or a new required parameter, for example. Read it as 'this one deserves a look,' not as a confirmed vulnerability. A dash means the change was not safety-relevant.
- 04
Read a context-surface change#
Below the Events table, a second table appears when the crawler has seen a server change its context surface. These entries are not tools, which is why there is no tool fingerprint column:
Column What it means Server fingerprint A content hash of the server, never its name Last seen When the crawler last saw this surface What changed The context kinds: instructions added or changed, or a prompt's argument contract changed A context surface is the text a server hands your client to inject into the agent's context when it connects: the server's own instructions, and the metadata of the prompts it offers. It is server-scoped, so one entry covers the whole server rather than a single tool. This text sits outside every tool contract hash, which means a change here moves nothing the gate pins, and the crawler's observation is the only drift signal it has. The section is absent when nothing has been observed.
- 05
See coverage on the dashboard#
The dashboard pairs two different populations: opt-in telemetry (installs that chose to send salted-fingerprint signals) and the public-registry crawler ledger. They count different things, so the numbers will not match. Coverage is the network growing, because every covered server is one the gate can warn you about on call 1.
Open the drift dashboard — two sections, Opt-in telemetry and Crawler ledger. Telemetry is opt-in and off by default, and coverage is not endorsement.
- 06
What the ledger is not#
It is a contract-diff, not a safety verdict, and not prevention, that is the in-path gate's job, holding the call. And absence is not a clean bill of health: a private or un-crawled tool never appears here at all.
- Does the mcpindex drift ledger name the servers that changed?
- No. Every event is fingerprint-only: a content hash of the tool and (when recorded) the server, never the name. mcpindex reports that a contract changed without publicly naming a specific server.
- Is a safety-relevant change in the ledger a confirmed vulnerability?
- No. The safety-relevant tag means the change touched a safety-relevant field, like an annotation flip or a new required parameter. It flags a change worth reviewing, not a proven exploit. The ledger is a contract-diff, not a safety verdict.
- Why do some ledger entries have no tool fingerprint?
- Because they are not about a tool. Entries in the context-surface table are server-scoped: they record a change to the instructions or prompt metadata a server injects into an agent's context on connect. One entry covers the whole server, so it carries a server fingerprint and no tool fingerprint.