Screen

Screen an MCP tool.

Paste a tool description. An LLM judge reads it for hidden instructions - the kind that tell an agent to read a secret file, exfiltrate data, or follow a buried command - and flags the exact line.

Building an MCP server? Run yours through it before you publish. It is the same screen whether you own the tool or are deciding whether to trust it. The verdict on your server page comes from the registry screener, which reads only the registry's short description with a smaller model, so the two can differ.

POST  /api/v1/screen

Sent to an LLM judge for screening. Avoid pasting real secrets.

try
What this is - and isn't
  • Advisory and semantic-only. We read the description, not the running tool. This screen does not run the deterministic conformance probe, so findings here are labeled PARTIAL.
  • A pass is not a safety guarantee.It means the description isn't lying - not that the tool is safe to grant access to. A high-capability tool with an honest description still warrants caution.
  • Not a certification or a badge. Screening your own tool does not get it endorsed, listed, or ranked higher. We publish what the judge finds, including a finding that flags your own tool, and the verdict is the same one a user evaluating your tool would get. We screen tools; we don't sell them a verdict.
  • Your input isn't storedunless you check “Contribute this example.” See privacy and how a finding is produced.
Two verdict surfacesTwo surfaces emit verdicts and they are separate axes. The advisory screen, read before you wire a tool, is semantic-only and out of the call path: REVIEW and UNVERIFIED are produced today, while ALLOW and DENY are reserved in the contract and not produced at v1, because the behavioural conformance probe a clearing ALLOW would need is advisory and uncalibrated in v1. The in-path gate emits HOLD when the live contract differs from your pin and PROCEED when it matches. The screen is a prior; the gate is the decision.ADVISORY SCREEN · BEFORE YOU WIREDID THE EVAL RUN?YESNOclearedcrossed the deny thresholdambiguous or partialno eval on fileALLOWRESERVEDDENYRESERVEDREVIEWPRODUCED AT V1UNVERIFIEDPRODUCED AT V1IN-PATH GATE · DURING THE CALLHOLDthe live contract differs from what you pinned→ PROCEEDthe live contract matches your pinDETERMINISTIC · FAIL-CLOSED · IN THE CALL PATHALLOW and DENY are reserved in the contract, not produced at v1. The conformance probeis advisory and uncalibrated in v1 (calibrated=false), so the screen never clears a tool.Neither surface overrides the other. The screen is a prior; the gate is the decision.
Fig. 09 · The screen verdict and the gate verdict are different axes. Neither overrides the other.
Read Fig. 09 as text
  ADVISORY SCREEN (before you wire)      |  IN-PATH GATE (during the call)
  -------------------------------------  |  --------------------------------
              eval ran?                  |
              yes         no             |   |- HOLD     the live contract differs
   cleared    ALLOW       .              |               from what you pinned
              reserved                   |
   crossed    DENY        .              |   -> PROCEED  the contract matches
              reserved                   |
   ambiguous  REVIEW      .              |  deterministic. fail-closed.
              live                       |
       none   .           UNVERIFIED     |
                          live           |
  -------------------------------------  |  --------------------------------
  semantic, advisory, out of path        |  in-path, can actually stop the call

  ALLOW and DENY are reserved in the contract, not produced at v1. the
  conformance probe is advisory and uncalibrated in v1 (calibrated=false), so the
  screen never clears a tool. neither surface overrides the other - the
  screen is a prior, the gate is the decision.

Permalink, SVG & reuse · CC BY 4.0