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

No annotations are provided, so the description carries the full behavioral burden. It discloses the escrow/refund side effect usefully: 'Refund only unearned slots; inconclusive submissions retain their escrow' — this tells the agent that closing triggers financial settlement with partial refund semantics. However, it does not state what happens to an already-closed task, whether the operation is idempotent beyond the idempotencyKey, or whether the task enters a terminal closed state vs. stays modifiable.

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?

Two sentences, no fluff, and the core action plus condition is front-loaded in the first sentence. The second sentence adds meaningful escrow semantics that an agent needs. Slightly more could be done without bloat, but the current form is tight and each clause 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?

Given a 3-param tool with no annotations and no output schema, the description is thin. It omits the meaning of expectedVersion and idempotencyKey (infrastructure-level params that agents typically get wrong), the return behavior (what the closed task object or confirmation looks like), and failure conditions (e.g., version mismatch or invalid idempotencyKey). For a state-changing operation with escrow implications, this is not enough to call it successfully.

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%, so the description must compensate for all three parameters: id, expectedVersion, and idempotencyKey. It mentions none of them. The purpose of expectedVersion (an optimistic-concurrency guard, likely checked against the task's current version) and idempotencyKey (a client-supplied dedup key) would be non-obvious to an agent and should be clarified since the schema names alone don't reveal their roles.

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 states a specific verb-action ('Close a task') and a resource, plus the condition ('after its submission deadline'). It is distinguishable from siblings like create_task and submit_task by the lifecycle stage it acts on. It doesn't explicitly name the near-sibling close_case, but the resource (task vs case) carries the differentiation, so it's clear if not exhaustive.

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 timing condition 'after its submission deadline' gives clear when-to-use context, implying the tool is only valid once that deadline has passed. However, there is no explicit when-not-to-use guidance, no mention of preconditions (e.g., task must exist, must not already be closed), and no named alternatives. With siblings like set_outcome, close_case, and reopen_case present, some routing guidance would help an agent avoid misuse.

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