Crevio

wait_for_run

Read-onlyIdempotent

Wait for a run to settle (completed, failed, or needs_input) and return it with the agent's final reply. If it is still running when the wait ends, the reply has wait_timed_out: true — call wait_for_run again.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`run_id`	Yes	A run id (trun_...).
`timeout_seconds`	No	How long to wait for the run to finish before returning. Defaults to, and is capped at, 300 s when your client accepts a streamed reply (text/event-stream), 90 s otherwise. The run keeps going when the wait ends first.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`object`	Yes
`result`	No
`reused`	No
`status`	Yes
`chat_id`	No
`summary`	No
`task_id`	Yes
`next_step`	No
`task_name`	No
`created_at`	Yes
`started_at`	No
`completed_at`	No
`error_message`	No
`wait_timed_out`	No	The wait ended first. The work is still running: follow it with the tool next_step names.
`credits_consumed`	No
`pending_approval_ids`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 29, 2026

changedInput schema / properties / timeout_seconds / description

Previous value: -"How long to wait for the run to settle before returning (default 60, max 90). On wait_timed_out, call wait_for_run with the run id."New value: +"How long to wait for the run to finish before returning. Defaults to, and is capped at, 300 s when your client accepts a streamed reply (text/event-stream), 90 s otherwise. The run keeps going when the wait ends first."

changedInput schema / properties / timeout_seconds / maximum
```
Previous value: -90New value: +300
```
addedOutput schema / properties / next_step
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / wait_timed_out

Added value: +{
+  "description": "The wait ended first. The work is still running: follow it with the tool next_step names.",
+  "type": "boolean"
+}

Changed1 schema field changedSep 22, 2026

changedOutput schema / properties / status / enum

Previous value: -[
-  "pending",
-  "running",
-  "completed",
-  "failed",
-  "needs_input",
-  "timed_out",
-  "unknown"
-]New value: +[
+  "pending",
+  "running",
+  "completed",
+  "failed",
+  "needs_input",
+  "timed_out",
+  "unknown",
+  "skipped"
+]

Changed1 schema field changedSep 6, 2026

changedOutput schema / properties / status / enum

Previous value: -[
-  "pending",
-  "running",
-  "completed",
-  "failed",
-  "needs_input",
-  "timed_out"
-]New value: +[
+  "pending",
+  "running",
+  "completed",
+  "failed",
+  "needs_input",
+  "timed_out",
+  "unknown"
+]

Changed1 schema field changedSep 2, 2026

changedOutput schema / properties / status / enum

Previous value: -[
-  "pending",
-  "running",
-  "completed",
-  "failed",
-  "needs_input"
-]New value: +[
+  "pending",
+  "running",
+  "completed",
+  "failed",
+  "needs_input",
+  "timed_out"
+]

First observedAug 22, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, so the remaining burden is behavioral detail, which the description supplies: the run keeps going after the wait ends, and a still-running result is flagged with wait_timed_out: true. It does not mention auth or rate-limit considerations, but for a read-only wait tool that is minor.

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

Conciseness5/5

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

Two sentences, front-loaded with the blocking condition and terminal states, then the timeout escape hatch. Every clause carries distinct information with no repetition.

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?

For a two-parameter wait tool with a full output schema and clear safety annotations, the description covers the essential loop semantics (what terminal states look like, what to do on timeout). Nothing an agent needs to invoke it correctly is missing.

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%: both run_id and timeout_seconds (including the 300 s streamed vs 90 s non-streamed cap and the default) are fully documented in the schema. The description only alludes to the wait ending, adding no syntax or semantics beyond the schema, so the baseline 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 states a specific verb (wait) and resource (run), plus the terminal states it waits for (completed, failed, needs_input) and what it returns (the agent's final reply). It does not explicitly contrast with the sibling get_run, which returns the current state without blocking, so differentiation is implicit rather than stated.

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 tells the agent what to do when the wait ends without settlement — 'call wait_for_run again' — which is actionable usage guidance for the blocking loop. It stops short of naming the non-blocking alternative (get_run) or saying when polling is preferable.

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

All Crevio tools Inspect

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

Need Help?