Get Agent Task

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety profile is covered. The description adds value by stating the data is immutable and audited, and mentions the timeout_fallthrough return field, which is non-annotated behavioral context. A small deduction because it doesn't elaborate on what timeout_fallthrough means or other edge cases.

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, front-loaded with purpose, and uses clear labeled sections (USE WHEN / NOT FOR / ARGS / RETURNS). Every sentence provides actionable information with no repetition or fluff.

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 read-based tool with rich annotations and 100% schema coverage, the description covers the purpose, usage, and return fields. The only gap is not explaining the 'timeout_fallthrough' field, but that's an output detail rather than a functional requirment. It doesn't need an output schema since it lists return keys.

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 covers task_id fully with format and description, so baseline is 3. The description just says 'ARGS: task_id' which adds no new semantics. That's acceptable given the schema's completeness.

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 the tool fetches an Agent-stage task's immutable input snapshot, instructions, and output contract. It names the specific resource ('Agent-stage task') and distinguishes it from siblings like claim/submit by explicitly naming those alternatives. The verb 'Fetch' is concrete and 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?

The description provides explicit USE WHEN and NOT FOR guidance, naming tailonic_claim_agent_task and tailonic_submit_agent_task as alternatives. This fully clarifies the tool's position in the workflow and prevents misuse.

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