Skip to main content
Glama
Sign In
falsepass

falsepass

by Super-Eric
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

falsepass_results

Retrieve the latest finished probe run for an environment, including its headline, failing probes, and static hints, or running job progress when no run has completed.

Instructions

The last finished probe run of an environment (headline, failing probes, static hints). While a job runs on it, the same digest with the job's progress under job (the progress alone when nothing has finished yet).

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

Input Schema

NameRequiredDescriptionDefault
envYesthe audit's name as falsepass_init returned it: the folder under workdir/audits/
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

A3.6/5.0
Behavior4/5

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

With no annotations and no output schema, the description carries the full burden, and it does disclose genuinely non-obvious behavior: the response shape is state-dependent, returning the digest plus job progress under `job` while a job runs, or progress alone when nothing has finished. What it omits is the failure mode (what happens when an environment has no runs at all) and any explicit statement of read-only, side-effect-free behavior.

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?

Two sentences with no filler, and the primary purpose is front-loaded before the conditional case. The second sentence is dense with nested parentheses and takes a re-read, but every clause conveys real information about the response shape.

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

Completeness3/5

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

For a two-parameter read tool with full schema coverage and no output schema, the description covers what comes back in the running and idle states, which is the main gap. It stops short of describing the no-data case or clarifying its boundary against the status-related siblings, leaving an agent to discover edge behavior by calling it.

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%, and both `env` and `workdir` are already well documented in the schema, including how `env` relates to workdir/audits/. The description adds no further parameter meaning, so the baseline of 3 applies.

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 names the resource precisely — the last finished probe run of an environment — and enumerates what the digest contains (headline, failing probes, static hints). It is clear enough for an agent to know it retrieves a result digest rather than triggering a run, though no verb is stated outright and no sibling (e.g. falsepass_audit_status or falsepass_completion) is named as the contrast case.

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

Usage Guidelines3/5

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

Usage is only implied: an agent can infer it should call this to inspect an environment's most recent completed probe run. There is no explicit when-to-use versus when-not-to-use guidance and no routing to a sibling for live status or completion checks, even though several siblings plausibly overlap.

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