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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description goes well beyond this by disclosing: extraction is deterministic ('NON sono inferiti da un LLM'), external VIES call behavior with shared budget ('una sola interrogazione VIES per chiamata'), honest degradation to 'attenzione' when VIES is down or budget exhausted, and no login/free. It also explains the checks performed (IBAN MOD-97, P.IVA/CF checksum, VIES comparison). No contradictions with annotations.

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 long but front-loaded with the primary purpose and then systematically covers extraction, checks, return format, external I/O, cost, and a caveat. Every sentence contributes operational information (red flags, verdict values, budget constraints, out-of-band warning). It is appropriately structured for a complex tool, though slightly verbose.

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?

Given no output schema, the description sufficiently covers return values ('Restituisce il parse completo più supplier_verification con verdetto (ok / attenzione / alto_rischio) e red flag puntuali'), input preprocessing (.p7m), failure modes, shared external I/O budget, and free/no-login access. This is complete for a tool with parsing and verification complexity.

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 the baseline is 3. The description adds meaningful context beyond the schema: it explains expected_country's fraud-flag role ('Un IBAN estero su un fornitore atteso italiano è il campanello #1 della frode'), clarifies that the default party 'cedente' is the supplier who receives payment, and notes that .p7m must be unpacked before passing xml_content. This elevates the value above the schema alone.

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: 'Estrae i dati strutturati da un XML FatturaPA/SDI E, nella stessa chiamata, verifica anti-frode la parte indicata' — clearly defining a combined parse-and-verify action. It distinguishes itself from siblings like parse_fatturapa (parse-only) and verify_payee by framing itself as 'la difesa contro la truffa del cambio-IBAN sulle fatture passive'.

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 description provides clear context for when to use the tool ('È la difesa contro la truffa del cambio-IBAN sulle fatture passive') and when not to rely on it exclusively ('NON sostituisce la verifica out-of-band (telefonata al fornitore su un numero già noto)'). It references verify_payee for comparison on external I/O but does not explicitly define alternatives like parse_fatturapa for parse-only needs, so it's clear but not fully exhaustive.

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