Get consultation status or result

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the polling semantics itself: default 45s cap, progress every 15s, group waits returning on any member completion, and what completed vs failed payloads contain. This is substantial beyond-annotation context, though terms like 'network is this round's web policy' are terse enough to be ambiguous.

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?

Every clause carries information, but they are crammed into a run-on block that mixes polling rules, return-shape documentation, and downstream workflow without any separation or front-loading beyond the first sentence. An agent must parse it linearly to extract the parts relevant to its current call.

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?

With no output schema, the description takes on the return-value burden and does so: completed carries advice, failed carries failure.kind, groups carry statuses plus comparison.by_target fields, and truncation/null-observation caveats are flagged. What is missing is a clear statement of the top-level response shape and how to distinguish a still-running from a finished wait.

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 coverage is only 20%, so the description has to compensate and largely does: wait_ms semantics (0 = poll, default 45000), ids combined with job_id returning only those points each whole with grounds and recorded verdict, job_id alone returning one whole answer, and detail: full adding brief/question. group_id's behavior is described functionally rather than by its field definition, leaving a small gap.

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 opening clause states a specific operation on a specific resource: wait on a job_id or group_id for consultation status/result, with wait_ms: 0 turning it into a poll. It is clearly distinguishable from consult_start/consult_list/consult_cancel by virtue of being the wait/retrieve step, though it never names those siblings to draw the contrast explicitly.

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?

It gives real workflow guidance: repeat while running, in a group wait until another member finishes, check available advice while others run, then wait again for new completions. It also routes to the sibling consult_record ('batch checked entries in consult_record, then report') and explains when to use job_id + ids versus job_id alone. It stops short of stating when not to use this instead of consult_list or consult_export.

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