Wait for a research run to finish or need attention, with an optional timeout up to 30 seconds. Returns early when the run completes or requires user, permission, or plan input.
Wait up to 30 seconds. Returns early on completion or user/permission/plan attention. timeout means research continues; only cancel_run cancels it.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| timeout_ms | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds real behavioral context beyond the annotations: it can return early on completion or user/permission/plan attention, and a timeout does not mean cancellation. This is valuable and consistent with the read-only, idempotent annotation given. It earns high marks, though it leaves vague what exactly the caller should do when 'attention' causes the early return.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three crisp sentences, each carrying essential information: the wait duration, the early-return conditions, and the cancellation distinction. There is no filler or repetition, and the most important facts are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives enough to invoke the tool correctly in most cases, but there is no output schema and the description does not explain what the tool returns or how an agent distinguishes a timeout from a completed run or an attention state. For a tool whose only observable result is the return value, this is a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It adds useful semantics for timeout via 'timeout means research continues,' but it does not mention run_id at all and does not explain how timeout_ms maps to the 30-second maximum, which is already in the schema. Because only one parameter is partially addressed, the description does not carry the parameter-documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a blocking wait operation on a run ('Wait up to 30 seconds') and contrasts it with cancellation in a way that distinguishes it from siblings like get_run and cancel_run. The behavior of returning early on completion or attention is stated explicitly, so an agent does not have to infer the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance about timeout behavior and explicitly names cancel_run as the only way to actually cancel the run. It does not explicitly tell the agent when to use wait_run versus get_status or get_run for non-blocking checks, so it misses full alternative routing, but enough context is present to avoid misusing the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.