Skip to main content
Glama
Sign In
falsepass

falsepass

by Super-Eric
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

falsepass_audit_status

Polls a background audit or reach job by waiting up to 600 seconds, then returns results if finished, progress if running, or an error with log details if failed.

Instructions

Wait up to wait seconds (max 600) for the job started by falsepass_audit or falsepass_reach, then return its results (status "finished") or progress (status "running": call again). A failed job is returned as an error with the end of its log.

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

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)
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.2/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 well: it discloses the blocking-wait behavior, the 600-second cap, the two return states (finished/running), the need to re-poll, and that failures surface as an error carrying the tail of the log. It omits details on whether job state persists across calls or how results are shaped, keeping it short of a 5.

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

Conciseness5/5

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

A single dense sentence with the wait semantics front-loaded and the outcome states packed into parentheses; no filler or redundancy.

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 polling tool with no output schema and no annotations, the description covers the essential behavior: what it waits for, the timeout ceiling, the possible return states, and the error case. Return-value structure is left implicit, which is a minor gap rather than a blocking one.

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 all three parameters are already documented, and the description's mention of `wait` (max 600) largely repeats the schema. The `env` and `workdir` parameters are not elaborated in the description at all, so it adds little beyond the structured fields.

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 a specific action (wait for the job, then return results/progress) and ties it to the two sibling tools that start such jobs (falsepass_audit, falsepass_reach). An agent can tell this is the status/polling endpoint for a background audit job 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 gives clear usage context: call this after starting a job, and if status is "running", call again. It does not address when to prefer falsepass_results or falsepass_completion instead, so the routing guidance is helpful but not exhaustive.

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

Deploy Server

Other Tools