Trust, stated plainly.

Every published screen verdict is semantic: an adversarial LLM judge reads the description for hidden instructions, exfiltration, or overclaims, bound to the exact tool definition seen. The screener runs on a recurring schedule, prioritizing new or requested servers; coverage expands across the registry as the corpus grows. The output is a per-tool REVIEW or UNVERIFIED with dimension verdicts and severity. The deterministic conformance probe (does observed behavior match the declared schema) is built but has not run on the public corpus; no published verdict carries a conformance result, and a clearing ALLOW - which the probe would have to earn - is not produced at v1.

The full method, the four-state model, and the graduation gate are documented in /methodology. It is written to be checked, not taken on faith.

Verdict history is hash-chained and anchored to Bitcoin via OpenTimestamps (latest confirmed at block 964,828). Each anchor commits to the previous one, so removing or reordering a past anchor invalidates every later link - and each of those is separately timestamped, so tampering is detectable against an external clock rather than against our own say-so.

What this proves is narrow, and worth stating exactly. An anchor shows that a given set of verdicts existed no later than the attested Bitcoin block. It does not show the verdicts are correct, it says nothing about minute-level ordering inside the confirmation window, and it does not reach back before the first anchor: the chain is real going forward, never retroactively.

What you can check yourself, and what you cannot. Anchor #37 covers 23,270 verdicts and carries an OpenTimestamps proof asserting Bitcoin block 964,828. The proof and the full ledger are committed at data/verdict-anchors.json alongside the .ots files in public/anchors/, so anyone can inspect them with the OpenTimestamps tooling.

The one-command check we previously withheld now exists: python3 scripts/verify_anchors.py from a clone of the site repository, no dependencies. It reproduces each anchor's root from the corpus at that anchor's own commit, re-folds the hash chain, and checks every proof stamps the chain_root it claims. The recipe it implements, including the one step nobody guesses, is written out in docs/verifying-anchors.md.

The earlier version of that script reported a clean pass on a checkout where it had in fact checked nothing, which is why we pulled it. This one refuses to report success unless it actually reproduced a corpus, and ships a --self-test so you can confirm it detects tampering rather than rubber-stamping. Do not take the green tick on trust; mutate a root and watch it go red.

• · Advisory, not blocking (the directory screen). The directory screen publishes a verdict; your agent or IDE decides whether to act. The screen does not sit in your call path or proxy your traffic. The in-path drift gate (below) is the separate surface that can HOLD a call.
• · Public artifacts in. Verdicts are produced from public tool definitions (the description + schema). The screener evaluates the text you paste - do not paste real secrets into it.
• · No call-time data. We evaluate the tool definition, not your runtime calls. Your arguments and your data never reach us.
• · Open by default. Methodology, quality scoring, and the registry source are public on GitHub. What we assert, you can audit.

The screen above is advisory and out of the call path. The drift gate is different in one decisive way: it is in-path. It pins each MCP tool’s contract on first sight and checks the live contract before your agent acts, so it can HOLD the call - not just alert after the fact, the way a passive scanner does. That position is what lets it protect a running agent; it is also what makes its trust posture worth stating exactly.

• · Zero credential custody. The gate never receives your tokens. It observes the session your client already authenticated and reads only the public tool contracts; the one-click wiring passes a server’s original env / headers through to that server untouched. There is no token field and no second connection - structurally, not as a promise.
• · Contract-diff, not a safety verdict. A HOLD means the tool’s contract changed versus what you pinned, not that the new contract is unsafe. The gate asserts what changed; you review and re-pin if it is expected.
• · Fail-closed. A tool with no pin, an unreadable contract, or a diff the gate cannot complete HOLDs rather than proceeds. The gate never renders a silent ALLOW on something it could not verify.
• · Advisory in judgment, in-path in effect. The judgment is narrow and provable (a deterministic contract-diff); the effect is real because the gate sits in the call path. We do not claim it verifies safety, blocks attacks, or certifies a tool.

What a security reviewer needs in one place: where the gate runs, what leaves the machine, and which threats it does and does not address.

• · Where it runs. In-path on the developer / agent host, single-tenant by default. The multi-tenant gateway (logical, in-process isolation, posture, and audit) is built but held off by default behind an explicit flag; spoof-resistant identity and process/VM separation are roadmap, and it is not the default deployment.
• · What leaves by default: nothing. The deterministic tier-0 contract-diff runs locally; the default build egresses nothing and never holds your credentials. Tiers 1-3 (cloud corpus lookup, LLM consult, behavioral verifier) are built in-path seams, each held off by default and gated behind explicit opt-in.
• · Optional egress: the cloud corpus lookup. If you opt into the cloud tier-1 corpus lookup, the only thing that leaves is a contract hash (a deterministic hash over the public tool contract) plus your bearer key on the pinned transport - never a token, an argument, a schema body, or your call data. Any error degrades to a miss (fail-closed). That request lands on mcpindex’s US-region edge.
• · Optional egress: the drift network. If you opt into drift telemetry (MCPINDEX_DRIFT_TELEMETRY=detection, off by default), the gate emits one one-way signal on a pin or a drift - salted (HMAC) fingerprints of the server/tool id, the contract hashes, the change type, a safety flag, an hour-rounded time, a random install id, and the SDK tag - and queries the network so it can warn you on the first call. Never a schema, argument, description, URL, or server/tool name. Fail-open: it never blocks or changes a call. Full disclosure on privacy.
• · Sub-processors. None in the default local deployment - nothing leaves the host, so there is nothing to sub-process. If you opt into the cloud tier-1 lookup, the request lands on our US-region edge (Vercel) and no other sub-processor sees it. A current sub-processor list is available on request.
• · Supply-chain integrity. The install.sh / install.ps1 installer and the published wheel ship with a SHA-256 you can verify before you run them, and the installer is auditable by piping it to less first. A signed single-binary (SLSA provenance) is on the roadmap; until then, pin the checksum.
• · Threats addressed. Silent contract drift (a tool changing its contract after you pinned it), description-poisoning (hidden instructions in a tool description), and an injection / exfil marker planted in an input or output schema.
• · Threats NOT addressed. The gate does not prove a tool safe, block or prevent an attack, or catch malicious runtime behavior that stays within an unchanged contract. It reports what changed; you decide.

Direct and current: mcpindex is pre-SOC 2. We are not going to imply otherwise. The interim posture is the one above - advisory deployment, no call-time data, public method, hash-chained history. Formal attestation (SOC 2 Type 2) is on the roadmap, not something we claim today. If you have a specific compliance requirement, tell us what you need and we will answer honestly about where we are.

Data handling is described in our privacy policy.

A trust product earns trust by stating its edges, on every verdict: the screen is semantic (the conformance probe is built but has not run on the public corpus; when it runs it is monitored, not enforced); confidences are reported but not yet calibrated (calibrated=false at v1); coverage expands continuously as the backfill scanner runs (15 of 150 labels to graduation, adversarial cases first). The full contract lives on /methodology - and it changes there first, before the verdict surface does.

Report a vulnerability to security@mcpindex.ai (or hello@mcpindex.ai). We acknowledge within two business days and aim to ship a fix or a mitigation timeline within ten. Please give us a reasonable window before public disclosure. A SECURITY.md with the same policy and a PGP key is published in the repo.

Live system status, data freshness, and the incident log are at /status. To report a problem with a verdict, email hello@mcpindex.ai.