Skip to main content
Glama
Sign In
falsepass

falsepass

by Super-Eric
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

falsepass_discover

Find recently updated RL environments on Prime Intellect Hub or Hugging Face OpenEnv Spaces to select targets for auditing verifier false passes and false fails.

Instructions

Recently maintained environments: hub "prime" (the Prime Intellect Hub, with what each needs: sandbox, tools, LLM judge, API key, an outside service its code calls, reference answers; needs the prime CLI) or "hf" (OpenEnv Spaces on the Hugging Face Hub, most liked first, each with the hf:owner/space target for falsepass_init; the public listing only).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "falsepass_discover"
  }
}

Input Schema

NameRequiredDescriptionDefault
hubNo"prime" (the Prime Intellect Hub; needs the prime CLI) or "hf" (OpenEnv Spaces on the Hugging Face Hub)prime
daysNoenvironments updated within this many days
limitNoat most this many environments
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

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose useful behavior — hf results are ordered 'most liked first' and cover 'the public listing only' (a scope limitation), and prime requires the `prime` CLI. It does not say whether results are paginated, whether auth is needed for either hub, or how the two hub listings relate to the `days` window for hf.

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

Conciseness3/5

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

It is compact, but the heavily nested parenthetical asides make it hard to parse on first read, and the hub descriptions bury the lead. The core idea (list recently maintained environments from one of two hubs) could be front-loaded more sharply.

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 4-parameter, all-optional discovery tool with a fully described schema and no output schema, the definition covers the hub choice adequately but leaves the result shape vague — it only states that hf entries carry an `hf:owner/space` target, without describing what a prime entry looks like or how `limit`/`days` surface in the output.

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 baseline is 3. The description restates the `hub` semantics (prime vs hf, CLI requirement) and loosely frames `days` as 'recently maintained', but adds no syntax or behavioral detail beyond what the schema already documents for `days`, `limit`, and `workdir`.

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 identifies the resource clearly: "Recently maintained environments" drawn from two hubs, with the `prime` hub needing the CLI and `hf` listing OpenEnv Spaces. It also distinguishes the two modes precisely. It stops short of a clean verb-and-scope statement (no explicit 'list/discover environments updated within N days'), so it is clear but slightly less crisp than a 5.

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: the mention of the `hf:owner/space` target 'for falsepass_init' hints this is a pre-init discovery step, but there is no explicit 'use this before X, use Y instead' guidance and no exclusions relative to siblings like falsepass_scan or falsepass_upstream.

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