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

Annotations already mark it as read-only, idempotent, and non-destructive. The description adds behavioral context by explaining the SLA countdowns are for 'timezone-safe polling' and that includeEvents inlines event history to save a round-trip. It also discloses the API key requirement. No contradictions with annotations.

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 compact yet information-dense, covering purpose, response contents, optional flags, prerequisites, and next steps in five sentences. Each sentence adds unique value with no redundant phrasing or filler.

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?

Even without an output schema, the description enumerates the main response components (operator status, proof, timestamps, decision requests, SLA countdowns) and explains optional behaviors. It also provides the follow-up workflow, making it fully self-contained for an agent to decide when and how to invoke the tool.

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?

The input schema already describes all four parameters, so the baseline is solid. The description enhances includeEvents and includePolicyText by explaining their purpose and trade-off (avoiding extra calls), and clarifies the apiKey source. This goes beyond mere schema descriptions.

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 states it retrieves full details of a physical-world task and enumerates specific content areas (operator status, proof, timestamps, pending decision requests). This distinguishes it from sibling getters like get_task_events and get_task_proofs by the comprehensive detail set.

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?

Provides explicit guidance: includeEvents=true saves a round-trip to get_task_events, and includePolicyText embeds policy text instead of fetching it from other sources. It also notes the prerequisite of an API key and suggests next actions (approve_physical_task_completion or cancel_physical_task) based on task status. While it doesn't enumerate all cases for not using this tool, the alternatives and follow-ups are clear.

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