get_task_result

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety and repeatability are covered by structured data. The description usefully adds the status vocabulary (running | done | error) and the fact that output/traceback are captured, but says nothing about polling intervals, output truncation, or whether the task record expires once read.

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 purpose sentence is front-loaded in one line, and the Args/Returns block is compact and scannable. The Returns line partially duplicates the existing output schema, a small redundancy, but nothing bloats the definition.

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 single-parameter polling tool it covers the essentials: what is fetched, the required argument's origin, and the status states. Since an output schema exists, the return explanation is a bonus rather than a requirement, and only the polling mechanics remain unspecified.

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% and the schema only supplies a title and minLength, so the description carries the burden. It does so by defining task_id as the ID returned by execute_code_async, which tells the agent where the value must come from — meaningful added semantics beyond the schema.

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 (Poll) plus the resource (status and captured output of one execute_code_async task), and explicitly ties itself to the sibling that produces the input. An agent can distinguish it from execute_code_async and execute_code without opening the schema.

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?

"Poll" plus "Task ID returned by execute_code_async" makes the trigger condition clear: call this after starting an async execution, repeatedly until completion. There are no explicit exclusions or guidance on polling cadence versus other result-retrieval paths, so it stops short of a 5.

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