Skip to main content
Glama

falsepass_repro

Writes a standalone script to re-score exact failing completions using the environment’s packages; optionally runs it twice in fresh virtualenvs to verify identical, reproducible output.

Instructions

Write audits//repro_auto.py: a script that depends only on the environment's own packages and re-scores the exact failing completions. probe limits it to some probes, e.g. ["P5"] or ["X1/denies_both_figures"] (code/variant). Identical output from two clean runs is what makes a lead reproducible: with run=true the script is also run twice, each in a fresh virtualenv, in the background like an audit (status "running": call falsepass_audit_status). The result says whether the runs were identical, where the first is stored (headed by its command), and how many cases still fail. script runs an existing script in the audit folder instead (e.g. a hand-written repro.py).

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_repro"
  }
}

Input Schema

NameRequiredDescriptionDefault
envYesthe audit's name as falsepass_init returned it: the folder under workdir/audits/
runNotrue: also run the script twice in fresh virtualenvs and compare (in the background)
waitNoseconds to wait for the background job before returning its progress instead (max 600)
probeNolimit the script to these probes, e.g. ["P5"] or ["X1/denies_both_figures"] (code, or code/variant)
scriptNorun an existing script in the audit folder instead, e.g. repro.py
sourceNowith run=true: take the environment from this patched copy (relative to workdir); its output is stored apart from the unpatched one
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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.15.0

TDQS

A4.1/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden and does substantial work: it discloses that a file is written at a specific path, that run=true spawns two fresh virtualenvs in the background with status 'running', and that results report identity of runs, storage location, and remaining failure count. It does not say whether an existing repro_auto.py is overwritten, nor how long virtualenv setup takes, which are the main residual gaps.

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

Conciseness4/5

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

The core action is front-loaded in the opening sentence, and the explanatory clause about identical output making a lead reproducible earns its place by justifying run=true. Some sentences are long and parenthesis-heavy, and the trailing `script` sentence would read better next to the run/script discussion, but there is no filler.

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 an eight-parameter, no-annotation, no-output-schema mutation tool, the description covers the essential mechanics: the produced file, background execution, status polling, and the shape of the returned result. It leaves the `wait`, `offline` and `workdir` parameters entirely to the schema, which is acceptable given full schema coverage.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all eight parameters, including wait, source, offline and workdir that the description never mentions. The description reinforces `probe` with code/variant examples and clarifies the run/script interaction, but adds little beyond what the schema states, so the baseline 3 is appropriate.

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

Purpose5/5

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

The first clause names a specific verb and artifact: 'Write audits/<env>/repro_auto.py: a script that ... re-scores the exact failing completions.' It also carves out the scope boundary from the script-running mode ('`script` runs an existing script in the audit folder instead'), so an agent can tell the two behaviors apart without opening the schema.

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 explains the key routing condition: the script is written always, but reproducibility verification only happens with `run`=true, and an existing hand-written script should be supplied via `script` instead. It also tells the agent where to poll for the background job (falsepass_audit_status). No explicit 'do not use this for X' exclusion is given, so it falls short of a full 5.

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