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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the safety profile is covered; the description adds real value beyond that by stating the code-uniqueness failure mode, that nothing existing is changed, and that a new CustomerID is returned. It omits auth/rate-limit or partial-failure behavior, so it stops short of a 5.

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?

Three compact sentences, front-loaded with the operation type and mutation nature, with the critical uniqueness constraint early. The trailing 'SOAP InsertCustomer.' is marginal for an agent but cheap enough not to hurt much.

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?

It helpfully discloses the return value (new CustomerID), which matters because no output schema exists, and it covers the destructive/uniqueness behavior. But for an 18-parameter creation tool with sparse schema coverage, it leaves too many optional fields unexplained for full completeness.

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 18 parameters and only 39% schema description coverage, the description must compensate for undocumented fields, but it only elaborates on `code` (uniqueness) and says nothing about `name` being required or how `tax_region`/`payment_terms_days` should be set. Fields like email, notes, addresses, vat_number and telephone get no meaning from either source.

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 ('create a new customer') and leads with 'WRITE:', so the agent immediately knows this is a mutation rather than a lookup like kashflow_get_customer or kashflow_find_customer_by_email. It does not explicitly name a sibling, but 'customer' inherently separates it from kashflow_create_supplier.

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 uniqueness rule ('KashFlow refuses a code that exists') implies the agent should look the customer up first rather than blindly retrying, which is useful implied routing. However, no explicit 'use X instead when...' guidance or preconditions (e.g., required permissions) are stated.

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