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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds no behavioral detail beyond that. 'Operate on' is ambiguous about whether the tool reads or modifies, though it does not explicitly contradict the read-only annotation. No auth, rate-limit, or side-effect context is disclosed.

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?

The description is short and free of filler, but it is under-specified rather than deliberately concise. 'Operate on' plus a list of resource categories conveys almost no actionable information. The sentence does not earn its place as a useful tool definition.

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?

For a tool with 13 parameters, nested objects, and no required fields, this description is far too thin. Although output schema and annotations exist, the agent still lacks a statement of the tool's core behavior, when to use it, and how parameters map to the operation. The definition is not sufficient for correct selection or invocation.

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?

With only 15% schema description coverage, the description needed to explain key parameters like line, lines, query, format, document_id, estimate_id, progress_pct, and idempotency_key, but it mentions none of them. The phrase 'tenant-scoped' only weakly echoes the tenant_id schema description. An agent cannot infer how to construct a valid call from this text.

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 uses the vague verb 'Operate on' and never states the primary action of creating a draft. It lists many resources (drafts, lines, versions, documents, exports, policy receipts) without identifying which one this tool actually acts on, so it cannot be distinguished from sibling tools like estimator_estimate_add_line or estimator_estimate_export. This reads as a namespace description rather than a specific tool purpose.

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?

No guidance is given on when to use this tool versus its many estimator siblings. The only contextual clue is 'tenant-scoped', which is a scope constraint, not a usage condition. There are no exclusions, preconditions, or alternative tool routing.

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