Skip to main content
Glama
Sign In

Checkbox

by site.checkbox
OverviewDiscussionsAdmin

Get a test run (steps, observations, fixes)

get_test_run
Read-onlyIdempotent

A synthetic test subscription with every step (checkout, acknowledgment email, reminders at each legal window, cancellation, confirmation): what was observed, check results, evidence ids and fixes. While running, next_action.type is "wait" and waiting_for says what it waits for (pass wait: 30 to get the answer as soon as the run moves on). When finished, apply the fixes (usually via get_compliance_plan) and start another run to verify. Without test_run, returns the newest run of the site.

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": "get_test_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteNoSite id (site_…). Optional when the account has exactly one site in this mode; list_sites shows them.
waitNoLong-poll: wait up to this many seconds for the run to move on before answering.
test_runNoTest run id (run_…). Default: the newest run of the site.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / wait
      Added value: +{
+  "description": "Long-poll: wait up to this many seconds for the run to move on before answering.",
+  "maximum": 30,
+  "minimum": 0,
+  "type": "integer"
+}
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavior beyond them: the long-poll semantics of wait, the next_action.type of "wait" plus waiting_for during a run, and the fallback that omitting test_run returns the newest run of the site. It stops short of describing pagination or size limits on the returned step/evidence data, so a 4 rather than 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.

Conciseness4/5

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

Dense but front-loaded: the returned payload is described first, then the in-progress wait behavior, then the finished-state next steps, then the default. Every clause carries information, though the opening is a sentence fragment and the parenthetical step list makes the first sentence long.

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?

There is no output schema, so the description carries the burden of explaining returns, and it does so by naming the step set, observations, check results, evidence ids, fixes, and the next_action/waiting_for state fields. It is nearly complete for a read tool of this complexity, with only minor gaps around the shape of individual step objects and any result limits.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining what wait actually buys the caller ('get the answer as soon as the run moves on') and by reinforcing that no test_run id yields the site's newest run. It adds intent-level meaning rather than restating the schema.

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 (a synthetic test subscription run) and enumerates exactly what it returns: each step (checkout, acknowledgment email, reminders, cancellation, confirmation), observations, check results, evidence ids and fixes. This clearly separates it from start_test_run on the sibling list. The retrieval verb itself is only implied by the name/title rather than stated, which keeps it just short of 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 Guidelines4/5

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

It gives concrete operational routing: pass wait: 30 while the run is in progress to get the answer as soon as it moves on, and when finished, apply fixes 'usually via get_compliance_plan' then start another run to verify. That names the relevant siblings and the conditions that select them. What is missing is guidance on when to call this at all versus get_scan or get_verification for non-test state.

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

All Checkbox toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources