How a verdict is produced.

The screen above is the prior an agent reads before it wires a tool. The drift gate is the live, in-path check during use. It answers a narrower, provable question: did this tool’s contract change since you pinned it? The verdict is a contract-diff, not a safety verdict - but the gate sits in the call path, so it can HOLD the call before your agent acts on the change, not merely report it after. The gate runs deterministically and entirely on your host. Its verdicts are produced by the live gate code, not a hand-written table; the reproducible scenario battery is documented in the whitepaper.

• TOFU pin
  baseline

  On first sight of a tool (the client's tools/list), the gate pins the tool's contract trust-on-first-use: a hash over name + description + input schema, plus the captured schema. The pin can persist across restarts, so a contract that changes while your agent is offline is still caught on the next call. The first-seen contract is the baseline; the gate cannot catch drift that happened before it was installed.

• Contract-diff
  deterministic

  On a call, the gate re-derives the live contract and compares it to the pin. A mismatch is classified into a fixed taxonomy (ChangeKind): added-required-param, required-set-expanded, constraint-narrowed, type-changed, enum-values-removed, removed-param, annotation-flip-to-destructive, output-schema-added, output-schema-changed, tool-added/removed. It also scans for injection/exfil markers in the input AND output schema and the description. No LLM, no scoring you cannot trace; a structural surprise it cannot classify fails closed (deep-schema-undiffable), never open.

• Postures
  policy

  Monitor never blocks: every drift returns proceed-with-note. Guard (default) holds the unambiguously-breaking and dangerous changes while letting a proven-benign drift through; two kinds where behaviour is the gate (annotation-flip-to-destructive, output-schema-changed) resolve to INCONCLUSIVE rather than a flat block. Strict holds everything it cannot prove benign - NOT every drift: the benign auto-accept (added optional param, new tool, first-time output schema; description byte-identical, no risk escalation, no marker) runs BEFORE the posture layer, so a proven-benign change is re-pinned and proceeds under strict too. Anything else holds before the call.

  TIER 3  behavioural verifier   clears or refutes a change   [ ] HELD OFF - opt-in
          exercises the changed tool                             executes the tool
  TIER 2  LLM consult            judges the ambiguous         [ ] HELD OFF - opt-in
                                                                 an LLM call
  TIER 1  cloud corpus lookup    judged once, known           [ ] HELD OFF - opt-in
                                 everywhere                      a contract hash leaves
  ---------------------------------------------------------------------------------
  TIER 0  deterministic          did this contract change     [X] LIVE - runs first
          contract-diff          versus what you pinned?          local - no egress
          ChangeKind taxonomy                                     fail-closed
          + marker scan

  the default build is tier-0 only. it egresses nothing.
  the behavioural tier clears or refutes. it never proves a tool safe.

  ChangeKind                       MONITOR    GUARD*      STRICT
  ------------------------------------------------------------------
  added-required-param             notify     | HOLD      | HOLD
  constraint-narrowed              notify     | HOLD      | HOLD
  deep-schema-undiffable           notify     | HOLD      | HOLD
  enum-values-removed              notify     | HOLD      | HOLD
  removed-param                    notify     | HOLD      | HOLD
  required-set-expanded            notify     | HOLD      | HOLD
  tool-removed                     notify     | HOLD      | HOLD
  type-changed                     notify     | HOLD      | HOLD
  annotation-flip-to-destructive   notify     ? INCONCL.  ? INCONCL.
  output-schema-changed            notify     ? INCONCL.  ? INCONCL.
  added-optional-param             -> proceed -> proceed  -> proceed
  output-schema-added              -> proceed -> proceed  -> proceed

  * guard is the default posture.

  of 12 surfaced kinds: 8 HOLD under guard, 2 resolve to
  INCONCLUSIVE (behaviour is the gate, not a block), 2 proceed as proven-benign.

  STRICT DOES NOT HOLD EVERY DRIFT. the benign auto-accept runs BEFORE the posture
  layer, so a proven-benign change (an added optional param, a first-time output
  schema) is re-pinned and proceeds under strict too. strict holds everything it
  cannot prove benign.

  MONITOR never blocks: every kind returns PROCEED-with-note.

  an injection / exfil MARKER found in a schema or description is a separate scan,
  not a ChangeKind, so it is not a row here - but guard blocks on it, as it does on
  a risk escalation, a description change, and any fail-closed error.

  verified 2026-07-27 by driving the gate (corpus_eval/tooling/cse/gate.py) at all
  three postures.

• · Contract-diff, not a safety verdict. A HOLD means “this tool’s contract changed vs what you pinned” - not that the new contract is unsafe. You review the before/after and re-pin if the change is expected.
• · Advisory in judgment, in-path in effect. The gate does not assert a tool is safe; it asserts what changed. Because it sits in the call path, that judgment can actually HOLD the call - a passive scanner can only alert after the fact.
• · Deterministic tier-0 live; tiers 1-3 built but held off by default. The contract-diff is deterministic, runs first, and is the live, deterministic leg. Above it the ladder is built as in-path seams - a cloud tier-1 corpus lookup (a contract judged once clears or condemns it everywhere), a tier-2 LLM consult on the ambiguous, and a tier-3 behavioral verifier that exercises a changed tool to clear or refute the change - but each is held off by default and requires explicit opt-in; the default build egresses nothing and stays fail-closed. When enabled, the behavioral tier clears or refutes a contract change; it is not a proof of safety, and confidence is reported but not yet calibrated (calibrated=false at v1).
• · Fail-closed. A tool with no pin, an unreadable contract, or a diff the gate cannot complete holds rather than proceeds. The gate never silently allows what it could not verify.

The in-path gate catches a change the first time you see it. The drift network catches it before you do. mcpindex crawls the public MCP registry every day, re-derives each tool’s contract, and records every silent change as a fingerprint-only entry. When you pin a tool, the gate can ask the network one question: has the crawler already caught this contract drifting? If it has, you are warned on the first call - a contract-diff advisory that rides alongside the verdict and never moves PROCEED or HOLD. Every drift the crawler catches is public in the drift ledger.

• · Crawler-corroborated, not crowd-sourced. The public corroboration count floors at the crawler (one first-party source); forgeable install reports are excluded from the public number. The warning is real today because the crawler sees the drift, not because other installs reported it.
• · Opt-in, privacy-by-construction. Off by default. When enabled, the only thing that leaves is a salted (HMAC) fingerprint plus closed-vocabulary fields (change type, safety flag, hour-rounded time) - never a schema, argument, description, URL, or server/tool name. Fail-open: it never blocks or changes a call.
• · Advisory, never the decision. The fleet advisory informs; the gate’s deterministic contract-diff still decides. The network can raise your attention; it cannot move a PROCEED or a HOLD.
• · Tool removals counted (as of 2026-07-19). The ledger also records when a tool present in one snapshot is absent from the next, scoped to servers reachable in both (a server going offline is never counted as removals). Earlier totals exclude removals. Most removals arrive as full toolset replacements rather than single-tool deletions, and the ledger labels them so. Removal entries are historical observations - a same-named tool may have since returned.

The directive an agent reads is one of three decisions, on top of a status that says how the eval went. Together they are four states an agent must distinguish.

• ALLOW
  decision (roadmap)

  The eval ran end-to-end and the tool cleared its checks at the recorded clearance level; the agent may invoke within that clearance until expires_at. Not produced at v1: a clearing ALLOW requires the behavioral conformance probe, gated to the D3 labeled-corpus milestone. Today the screen emits REVIEW or UNVERIFIED only.

• DENY
  decision (roadmap)

  The eval ran end-to-end and a finding crossed the deny threshold (high-severity intent flag, conformance regression, or a poisoned description); the agent should not invoke. Reserved in the contract; at v1 a high-severity finding surfaces as REVIEW for human adjudication rather than an automatic public DENY.

• REVIEW
  decision

  The eval ran but produced ambiguous or partial findings (e.g. medium-severity flag, partial conformance, provider disagreement). Surfaces the dimension findings; agent should defer to a human or fall back to its own checks.

• UNVERIFIED
  status

  No verdict on file for this tool yet (the wire term the trust API returns when a tool has not been screened). The agent should NOT infer trust; treat as not-yet-cleared. Coverage rolls out as the corpus expands (adversarial cases first).

• · Definition, not runtime. The eval is bound to the tool definition (description + schema) at evaluation time. Runtime behavior on a specific call is not covered.
• · Conformance built, not yet run; monitored, not enforced. The deterministic conformance probe has not run on the public corpus, so no published screen verdict carries a conformance result today. When it runs, a conformance result is reported in the verdict and the public surface, not enforced on the wire.
• · OTS cadence bound = confirmation latency. The OTS anchor proves the verdict existed by some Bitcoin block; it does not prove minute-level ordering inside the confirmation window.
• · calibrated = false at v1. Confidence scores are reported but not calibrated against a held-out adversarial corpus yet.
• · Advisory, not blocking. mcpindex publishes the verdict. The agent or IDE decides whether to act.
• · D3 graduation gate. >=150 conforming labels with FP upper-95 <=2%. Current: 15/150.

The honest-limits list is a contract. If any of these stops being true, the methodology page changes first, the verdict surface changes second, and the network only sees the upgrade after both.

The trust verdict answers “does this tool behave as it claims.” The directory still answers a simpler question: which servers look mature from public registry signal. The 0-100 MCP Quality Score is a public-data composite (freshness, completeness, installability, documentation, semver stability) and remains the secondary axis on every page. Source: lib/quality.ts.

"mcpindex: the in-path trust gate for agent tool calls." mcpindex.ai/methodology, 2026.
https://mcpindex.ai/methodology

Or just link to a server's detail page. The verdict surface and the score breakdown both render there.