Testsy

Wait for a run

wait_run

Read-only

Wait up to seconds (default 25, at most 55) for a run to finish, then return it: one call instead of polling get_run every few seconds. Call it again while final is false. The answer comes back the moment the run is final (verdict, checks and evidence in), or when the time is up with final false — then call wait_run again. Runs take 2 to 20 minutes, so expect several calls for a long run; each costs nothing while it waits.

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

Input Schema

Name	Required	Description	Default
`runId`	Yes	Run id (j_…)
`seconds`	No	How long to wait at most, 1–55 (default 25)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint=false; the description adds the operationally important traits: default and maximum wait (25/55), the two return states (final true with verdict/checks/evidence, or final false on timeout), typical run duration of 2–20 minutes, and that the wait costs nothing. That is exactly the behavioral context annotations cannot express.

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?

Front-loaded with the core behavior and kept to a tight paragraph, with the timeout/retry loop stated clearly. Minor redundancy between 'Call it again while final is false' and 'then call wait_run again,' but nothing is wasted.

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

Completeness5/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 return-value burden itself and does: it explains the final flag, what is included when final, and what happens on timeout. Combined with the retry loop and duration expectations, an agent has everything needed to drive this tool correctly.

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 coverage is 100% and the schema already documents both parameters including the 1–55 range and default of 25, so the description's restatement adds little. Its only added meaning is contextual: runs take 2–20 minutes, which implies the wait will usually time out before completion. Baseline 3 applies.

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?

States a specific verb (wait) and resource (run), plus the exact semantics: waits up to N seconds for a run to finish, then returns it. It also distinguishes itself from the sibling get_run by framing itself as 'one call instead of polling get_run every few seconds.' An agent can pick between them without opening either schema.

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

Usage Guidelines5/5

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

Explicitly names the alternative (polling get_run) and the condition that selects this tool, then gives a full usage loop: 'Call it again while final is false' and 'when the time is up with final false — then call wait_run again.' It even sets expectations for long runs ('expect several calls').

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

All Testsy tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.