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 meaningful consequence: the deposit is held until Doing Work decides. It does not say whether the statement can be amended or resubmitted, whether submission is one-shot, or what happens after a decision — gaps that matter for an irreversible mutation.

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 short sentences with the action and the stake front-loaded; nothing is wasted. The parenthetical eligibility note is compact but slightly interrupts the flow.

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?

The output schema means return values need not be explained, and the business stake (held deposit) is covered. Still, for a three-required-parameter mutation with zero annotation and zero schema documentation, an agent lacks guidance on preconditions, statement content, and post-submission behavior.

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, and it does not. It never explains shop_id, job_id, or what the statement should contain (only the 1-2000 char bound lives in the schema), and 'customer booking' vs. a parameter named job_id leaves the identifier's meaning ambiguous.

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 concrete verb and resource: submitting your side of a disputed no-show on a customer booking, with the recipient ('Doing Work') named. It is distinguishable from nearby siblings like network_decline and homeowner_reportNoShow, though the relationship between 'customer booking' and the job_id parameter is not spelled out.

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 parenthetical '(owner or office)' gives a caller-eligibility hint, and 'disputed no-show' implies the triggering situation. However, it never says when to use this versus network_reply or network_decline, nor whether a dispute must already be open before calling.

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