Skip to main content
Glama

falsepass_audit

Installs an environment in a throwaway virtualenv and scores known-good and known-bad completions to detect false passes and false fails before training. Runs in the background; check progress with its status tool.

Instructions

Probe one environment set up with falsepass_init: installs it in a throw-away virtualenv and scores known-good and known-bad completions with its own reward code.

Takes from under a minute to several minutes, so it runs in the background: this call waits up to wait seconds (max 600). If the audit is done, it returns the headline numbers, the failing probes with one example completion each, and static hints (status "finished"); otherwise {"status": "running", ...}: then call falsepass_audit_status. Calling it again while an audit of env runs does not start a second one. n is the number of tasks sampled; search > 0 adds mutation search (scorer calls per direction and example; 120 is a good value). source installs the environment from a local folder (a patched copy, relative to workdir) instead of its release: the whole probe suite against a fix.

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

Input Schema

NameRequiredDescriptionDefault
nNotasks sampled from the dataset (default 25)
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)
searchNomutation search: scorer calls per direction and task (0 = off; 120 is a good value)
sourceNoinstall the environment from this local folder (a patched copy, relative to workdir) instead of its release
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?

With no annotations, the description carries the full burden and does it well: it discloses non-trivial latency (under a minute to several minutes), the background-job model, the up-to-600-second wait cap, the two possible return shapes (finished with headline numbers/failing probes/hints vs running), and de-duplication of concurrent calls. It omits failure modes (nonexistent env, install failure) and whether results persist for later retrieval, which keeps it out of the top band.

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 behavior and the wait/background caveat are front-loaded, and most sentences carry real information. The final clause about `source` is a fragment ('the whole probe suite against a fix') that reads as a dangling note, and the description is dense enough to warrant a tighter structure.

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 7-parameter tool with no output schema and no annotations, the description covers what the agent needs: what it produces on both branches, how long it may take, and how to continue. Only edge cases (missing env, install failure, whether finished results are retrievable elsewhere) are left unaddressed.

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 every parameter is already documented in structured data; the baseline is 3. The prose repeats rather than extends that documentation (`n` is tasks sampled, `search` adds mutation search, `source` installs from a local folder), adding only light context such as the 'whole probe suite against a fix' framing.

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 description names the specific action (probe/audit one environment), the object (an env created by falsepass_init), and the mechanism (install in a throw-away virtualenv, score known-good and known-bad completions with its own reward code). It also implicitly separates this from falsepass_init (setup) and points at falsepass_audit_status for polling, so an agent can place it among siblings without opening schemas.

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?

Clear routing guidance is given: if the result is {"status": "running"}, call falsepass_audit_status, and calling again while an audit runs does not start a second one. Guidance is also given for the optional knobs (search > 0 for mutation search, source for a patched local copy). It stops short of saying when to prefer this over verification/results siblings, but the invocation context is unmistakable.

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