Skip to main content
Glama

falsepass_init

Initializes an audit directory for a specified RL environment and returns its audit name, so agents can start probing for false passes and false fails.

Instructions

Set up audits// for an environment and return the name to audit it with.

target: a Prime Hub slug (owner/environment), a Python file of reward functions written for TRL's GRPOTrainer (def accuracy_reward(completions, solution, **kwargs); or a module name such as trl.rewards with framework "reward") together with dataset (a .jsonl/.json/.csv/.parquet file, hf:owner/name, or call:function in the file; optional functions, weights, split, dataset_config, answer_column, prompt_column, map (a row mapper in the file), path (folders put on sys.path for a package that is imported rather than installed, e.g. a clone's src)), an OpenEnv Space (hf:owner/space, cloned next to the audit) or folder (openenv.yaml), a local folder with a pyproject.toml (verifiers or Inspect project), an Inspect task file, an Inspect registry name (inspect_evals/gsm8k), or a HUD environment folder. Options: name (folder name, default from the environment), version (Hub version), framework ("verifiers", "openenv", "reward", "inspect" or "hud" when detection is wrong), task (Inspect: which @task), answers (HUD and OpenEnv: path to a JSON file of reference answers, an object from task key to answer or a list in task order; without it only answer-free probes run, unless an OpenEnv task record carries an answer field), extra (more requirements to install, e.g. ["inspect-evals[math]"]; added to the environment's own), without (requirement names to drop from the environment's own, e.g. a pin that does not resolve), env_class / action_class (OpenEnv, "module:Class": the environment class or factory and the action class when detection picks the wrong one), manual (also write an adapter.py skeleton for a Q&A environment automatic mode cannot script), policies (the same for games, simulations and tool tasks: a skeleton built around policies; use it when an audit comes back "inconclusive", or for a verifiers v1 tool taskset once the automatic run of generic tool policies is done, to add a solver as the control and task-aware exploits; v1 episodes run through the taskset's own loop; for an OpenEnv MCP tool environment, or one whose reward comes after several steps, the policies play whole episodes through its reset() and step()), force (rewrite an existing audit's env.toml, e.g. to add answers; adapter.py is kept).

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": {
      "target": "<target>"
    },
    "name": "falsepass_init"
  }
}

Input Schema

NameRequiredDescriptionDefault
mapNoreward functions: a row-mapping function in the file
nameNofolder name under audits/ (default: from the environment)
pathNofolders put on sys.path for a package that is imported rather than installed, e.g. a clone's src
taskNoInspect: which @task of the file
varsNoenvironment variables the environment reads, set on every run, e.g. {"DATA_PATH": "/abs/path/data"} (a relative path is taken from workdir)
extraNomore requirements to install, e.g. ["inspect-evals[math]"]
forceNorewrite an existing audit's env.toml (adapter.py is kept)
splitNoreward functions: the dataset split
manualNoalso write an adapter.py skeleton, for a Q&A environment automatic mode cannot script
targetYeswhat to audit: a Prime Hub slug owner/environment, an OpenEnv Space hf:owner/space, a local folder, an Inspect task file or registry name, a HUD folder, or a file or module of reward functions (with `dataset`)
answersNoHUD and OpenEnv: a JSON file of reference answers (task key to answer, or a list in task order)
datasetNoreward functions: a .jsonl/.json/.csv/.parquet file, hf:owner/name, or call:function in the file
versionNoHub version to install (default: the latest)
weightsNoreward functions: one weight per function
withoutNorequirement names to drop from the environment's own, e.g. a pin that does not resolve
workdirNothe folder whose audits/ holds the audits (default: the current directory).
policiesNowrite a policy-based adapter.py skeleton, for a game, simulation or tool task
env_classNoOpenEnv: "module:Class", the environment class or factory, when detection picks the wrong one
frameworkNo"verifiers", "openenv", "reward", "inspect" or "hud", when detection is wrong
functionsNoreward functions: the functions of the file to use (default: all)
action_classNoOpenEnv: "module:Class", the action class
answer_columnNoreward functions: the dataset column that holds the reference answer
prompt_columnNoreward functions: the dataset column that holds the prompt
dataset_configNoreward functions: the Hugging Face dataset config name

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.15.0

TDQS

A4/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 discloses substantial behavior: directories and adapter skeletons are written, OpenEnv Spaces are cloned, requirements can be added or dropped, and `force` rewrites `env.toml` while preserving `adapter.py`. It also explains that omitting `answers` generally limits execution to answer-free probes. Credentials, network access, failure handling, and partial-setup behavior remain unspecified.

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

Conciseness2/5

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

The purpose is front-loaded, but the remainder is one extremely dense paragraph with deeply nested parenthetical clauses covering nearly every option. Much of it duplicates the fully documented schema, and the lack of bullets or sections makes the otherwise useful reference difficult to scan.

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 complex 24-parameter setup tool without annotations or an output schema, the definition covers accepted inputs, generated artifacts, important fallback modes, overwrite behavior, and the returned audit name. It is sufficient for most invocations, but operational prerequisites, failure semantics, and an explicit handoff to the relevant sibling workflow would make it more complete.

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

Parameters5/5

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

Although schema coverage is 100%, the prose adds meaningful semantics beyond it, especially the many accepted `target` forms and combinations required for reward-function targets. The `policies` guidance explains concrete adaptation scenarios and episode behavior, while `answers`, `extra`, `without`, and `force` receive useful consequences and examples rather than mere restatement.

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 opening sentence clearly states the verb and resource: it sets up `audits/<name>/` for an environment and returns the name needed to audit it. The extensive target list further clarifies what can be initialized, but the description does not explicitly distinguish this tool from siblings such as `falsepass_audit` or `falsepass_discover`.

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 gives unusually specific situational guidance: override `framework` when detection is wrong, use `manual` when automatic Q&A adaptation fails, use `policies` for specified task types or after an inconclusive audit, and use `force` to rewrite an existing configuration. However, it does not explicitly explain when initialization is unnecessary or name a sibling tool for discovery, auditing, or inspecting an existing setup.

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