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

With no annotations, the description carries full behavioral burden. It usefully discloses that drafts and cancelled invoices are excluded by default and that it aggregates per month, and it points to get_invoice for rate detail. However it does not describe the return shape, date-range defaults, currency behavior, or whether figures are reversible/recomputable – gaps that matter for a report with no output schema.

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 tight sentences with zero waste: purpose first, then default exclusion behavior, then the alternative pointer. Front-loaded and every sentence earns its place.

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?

No annotations and no output schema, so the description must define the return and safety profile. It covers scope, exclusions, and an alternative, but omits the return structure (taxable base vs. collected columns, units) and date-range defaults. Adequate but with clear gaps given the absence of an output schema.

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 all four parameters (state, date_from, date_to, currency) are already fully documented in the schema. The description reinforces the state default ('Drafts and cancelled invoices are excluded by default'), aligning with the 'issued' default, but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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 opens with a specific verb+resource: 'Monthly output VAT summary for the VAT return (decont TVA): taxable base and VAT collected per month from issued invoices.' An agent can immediately distinguish this reporting tool from the write/create siblings and from report_vat_deductible, which handles the deductible side.

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 states usage context ('for the VAT return') and routes the agent to an alternative for per-rate detail: 'use get_invoice on individual invoices.' It also notes the default exclusion of drafts/cancelled. It stops short of contrasting with report_vat_deductible or report_invoiced_by_period, so there is a minor gap for full when/when-not disambiguation.

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