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

With no annotations, the description carries the full burden, and it does disclose one real behavioral trait: the escrow state is 'read live from chain', which tells the agent the data is fresh but likely slower/more expensive than a cached read. It also reveals the tool is a broad aggregator across several data sources. It says nothing about permissions, latency, rate limits, or whether the 'similar settled trades' section is bounded.

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?

One front-loaded sentence, effectively a colon-prefixed fragment that puts the resource first and the payload second. No filler sentences. It is dense to the point of being slightly clipped, but nothing is wasted.

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?

There is no output schema and no annotations, so the description has to carry both semantics and behavior; it does enumerate the returned sections, which partially compensates. However it leaves one parameter completely undefined and never resolves its overlap with get_task, so an agent cannot confidently pick it over that sibling or use the 'agent' argument at all.

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 neither parameter carries any description, so the description is the only possible source of meaning — and it supplies none. 'taskId' is at least implied by 'One task in full', but the 'agent' parameter (maxLength 200) is never mentioned, leaving its role (viewer identity? filter? perspective?) completely unexplained for a required-adjacent input.

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?

Names the resource ('One task in full') and enumerates the specific payload it assembles: live escrow state from chain, attempts, parent and subcontracts, similar settled trades. That is far more specific than a tautology. It stops short of differentiating itself from the sibling get_task (and explore_tasks/list_tasks), which reads like the same 'fetch one task' intent.

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?

There is no when-to-use, no when-not-to-use, and no reference to any alternative, even though get_task and explore_tasks sit in the same sibling list and look heavily overlapping. The agent must guess which of these single-task readers to call, and the description offers no routing signal.

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