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

Annotations already declare readOnlyHint=false and destructiveHint=false, establishing this as a non-destructive write. The description adds real behavioral context by framing this as a generic insert with no numbering, VAT, QR or ledger side effects, but says nothing about duplicate handling, idempotency, validation failure modes, or per-resource required fields.

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 purpose and the sibling exclusion are front-loaded in two tight sentences with no filler. The trailing 'Creatable resources' line duplicates the enum already in the schema and, because it disagrees with that enum, adds noise rather than clarity.

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 payload is a nested free-form object with additionalProperties=true and no field documentation anywhere, so an agent has no way to know which fields each resource requires — the single most important thing for a creation tool. The description covers routing well but leaves the data contract entirely opaque, and the enum/prose mismatch further weakens confidence in scope.

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 100%, so both parameters (resource enum, free-form data object) are already documented, making 3 the baseline. The description's resource list adds marginal value but partially contradicts the enum by naming resources that cannot be created and omitting 'orders' from the opening sentence.

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 gives a specific verb (create) plus the resource families and an explicit enum of creatable resources, so the tool is clearly distinguished from read-only siblings. It loses a point because the first sentence advertises 'employee' and 'asset' as creatable while the enum and the follow-up list contain neither, so an agent gets conflicting scope signals.

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?

It names the alternative explicitly ('Use fawtar_create_invoice for invoices') and gives the reason that selects it — sequential numbering, VAT computation, QR writing and ledger posting. That is a when-to-use/when-not-to-use rule with a rationale, not just a pointer.

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