Why the gate exists.

The official MCP registry at registry.modelcontextprotocol.io is the canonical list of MCP servers. PulseMCP, Smithery, Glama, and MCP.so present human-browsable views on top of it. A list is the right primitive for discovery. It is not the right primitive for the decision an agent has to make next.

That decision is the trust call. The MCP description is a contract the agent obeys the way it obeys a system prompt. If the description lies (instructs the agent to exfiltrate a key, claims schema validation it never runs, hides a destructive side effect inside a benign-sounding tool) the agent has no way to know. The agent will act. The user finds out after.

mcpindex publishes a per-tool finding with dimension verdicts (integrity, hidden intent, and others) and severity. Today the screen is semantic-only: an LLM judge reads the description for hidden instructions. The deterministic conformance probe — which checks whether observed behavior matches the declared schema — is built but has not yet run on the public corpus, so no published screen verdict carries a conformance result yet. History is OTS Bitcoin-anchored, so once a block confirms, the trust record for a tool cannot be quietly rewritten.

v1 is honest about its edges. Conformance is built but not yet run on the screen; when it runs it is monitored, not enforced. OTS Bitcoin-anchored history with cadence bound = confirmation latency (~10 min for pending; ~1 hour at N=6 confirmations for Bitcoin-finalized); sub-window precision asserted, not proven. Confidences are reported but not yet calibrated (calibrated=false). Deployment posture is advisory: we publish the verdict; the agent or IDE decides whether to act on it. The graduation gate to D3 is >=150conforming labels with FP upper-95 <=2%; today the corpus stands at 15/150.

The trust call happens at two moments, and mcpindex answers the same question at both: should my agent act on this tool, right now? Before you wire a tool, the directory screen is the prior: an advisory, semantic read of whether the description matches the behavior. During use, the drift gate is the live check. It pins each tool’s contract and HOLDs a call the instant that contract silently changes, before your agent acts. The screen catches a lie at publish time; the gate catches the silent change at runtime, the gap nothing else covers, widening as agents get more autonomous.

The gate is a deterministic contract-diff, in-path, and runs on your host. Above that live tier-0, the ladder is built as in-path seams: a cloud tier-1 corpus lookup, a tier-2 LLM consult on the ambiguous, and a tier-3 behavioral verifier that exercises a changed tool. Each is held off by default and requires explicit opt-in; the default build egresses nothing and stays fail-closed. It is a contract-diff, not a safety verdict: when enabled, the behavioral tier clears or refutes a change, it does not prove a tool safe.

The two moments feed each other, and that loop is the network. The first turn is already live: mcpindex crawls the public registry every day and records every contract that drifts, and the gate can query that record to warn you on the first call — crawler-corroborated and opt-in. That record is public in the live drift ledger. The deeper tier-1 corpus lookup the gate queries before it decides is still held off by default. The gate alone is copyable, and open source by design. What compounds is behind it: the growing record of drift, the corpus of verdicts, and the published methodology that governs them. A competitor can re-implement a contract-diff in a weekend; they cannot re-implement the record.

Three primitives are exposed: an agent-readable index, the verdict surface on every server page, and a drop-in MCP server that exposes check_tool_trust to your agent. Architecture and integration notes are in /docs; the eval method and honest limits are at /methodology.