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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered structurally and 'Creates nothing' is largely redundant. The description does add genuine non-obvious behavior: the connectionId fallback for older connection-scoped creations, that creationReference works directly, and the no-match/do-not-recreate rule.

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?

Four short sentences, front-loaded with the lookup key and scenario before the caveats. 'Creates nothing' repeats the annotation and could be dropped, but the remaining content is dense and earns its place.

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?

With an output schema present and 100% parameter coverage, the description only needs to carry purpose, trigger and safety caveats, and it does. The one gap is sibling disambiguation against get_task/list_tasks, which an agent would need to resolve elsewhere.

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 100%, so each parameter is already documented, which sets the baseline at 3. The description adds only marginal relational context ('also give that connectionId', 'a creationReference works directly') beyond what the per-parameter descriptions already say.

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 (find a task you created) and the lookup key (original operationId), plus the recency scenario (after a lost reply or reconnect). It is clear on its own, but never names the near-identical sibling get_task or list_tasks, so an agent must infer why this differs from simply fetching a task.

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 a concrete trigger ('after a lost reply or reconnect') and a follow-up rule ('No match is not permission to create a replacement without asking the owner'), which heads off the obvious wrong next action. It stops short of routing the agent among siblings (get_task, list_tasks, wait_for_task), so it is clear context without explicit alternatives.

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