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

Annotations already declare write, non-idempotent, non-destructive, open-world. The description adds meaningful context beyond that: the id is server-assigned, no side effects like sending documents occur, and the server may demand fields beyond those supplied and will reply with a validation message. Only the shape/format of that error response is left implicit.

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?

Four short clauses, front-loaded with the 'WRITE:' marker for quick risk triage, then behavior, then precondition, then failure mode. No redundant restatement of the title or schema.

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 an 11-param write tool with no output schema, the description covers the critical unknowns: server-assigned id, no sending side effects, possible extra required fields, and error behavior. Field-level detail is left to the schema, which is a fair split, though more guidance on which fields Laudus typically demands would help.

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 coverage is only 55% across 11 params, so the description should compensate more. It does highlight RUT (vat_id) as the dedup key, which is the most important semantic, but it does not explain that name is the only required field or clarify the remaining undocumented fields.

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 specific verb and resource (creates a customer in Laudus) and immediately scopes it against confusable siblings by clarifying that the record is not an invoice and sends nothing. Also clarifies id assignment, so an agent knows not to supply 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?

Gives an explicit prerequisite workflow: check laudus_list_customers for the RUT first to avoid duplicates. It doesn't name an alternative creation path or say when not to create, but the dedup guidance is concrete and actionable.

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