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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description adds genuine value by disclosing the shape of the answer (part ids, grain, cut order, offcuts, edge banding) and by scoping it with 'Geometry only', which tells the agent this does not price or quote. It stops short of disclosing defaults, unit behavior, or what the nesting step does when parts do not fit.

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?

It is compact and front-loads the core purpose, but it is one long run-on sentence built from colon chains, and 'the blank' is repeated in both halves ('the blank with scribe and bow, then the blank and any other parts nested'). A tighter two-sentence split between measurement and nesting would read better.

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?

This is a 27-parameter tool with nested objects, eight enums and defaults layered on defaults. An output schema exists so return values need no explanation, but the description never explains the measurement model (span, measuredAt, leftAngle/rightAngle) or when to reach for this versus fit_worktop_run, leaving an agent to reconstruct the whole workflow from the schema alone.

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 81%, so the schema already carries most parameter meaning and the baseline would be 3. The description still adds semantics the schema does not: it frames scribe and bow as inputs that shape the blank, and ties grain, offcuts and edge banding to the nesting output, which helps the agent understand which parameters feed which part of the answer.

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 names the resource (worktop, shelf or panel between walls that are not square) and enumerates the outputs, which makes the purpose inferable, but it is a noun-phrase fragment with no verb and it never distinguishes itself from near-identical siblings like fit_worktop_run or scribe_template. An agent can guess what it produces but not why it should pick this one.

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, when-not-to-use, or alternatives guidance anywhere. With fit_worktop_run, scribe_template and optimise_cuts in the sibling list, the absence of any routing sentence is a real gap.

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