Skip to main content
Glama

plot_rank_bootstrap

Plot bootstrap rank-test diagnostics by showing LR* histograms, observed LR, and 90/95/99% critical values for each r→r+1 comparison from a finished rank test or job.

Instructions

FIGURE — The rank test's bootstrap: for each comparison r -> r + 1, the histogram of the B bootstrap statistics LR*, the OBSERVED LR (solid), the bootstrap's 90/95/99 % critical values (dashed) and, for cases 1 and 2, the asymptotic 5 % value (dotted: orientation only). From the finished rank test of the current specification (the one with the largest B), or job_id's. Read from the job's .boot file with drvec's own reader.

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

Input Schema

NameRequiredDescriptionDefault
nameYes
pathNo
job_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3/5.0
Behavior3/5

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

With no annotations, the description does useful work: it names the data source (the job's .boot file, read by drvec's own reader) and the state dependency (a completed rank test). It is silent on the write profile, where the figure is emitted, and what is returned, which matters for a tool that presumably produces an output file.

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?

The key artifact is front-loaded via the 'FIGURE —' lead, but the single sentence is dense, jargon-heavy (LR*, r -> r + 1, cases 1 and 2, B) and stacks several clauses without breaks. It is information-rich but not scannable.

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

Completeness2/5

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

For a 3-parameter tool with no annotations and no output schema, the description should explain the return artifact and the path/name roles. It covers provenance well but leaves the agent unsure what it gets back and how to direct the output.

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

Parameters2/5

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

Schema coverage is 0%, so the description carries full burden. It explains job_id as an alternative source, but never says what 'name' identifies (the specification? the comparison?) nor what 'path' controls, leaving two of three parameters undocumented anywhere.

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 'FIGURE —' prefix plus the body states a specific artifact: a histogram of B bootstrap LR* statistics per comparison r -> r + 1, with observed LR and 90/95/99% critical value overlays. That distinguishes it from the sibling rank_test (which computes the test) and from other plot_* siblings. It loses a point only because no explicit verb ('plot', 'write PNG') ever appears.

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?

It states the prerequisite that a rank test must be finished, and gives a selection rule when several exist ('the one with the largest B'), plus the job_id alternative. It never says when an agent should prefer this over rank_test or other diagnostics, and no exclusions are given.

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