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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. Beyond that, the description discloses the one behavior annotations cannot: the call blocks and typically returns data on the first attempt, plus the pending/terminal status lifecycle. That is high-value behavioral context.

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?

Purpose is front-loaded in the first sentence, followed by execution guidance and then an output caveat — a sensible ordering with no filler. The adjacent "Call immediately ... call again immediately" phrasing is slightly repetitive and 'failed' is left unquoted among status values, but the text remains dense and useful.

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?

For a two-parameter polling tool with full schema coverage, annotations covering safety, and an output schema handling return values, the description covers everything an agent must know: where the ID comes from, that the call blocks, how to loop, when to stop, and how to interpret columns. Nothing material is missing.

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?

With 100% schema coverage the baseline is 3, but the description adds provenance the schema lacks — that `schedule_id` comes from a data_query response — and explains that columns should be mapped via requested_field_ids/canonical_field_ids rather than row-0 display names. It says nothing about `compress` beyond what the schema already documents, which is the only real 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?

States a specific verb+resource ("Retrieve results from a data_query") and binds it to the `schedule_id` produced by that query, which distinguishes it from querying siblings like data_query itself. It stops short of naming other retrieval alternatives, but the resource and scope are unambiguous.

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?

Gives explicit invocation timing ("Call immediately; the call waits, so it usually returns data first time"), an explicit retry rule while pending, and an explicit stop condition on status 'completed' or failed. This is exactly the when-to-call / when-to-stop guidance an agent needs for a polling tool.

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