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

No annotations are present, so the description must carry the full burden for behavioral disclosure. It tells the agent what data is returned but does not state that this is a safe read, how missing or invalid task IDs are handled, or whether any authentication or boundary constraints apply.

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 a single concise sentence that front-loads the core idea ('One task in full') and then itemizes the meaningful contents without redundancy. Every word earns its place and there is no restatement of the schema.

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 simple one-parameter fetch with an output schema available, the description plus the schema is largely sufficient: the agent knows it gets a full task and what the task consists of. It still lacks usage/alternative guidance and behavioral safety notes, so it is not fully complete, but the missing return-format detail is already covered by the output schema.

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 description never mentions task_id or explains how it selects the task. The parameter name is self-explanatory and the 'one task' wording implies ID-based lookup, but this is minimal compensation for a schema with no property 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 phrase 'One task in full' clearly identifies the operation as returning a single complete task and lists the fields that full task contains (question, materials, required output schema, budget, boundary). This distinguishes it from list_tasks, which would return multiple tasks, and from resource-specific tools like get_verse or get_connection, even though no sibling is explicitly named.

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 no explicit guidance about when to use get_task versus alternatives such as list_tasks or get_context, and it names no sibling tools. The 'full' wording implies the agent should use it when complete task details are needed, but this is implicit rather than stated.

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