Skip to main content
Glama

falsepass_reach

Counts how many tasks a failing probe reaches and how often completions fail or earn full reward, after an audit, using selected probes, templates, or a task sample.

Instructions

After an audit: how many tasks a failing probe reaches. Scores only the rows asked for, e.g. probe=["P15/denied"] (a code, or code/variant as in the results), plus the reference (P1) as a control, on every task (tasks=0) or a sample of tasks. templates counts completions of your own instead of writing a script (rows U1/t1, t2, ...): "{answer}", "{wrong}", "{answer_in_format}" and "{wrong_in_format}" are filled per task, other braces stay, e.g. "\boxed{{answer} \text{ is wrong}}"; expect "zero" counts where they are paid, "full" where they are not paid in full. Each template row also returns first_completion, the text it became on the first task. Returns per row the tasks counted, how many failed (expected 0: paid; expected full: not paid in full), full-reward and error counts, the failing task keys and up to three failing completions. Per-example probes only (P1-P9, P13-P17, A1, X1). Runs in the background like falsepass_audit: status "running" means call falsepass_audit_status. Whole datasets whose reward starts a process per call (uv scripts) take minutes to an hour.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "env": "<env>"
    },
    "name": "falsepass_reach"
  }
}

Input Schema

NameRequiredDescriptionDefault
envYesthe audit's name as falsepass_init returned it: the folder under workdir/audits/
waitNoseconds to wait for the background job before returning its progress instead (max 600)
probeNoprobe rows to count, e.g. ["P15/denied"] (code, or code/variant as in the results)
tasksNohow many tasks to score (0 = every task in the dataset)
expectNofor templates: "zero" counts where they are paid, "full" where they are not paid in fullzero
sourceNotake the environment from this patched copy (relative to workdir)
offlineNoread Hugging Face datasets from the local cache without checking the Hub first: seconds saved per run once the data is cached (a dataset not cached yet fails to load)
workdirNothe folder whose audits/ holds the audits (default: the current directory).
templatesNocompletions of your own to count, with {answer}, {wrong}, {answer_in_format} or {wrong_in_format} filled per task

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.15.0

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does substantial work: it discloses background execution, the 'running' status handoff to falsepass_audit_status, and a realistic runtime warning (minutes to an hour for uv-script datasets). It also states the return payload shape (tasks counted, failure counts, full-reward and error counts, failing task keys, up to three failing completions), though it does not discuss cost, caching, or failure modes beyond the runtime note.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded, but the body is a dense run-on of semicolon-joined clauses mixing probe syntax, template placeholders, expect semantics, return shape, and runtime caveats. Every sentence carries information, yet the lack of structure makes it harder to scan than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with no output schema and no annotations, the description covers the essential ground: what is counted, how rows are selected, what is returned, and how background execution is handled. Minor gaps remain around the source/offline/workdir parameters and error behavior, but nothing critical to a correct call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: the probe row syntax ('P15/denied', code or code/variant), that tasks=0 means every task, the template placeholder vocabulary ({answer}, {wrong}, {answer_in_format}, {wrong_in_format}) with an escaping example, and the 'zero' vs 'full' semantics of expect. The source, offline, and workdir parameters are left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: counting how many tasks a failing probe reaches after an audit, which is clearly distinct from falsepass_audit (which presumably runs the audit). It never names a sibling explicitly, so differentiation is implied by the 'after an audit' framing rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It establishes the precondition ('After an audit') and the operational context (runs in the background; status 'running' means call falsepass_audit_status), which routes the agent correctly. It also bounds scope with 'Per-example probes only (P1-P9, P13-P17, A1, X1)', but gives no explicit when-not-to-use guidance versus falsepass_results or falsepass_audit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.