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

With no annotations at all, the description carries the full burden. It does well on the output side by disclosing exactly what is written into the archive, which communicates the side effect. It says nothing about cost/volume (it pulls every invoice and credit note for a year), whether an existing file at output_dir is overwritten, or required permissions.

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?

A single front-loaded sentence that leads with the action and then lists deliverables; every item listed is substantive content the agent would otherwise have to guess. It is dense but not padded, though the long enumeration makes it less scannable than a short lead plus bullet list.

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 a 5-parameter tool with no output schema and no annotations, the description effectively serves as the return-value specification by naming every file produced, including the summary report contents. Remaining gaps are operational (runtime, overwrite behavior, huge datasets) rather than about what the tool produces.

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 60%, so the schema already documents year, company_id, and output_dir defaults. The description reflects the content toggles implicitly (PDF and XML are listed as included) but adds no meaning about year scoping, company selection, or what happens when include_pdf/include_xml are false. Baseline-to-slightly-below is warranted.

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 states a concrete verb and resource — creating the annual zip for the accountant — and then enumerates the exact artifacts inside it (four CSVs, PDFs, FatturaPA XML, riepilogo.md). An agent can tell this is a bulk export/report bundle, distinct from single-purpose siblings like revenue_summary or tax_estimate.

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?

Usage is implied by 'annuale per il commercialista' — the agent can infer this is a year-end delivery package rather than an ad-hoc query. However, it never states when NOT to use it or points to lighter alternatives (revenue_summary, tax_estimate, tax_deadlines_export) that cover part of the same ground.

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

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

readOnlyHint=true already establishes this as a safe read, so the description's margin is smaller. It does add real context beyond the annotations: the quota is consumed by all private apps, and it is tracked over both an hourly and a monthly window. It stays silent on what happens when the quota is exhausted (error vs. indication), which is the behavior that would actually change an agent's next step.

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?

Two sentences with no filler: the measurement is front-loaded, the parenthetical adds only essential context about shared limits, and the imperative usage sentence follows. Nothing could be removed without losing information.

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 a zero-parameter, read-only quota check with no output schema, the description covers what is measured and when to call it. The remaining gap is the return shape (e.g., whether it yields two numbers plus reset timing), which it hints at but does not spell out.

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?

The tool takes zero parameters, which sets the baseline at 4, but the schema has no properties for the description to enrich and the description adds nothing about argument handling. There is simply nothing to disambiguate, so it lands at the neutral middle rather than being actively helpful.

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 states a specific resource and metric: remaining API requests in the current hour and month, qualified as the Fatture in Cloud quota shared across private apps. That is precise enough to distinguish it from ordinary data tools, though it never contrasts itself with the generic 'api_request' sibling, which an agent might otherwise reach for.

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?

"Usalo prima di operazioni in blocco" gives a concrete trigger condition (before bulk operations such as bulk_duplicate, bulk_email, bulk_send_einvoice). It gives no explicit when-not or alternative tool, so it falls short of a 5, but the usage context is clear rather than implied.

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

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

Annotations already declare openWorldHint=true and destructiveHint=true, so the safety profile is known. The description adds genuinely useful routing behavior: path is resolved relative to the company unless it begins with /user, /info or /c/, which is non-obvious and would otherwise cause silent misrouting. It does not mention auth/scope requirements, pagination, or response/error handling for raw calls, so with annotations already covering the danger profile this lands at a solid 3.

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?

Two sentences, front-loaded with the scope definition before the path rules, with zero filler. The API reference URL earns its place as the escape hatch for everything the description cannot enumerate, though it slightly lengthens an otherwise tight definition.

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 a raw passthrough with destructive and open-world annotations and no output schema, an agent needs to know path resolution, payload shape, and that responses are raw API JSON. Path resolution and a doc link are covered and the schema hints at the { data: {...} } envelope, but the raw response format and the undefined 'query' parameter are not addressed.

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 40%, so the description needs to compensate and it partly does: the path scoping rule (relative vs absolute prefixes) is the single most important semantic and is only in the description. However 'query' is undocumented in both description and schema, and 'method' semantics (which verbs mutate, which need bodies) are left entirely to inference, so compensation is incomplete.

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 (direct call to API v2) and defines its scope precisely as the fallback for anything without a dedicated tool, listing concrete example domains (settings, price lists, webhooks, pending documents). This makes it unambiguously distinguishable from every sibling, which are all named-resource CRUD tools.

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 phrase 'per tutto ciò che non ha un tool dedicato' gives a clear selection rule: use this only when no dedicated sibling exists. That implicitly excludes the ~80 named-resource tools. It stops short of explicitly telling the agent to prefer dedicated tools first, but the condition is stated plainly enough to act on.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add scope and content — which it does by listing the four audit categories checked, giving real insight into what the call will surface. It stops short of saying whether results come back as a flat findings list, per-document flags, or counts, and says nothing about volume or pagination for large years.

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?

A single sentence that front-loads the core purpose and then uses semicolons to enumerate checks economically — no filler. It is slightly run-on and mixes four distinct audit families into one breath, but every clause carries information.

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?

With no output schema, the description carries the burden of conveying what comes back; the enumerated checks imply findings but the response shape (list of issues vs. counts vs. per-document objects) is unstated. For a two-optional-parameter read-only tool this is adequate but leaves a real gap around return values and result volume.

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 description coverage is 100%: both parameters (year, company_id) already document their defaults (current year, FIC_COMPANY_ID or the token's sole company). The description adds no meaning beyond that — it never explains that the year parameter drives the numbering/date checks or how company scoping affects results. 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 states a specific operation on a specific resource ('Controlli sui documenti dell'anno') and then enumerates exactly which anomalies are detected: unsent/rejected e-invoices, missing stamp duty above 77,47 €, overdue payments, and numbering gaps/duplicates. An agent can tell this is an audit/report tool rather than a CRUD tool. It does not, however, name or contrast itself with near-neighbours like verify_einvoice, stamp_duty_report, or receivables_report.

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 scope is implied by 'dell'anno' plus the year parameter, so an agent knows this is a yearly audit sweep. There is no explicit when-to-use / when-not-to-use guidance and no pointer to the overlapping sibling reports that cover a subset of these checks (stamp_duty_report, receivables_report, verify_einvoice).

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description's main added value is disclosing that results include consent expiry dates — useful domain context for deciding whether a re-link is needed. It does not say what happens when consent has expired, whether expired links are still returned, or whether the call requires a live Enable Banking session.

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?

A single short sentence with no filler, and the resource plus the consent-expiry detail are front-loaded. It is efficient, though the elliptical phrasing costs a little clarity about the actual operation.

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 a zero-parameter read tool with no output schema, the description should convey what comes back (list of accounts, institution names, consent expiry/status) and any authorization dependency on Enable Banking. It hints at the two key data points but leaves the return shape and the link prerequisite unstated, and the Italian text sits oddly against English sibling names.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the empty schema already shows. Baseline 4 applies; the description does not need to compensate for any undocumented parameters.

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 names the resource (bank accounts linked via Enable Banking) and adds that consent expiry is included, but it never states an explicit verb and reads as a noun phrase rather than an action. It also fails to distinguish itself from the nearby sibling bank_list_banks, so an agent cannot tell from the description alone which one returns linked accounts versus available banks.

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?

There is no when-to-use guidance, no mention of prerequisites (an existing Enable Banking link), and no reference to alternatives such as bank_link_start or bank_list_banks. The agent must infer the usage context entirely from the name.

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

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

readOnlyHint=true already declares the safety profile, and the description adds almost nothing beyond it. It omits whether the returned set is static/global or scoped to the company, whether it reflects previously uploaded statements, and what the entries look like.

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?

One short sentence with no filler and the subject front-loaded. It loses a point only because the compactness comes at the cost of omitting the action verb rather than because of wordiness.

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 a zero-parameter, read-only lookup with no output schema, the description should convey the shape of the result (a list of banks paired with supported format identifiers). It states the domain but leaves the return structure entirely to inference.

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?

The tool takes zero parameters, so there is no parameter semantics for the description to carry; the baseline of 4 applies. Nothing in the description misrepresents the empty input schema.

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 names the resource (banks and bank statement formats recognized during import) but is a bare noun phrase with no verb, so it never states that the tool retrieves/lists them. It also does not distinguish this reference list from bank_list_banks, which sits right next to it among the siblings.

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?

There is no when-to-use guidance at all: nothing says to call this before bank_parse_statement to check whether a format is supported, nor how it differs from bank_list_banks. The mention of 'import' only loosely implies a pre-import discovery use case.

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

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

No annotations are supplied, so the description carries the full burden. It does not disclose that this call creates a persistent bank connection, what state validation does or whether a mismatched state is rejected, whether the call is idempotent, or what errors surface on an expired/invalid code — all the behavior an agent needs for an OAuth-callback step.

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?

A single front-loaded sentence with an action verb and no filler; the parameter explanation is attached directly to the imperative. It is efficient but leans toward under-specification rather than tightness, leaving no room for the flow context the agent actually needs.

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 OAuth-callback tool with no annotations and no output schema, the description omits the flow context (that it finalizes a bank_link_start session), which parameter form is preferred, what a successful result yields, and how to recover from an invalid code or state. Given the complete absence of structured behavioral data, this is a significant gap.

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 description coverage is 0%, so the schema alone leaves both parameters opaque strings. The description compensates by explaining that redirect_url is the full return URL containing ?code=...&state=... and that alternatively the bare code may be passed — real semantic value the schema does not provide, though it stops short of naming the state field's role or marking either parameter required.

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?

"Completa il collegamento" states a completion action on a linking flow, and the parameter hints (?code / state) identify it as an OAuth-style callback. However, the object of "collegamento" is never named as a bank account link, so the purpose is only inferable by combining the name with the sibling bank_link_start rather than from the text itself.

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?

There is no statement of when to call this versus alternatives, no mention that it must follow bank_link_start, and no note on prerequisite authorization. The only guidance is a weak either/or between the two parameters ("oppure"), with no rule for choosing between them and no indication of what to do on failure.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the tool returns a link rather than linking immediately, that consent persists up to 180 days, and the critical quirk that the final page may display an error yet its URL must still be captured. It stops short of describing failure modes, expiry/retry behavior, or any auth/quota constraints on the PSD2 flow.

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 short sentences, front-loaded with the identity of the tool, then the actionable procedure, then the consent lifetime. Every clause carries operational weight, including the parenthetical that prevents a common failure.

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 output schema exists, and the description fills that gap by stating the return value is a link and describing exactly what to do with it. For a four-optional-parameter initiation tool this is nearly complete; only error/expiry handling and the precondition that the account must not already be linked are absent.

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 description coverage is only 50%: 'bank' and 'psu_type' are documented in the schema, while 'days' and 'country' are not. The description partially compensates by tying consent duration to up to 180 days (the schema's maximum for 'days'), but 'country' is never explained and the exact-bank-name hint lives only in the schema, so much of the meaning still rests on structured 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 ('Collega un conto corrente via Enable Banking (PSD2)') and explicitly names the sibling it hands off to ('passalo a bank_link_finish'), so an agent can separate it from bank_link_finish and bank_accounts without opening any schema.

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 a clear step-by-step usage path: open the returned link, authorize at the bank, copy the final page URL and pass it to bank_link_finish, including the counterintuitive case where the page shows an error. Lacks explicit when-not-to-use guidance (e.g. use bank_accounts for accounts already linked), but the forward workflow is unambiguous.

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

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

Annotations only declare readOnlyHint=true, so the description carries the rest of the burden. It usefully discloses that the data comes from the Enable Banking provider and that returned names are exact-match identifiers for downstream linking, but it says nothing about country scoping, empty results, or freshness of the list.

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?

A single short sentence with the key fact (exact name for bank_link_start) front-loaded and no filler. Its brevity, however, is partly achieved by omitting important parameter information.

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?

Low complexity and no output schema lower the bar, but with two undocumented parameters the definition is not sufficient on its own; an agent must open the schema to learn that filtering by search text or country is possible.

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 description coverage is 0%, so the description must compensate and it does not: neither the 'search' string nor the 'country' code (which defaults to IT and must be 2 characters) is mentioned. An agent reading only the description would not know it can filter at all.

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 names the resource (banks linkable via Enable Banking) and implicitly the verb via the tool name, and it distinguishes itself from bank_link_start by casting itself as the source of the exact name that tool needs. It does not explicitly say 'list/returns' but the intent is unambiguous for an agent.

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 implies usage ('exact name to use in bank_link_start'), which tells the agent this is a prerequisite lookup for the linking flow, but it never states when not to call it or how to narrow the results with the available filters.

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

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

readOnlyHint=true is consistent with 'Legge', so no contradiction. The description adds useful behavior beyond the annotations by naming accepted input formats and summarizing the returned figures, but it does not explain what happens when the bank is not recognized or that the mapping override is then required, which is the main failure mode this tool has.

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?

A single front-loaded sentence with no filler; the format list is compactly parenthesized. It is appropriately sized, though it could have used one more clause for the unrecognized-bank path instead of stopping at the output summary.

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?

With no output schema and a nested-object parameter, the description carries extra burden. It does sketch the return values (bank, period, in/out), but leaves the unknown-bank/mapping fallback and error behavior unexplained, which matters for a parser that can fail on unrecognized layouts.

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 description coverage is 67%, so the schema already documents bank ('Forza il formato... vedi bank_formats'), mapping, and its nested fields. The description adds no parameter-level detail itself; the phrase 'banca riconosciuta' only weakly implies the auto-detection that the bank parameter overrides.

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 states a specific verb and resource ('Legge un estratto conto') and adds scope details: accepted formats (XLSX, XLS, CSV) and what it reports (recognized bank, period, income/expenses). It does not explicitly distinguish itself from the closely related bank_formats, bank_reconcile, or client_statement siblings, so it falls short of a 5.

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?

There is no explicit guidance on when to use this tool versus the bank_* alternatives (bank_formats for discovering formats, bank_reconcile for matching, bank_list_banks). Usage must be inferred from the mention of home-banking export files. It also omits prerequisites such as whether file_path must point to a local file already uploaded.

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

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

With no annotations, the description carries the burden well: it discloses that the tool mutates state ('segna come pagate le rate'), that dry_run is the safe preview mode, and how confidence thresholds gate writes. It doesn't address reversibility, permissions, or idempotency, so it stops short of full disclosure.

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?

Two dense sentences with the core purpose and the dry-run workflow front-loaded; little waste. The confidence-threshold clause is slightly compressed but 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?

For a 9-parameter mutation tool with a nested mapping object and no output schema, the description covers the essential matching logic and the safe preview workflow. Gaps around account selection (payment_account_id) and output format remain, but the core calling behavior is adequately conveyed.

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 56%, so some compensation is needed. The description explains dry_run and min_confidence behavior meaningfully and hints at the file-vs-linked-account choice, but says nothing about company_id, payment_account_id, mapping, from/to, or bank, leaving several parameters to 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 and resource ('Riconciliazione bancaria: abbina gli accrediti... alle fatture aperte') and enumerates the matching criteria (importo, numero fattura in causale, P.IVA, nome cliente). An agent can clearly distinguish this from siblings like mark_paid or bank_parse_statement.

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 spells out an explicit two-step workflow: dry_run defaults to TRUE for proposals, then re-run with dry_run=false to record matches ≥ min_confidence. It lacks explicit naming of alternatives (e.g., mark_paid) or exclusions, but the operational guidance is clear.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the most dangerous default: dry_run=true, plus the preview-then-apply workflow. It says nothing about whether copies are drafts, how numeration is assigned, what happens on partial failure, or any cap on how many documents can be copied in one call — all material for a bulk mutation.

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?

Two sentences, zero padding: the action and example come first, the dry_run safety default second. Everything is front-loaded and every clause 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?

For a 7-parameter, nested-object bulk mutation with no annotations and no output schema, the description covers the essential safety loop but omits how many documents a single call can handle, what the preview actually returns, and how overrides interact with per-document differences. Adequate to start, not enough to call confidently at scale.

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 already 86%, so the schema does most of the work, but the description still adds operational meaning: the dry_run default is called out as a behavior, not just a type, and the q-filter example mirrors the realistic filter syntax. It does not explain the q vs ids vs type relationship or that overrides apply uniformly to every copy.

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 scope — 'Copia molti documenti in una volta' — with a concrete example (all September invoices dated today), which clearly marks it as the batch counterpart to the single-document tools. It never names the sibling duplicate_document, so the differentiation is implicit rather than explicit.

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 real usage guidance: the scenario (bulk copy of a filtered set) and a mandatory two-step procedure (preview with dry_run=true, then re-run with false). What is missing is the exclusion — nothing tells the agent to prefer duplicate_document for a single document, even though that sibling exists.

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

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

Annotations supply only openWorldHint=true, so the description carries the burden for a side-effecting send operation. It usefully discloses that dry_run is TRUE by default and what the preview returns (recipients and subjects), which is critical safety context. It does not say what happens on real send (irreversible, per-recipient failures, rate limits, whether sending is batched or partial) — significant gaps for an outbound-email tool.

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?

Two short sentences with zero filler; the bulk-send purpose comes first and the safety-relevant dry_run behavior is front-loaded second. Nothing is redundant.

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 a 5-parameter, side-effecting bulk send with no output schema, the definition is only adequate: it covers purpose and preview behavior but omits failure handling, send-confirmation semantics (e.g. that dry_run must be set false to actually send), and prerequisites. An agent could invoke it but would be guessing about the real-send path.

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 80%, so most parameters are already documented, including the q/ids alternative and the type enum. The description still adds real meaning by explaining what dry_run actually produces ('mostra destinatari e oggetti'), which the bare boolean default in the schema does not convey.

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 ('Invia per email molti documenti') plus the key scoping rule that each document goes to its own client with default texts. 'Molti' implicitly contrasts with the single-document sibling email_document, but the sibling is never named, so differentiation relies on inference.

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 bulk-vs-single distinction is implied by 'molti' but never made explicit against email_document or email_document's per-document variant. There is no statement of prerequisites (configured sender/SMTP, verified addresses) or of when not to use it. The dry_run default note is the one concrete piece of usage guidance.

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

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

Annotations already flag destructiveHint=true and openWorldHint=true; the description adds genuinely new behavior on top of that: dry_run is safe-by-default, and invalid-XML documents are skipped and reported instead of failing the whole run. It still doesn't say whether a real (non-dry-run) submission is irreversible or whether skipped items can be retried.

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 short sentences, front-loaded with the action and immediately followed by the safety-relevant default. No filler, though the skip/flag sentence could be tied more tightly to the send behavior it qualifies.

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 a bulk mutation that talks to an external authority, the description leaves notable gaps: no batch-size or quota expectations for openWorldHint calls, no indication of what the caller gets back per document (results vs. summary, since there is no output schema), and no note that a real send cannot be undone.

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 80%, so q, ids, type and company_id are already documented. The one real addition is explaining dry_run's effect ("solo verifica"), since the schema lists only a bare default of true; nothing is added about how q and ids interact when both are supplied.

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 pair and resource ("Verifica e invia allo SdI molte fatture"), and the plural "molte" signals batch scope, which separates it from the single-document send_einvoice sibling. It does not name that sibling explicitly, so the differentiation is implicit rather than stated.

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 that dry_run defaults to TRUE and that this means "solo verifica", which is useful operational context, but it never says when to pick this tool over send_einvoice or verify_einvoice, nor when to leave dry_run on versus turn it off (e.g. real submission to SdI).

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered elsewhere. The description does add genuine behavior: it names which data sources feed the projection (open invoices, recurring invoices, tax deadlines on 30 June / 30 November, fixed expenses) and states that the result flags months with negative balances. It stops short of disclosing assumptions (e.g. how overdue items and revenue_estimate feed the model, currency, or whether values are cumulative).

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?

Two dense sentences with no filler; the core scope (month-by-month projection and its inputs) is front-loaded, followed by the computed outputs. Slightly long clauses, but every element 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?

With seven optional parameters, no output schema, and non-trivial financial modelling, the description covers what is computed and what the result means well enough to call the tool correctly. The remaining gap is the shape of the return (monthly rows? totals? currency?) and the model's assumptions, which an agent would have to discover from the response.

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 high (86%), so the parameters are largely self-documenting and the baseline of 3 applies. The description corroborates a few of them implicitly — fixed expenses maps to monthly_expenses, amounts to set aside map to tax_fund, expected receipts map to revenue_estimate — but adds no syntax, units, or interaction rules (e.g. how include_overdue changes the first month) beyond the schema.

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?

A specific verb ("Previsione") applied to a specific resource (cash flow month by month), plus an enumeration of the inputs it combines (open invoices, recurring invoices, tax deadlines, fixed expenses) and the derived output (how much to set aside, negative-balance months). An agent can tell this is a projection tool rather than a raw report, though it never names the closest siblings (receivables_report, recurring_expenses_report, tax_estimate) to sharpen the distinction.

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?

Uses the description content to imply when the tool applies, but gives no explicit when-to-use or when-not-to-use guidance and does not point to alternatives for narrower needs (e.g. receivables_report for collections only, tax_estimate for tax accrual only). With many adjacent reporting/report tools in the sibling list, an explicit routing sentence is the missing piece.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the external dependency (VIES EU registry), that the default is a non-mutating preparation step, and that create=true performs the write. It omits what happens when VIES lookup fails or returns partial data, and says nothing about permissions or duplicate-client handling.

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 core action, then the SDI caveat, then the create flag. No filler. The density is high but every clause carries information an agent needs.

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 output schema and no annotations, yet the description tells the agent what data comes back (business name, address, verified city/province) and what the create flag does, which is the essential shape for a 7-parameter enrichment tool. Gaps remain around failure modes and the role of company_id and email, which are undocumented in both schema and description.

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 57%, so the description needs to compensate and largely does: it explains vat_number (with or without country prefix is covered by schema), create, ei_code and certified_email, and adds genuine domain meaning by noting the SDI code is not publicly available and PEC is the fallback. It adds nothing for email, country, or company_id.

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: builds a client's master data (anagrafica) from a VAT number via VIES, returning business name, address, and verified city/province. That is far more than the bare name. It does not explicitly contrast itself with the sibling create_client, so an agent must infer that this is the VIES-enriched path versus manual entry.

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 clear operating context: use it when you have a partita IVA and want registry data resolved, and it explains the preview-versus-write split ('Con create=true crea il cliente'). It also advises what to do when the SDI code is unavailable (ask the client or use their PEC). It stops short of naming alternatives or stating when not to use it.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds some behavioral value by indicating the response aggregates documents, paid amounts, open balance, and overdue amounts, but it does not say whether this is a computed snapshot, whether it paginates, or what period the 'scaduto' figure covers.

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?

A single short, front-loaded sentence with no filler. It is efficient, though the terseness borders on under-specification rather than true conciseness.

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?

There is no output schema, so the description bears the burden of explaining what comes back, and it only lists four content labels with no shape, units, or period semantics. For a financial reporting tool an agent cannot tell what fields to expect or how to interpret the open versus overdue split.

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 67%: 'from' and 'company_id' carry descriptions, while 'client_id' (the sole required parameter) has none. The description supplies no parameter meaning whatsoever — no mention of the date range, the company scoping, or how the period affects the reported balances — so it fails to compensate for the gap.

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 names a specific resource ('Estratto conto di un cliente') and enumerates the content it produces (documenti, pagato, saldo aperto, scaduto), so an agent knows this is a per-client statement/report rather than a generic list. It does not distinguish itself from near neighbors such as receivables_report or get_client, leaving the boundary implicit.

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?

There is no when-to-use or when-not-to-use guidance. With sibling tools like receivables_report, get_client, and list_issued_documents, the description gives no hint which one an agent should pick for a client-level balance question versus an aggregate receivables view.

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

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

No annotations are supplied, so the description carries the full behavioral burden, yet it only says the tool creates something. It does not state required permissions, whether the operation is reversible, how errors or duplicate archival numbers are handled, or what the response contains. The single mitigating fact is the pointer to the Fatture in Cloud API v2 schema, which at least tells the agent where the payload contract lives.

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?

Two short sentences, no filler, and the core operation is stated first. The brevity is efficient rather than padded, though for a tool with an opaque nested payload it borders on under-specification.

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?

This is a mutation tool with no annotations, no output schema, and a nested free-form `data` object whose structure is never described. An agent reading only this definition cannot construct a valid payload or predict the result; it is fully dependent on external API documentation.

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 50%: company_id is documented in the schema, but `data` is an untyped free-form object with additionalProperties {} and no description. The description does add real meaning there by naming the authoritative shape (Fatture in Cloud API v2 schema), which is more than the schema offers, though it defers rather than explains.

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 and resource ("Crea un documento d'archivio"), which an agent can separate from update_archive_document / delete_archive_document / list_archive_documents by name alone. It stops short of distinguishing it from other creators such as create_received_document or upload_attachment, so it is clear but not sibling-differentiated.

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?

There is no guidance on when to choose this over create_received_document, create_issued_document, or upload_attachment, nor any stated prerequisites or preconditions. The agent must infer the routing decision entirely from the tool name.

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

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

No annotations are supplied, so the description carries the full burden for a mutation tool. It does not state required fields, whether entries post to any balance, idempotency, or what happens on validation failure; the only behavioral hint is that the payload mirrors the Fatture in Cloud API v2 schema, which defers understanding to external documentation the agent may not have.

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?

Two short sentences, front-loaded with the purpose, with no filler. The second sentence earns its place as a schema hint, though it shifts a large informational burden onto an external reference rather than spelling anything out.

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?

This is a write operation with a nested untyped object parameter, no annotations, and no output schema, so the description is the only source of behavioral detail — and it supplies almost none. A caller would need the Fatture in Cloud v2 cashbook payload spec to use this tool correctly.

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 50%, and the uncovered parameter is the critical one: 'data' is a free-form object with additionalProperties and no property documentation. The description only points at the external API v2 schema, adding no field-level meaning, so an agent cannot construct a valid payload from the definition 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?

States a specific verb and resource ('Crea un movimento di prima nota') and clarifies scope with the parenthetical 'incassi e pagamenti', which tells the agent this covers both receipts and payments. It is not explicitly differentiated from nearby siblings such as create_receipt or create_f24, which also create money-movement-like records, so it falls short of a 5.

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?

There is no guidance on when to choose this tool over create_receipt, create_f24, or register_pending_received_documents, nor any prerequisites or preconditions. The agent must infer from the name alone when a prima nota entry is the right object to create.

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

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

No annotations are supplied, so the description carries the full burden. It discloses the domain constraint that data must follow the Fatture in Cloud API v2 schema and the e-invoicing field requirements, but says nothing about permissions, side effects, whether creation is idempotent, or what happens on validation failure.

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 short sentences, front-loaded with the action and the schema reference before the conditional e-invoicing requirements. No filler or redundancy.

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 a create tool with a single opaque nested payload and no output schema, the description covers the essential call-time knowledge. It leaves the response shape unstated, which is a minor gap for an agent that likely needs the new client's id.

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?

The `data` parameter is an opaque object with additionalProperties and no keys documented in the schema, yet the description points to the external API v2 schema and enumerates the keys required for e-invoicing, which materially fills a real gap. company_id is already documented in the schema, so that half needs no compensation.

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 concrete verb+resource ("Crea un cliente"), which is unambiguous and easily separated from siblings such as create_supplier or create_product. It does not explicitly name a sibling to contrast with, but the resource noun makes disambiguation trivial.

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?

Usage is only implied: it tells the agent what fields are needed for electronic invoicing (vat_number or tax_code, address_*, ei_code or certified_email), which is a useful precondition, but there is no guidance on when to use this versus update_client, list_clients, or client_from_vat, nor on duplicate-handling.

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

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

No annotations are supplied, so the description carries the full burden, and it does substantial work: it discloses that dry_run is TRUE by default, that the result is only a preview with totals, that nothing is transmitted to SdI until send_einvoice is called, and that the note must be bound to the original invoice. It does not cover permissions, what happens if the invoice was never sent, or whether an existing credit note blocks creation.

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 sentences, each carrying distinct load: purpose and linkage rule, the exclusivity claim, then the dry-run/send workflow. The most decision-critical fact (staged by default, nothing sent) is placed last but not buried, and there is no filler.

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 a 7-parameter mutation tool with no annotations and no output schema, the definition covers the essentials an agent needs: the reference requirement, the total/partial choice, and the two-step dry-run-then-send flow. Gaps remain around error conditions and permissions, but the core decision path is complete.

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 71%, and the schema already documents date defaulting, amount meaning partial vs total, company_id defaults, and items_list as an alternative to amount. The description adds real meaning only for dry_run, whose schema entry is bare, explaining the preview-versus-send semantics. That is a useful increment but it does not meaningfully clarify the remaining parameters.

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 ('Crea la nota di credito di una fattura'), the two supported scopes (totale o parziale), and the domain constraint that it must reference the original invoice number and date for SdI. It also distinguishes itself from everything in the sibling list by declaring it is 'l'unico modo per correggere una fattura elettronica già inviata'.

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 clear triggering context (correcting an already-sent electronic invoice) and an explicit follow-up route ('usa poi send_einvoice') for the default dry_run path. It does not contrast against adjacent siblings such as duplicate_document, transform_document, or delete_issued_document, so when-not-to-use is left implicit.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It says nothing about whether the F24 is saved as a draft or submitted, what happens on invalid data, permissions, or idempotency. The only behavioral hint is that `data` must conform to the Fatture in Cloud v2 API schema, which is useful but far from sufficient for a write operation.

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?

Two short sentences with the action stated first and the payload hint second; nothing is wasted. It is perhaps too terse given the complexity of the opaque `data` payload, but structurally sound.

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 tool takes a nested, schema-less object and has no output schema and no annotations, so the description should explain the payload's minimum content, the create semantics, and the return value. Instead it defers entirely to an external API reference, leaving an agent without enough information to construct a valid call confidently.

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 50%: company_id is documented in the schema, while `data` is an unconstrained free-form object with no properties. The description compensates by pointing to the external Fatture in Cloud v2 API schema for the payload shape, which is genuinely additive information the schema cannot express, though it gives no version reference or field examples.

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 states a specific verb and resource ("Crea un modello F24"), which distinguishes it from the read/update/delete F24 siblings by action. It stops short of naming those siblings or the object's scope, but the operation is unambiguous.

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?

There is no guidance on when to create an F24 versus calling update_f24 on an existing one, no preconditions (e.g. company selection, required identifiers), and no mention of what the tool does with the created form afterwards.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It does add genuinely useful behavior: numbering is automatic when `number` is omitted, and the stamp-duty rule for forfettari is a domain-specific side effect most agents would miss. However it never says whether the document is created as a draft or finalized, whether e-invoicing is triggered (a separate send_einvoice tool exists), what permissions are needed, or whether the operation is reversible.

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?

Five tight sentences, front-loaded with the purpose, then the schema pointer, then the two field-level rules, then the alternative tool. No filler and no repetition of what the name already says.

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 a create tool built around an opaque nested payload, the external-schema pointer plus field hints is a sensible and largely sufficient approach, and no output schema means return values need not be described. Gaps remain around draft-vs-finalized state, whether this triggers e-invoicing or emailing, and which keys `data` requires — all material for a mutation tool with zero annotation coverage.

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?

`data` is an unconstrained free-form object (additionalProperties: {}), so the schema alone is useless; the description rescues it by pointing to the Fatture in Cloud API v2 schema and then highlights two specific fields (`number`, `stamp_duty`) with the exact conditional value. The other two params are already documented in the schema at 67% coverage. It still leaves required fields inside `data` unstated, so not a 5.

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 ('Crea') plus resource ('documento emesso') and enumerates the concrete document types it covers (invoice, credit note, proforma, quote, order, DDT). This is far more informative than the bare name. It stops short of 5 because the sibling create_credit_note overlaps with the 'nota di credito' case it claims to handle, and the description never says which one to prefer.

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 gives concrete when-to guidance: omit `number` for automatic numbering, add `stamp_duty: 2` for flat-rate taxpayers above €77.47, and use duplicate_document to repeat an existing document — an explicit named alternative. What is missing is routing against create_credit_note and transform_document, both of which sit adjacent to this tool's stated scope.

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

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

With no annotations, the description carries the full burden: it discloses that this is a create operation and points to the Fatture in Cloud API v2 schema for the payload, which is genuinely useful. However, it says nothing about permissions, duplicate handling, defaults applied server-side, or what a successful creation returns.

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 short sentences, front-loaded with what is created and followed by the payload contract and field list. No filler, and the most decision-relevant information comes first.

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 a create tool with a nested free-form object, no annotations and no output schema, the description covers the entity and the payload vocabulary, which is the core need. It leaves gaps on required fields, the company_id default behavior, and the result of the call, so it is adequate but not fully complete.

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 50% and the `data` parameter is a free-form object with no declared properties, so the description is the sole source of field names (name, type, iban, sia, cuc, virtual) and the type enum values (standard/bank). It still omits which fields are mandatory and the types of the remaining 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 ('Crea un conto di saldo') and enumerates the concrete kinds (banca, cassa, carta), so an agent knows exactly what entity is produced. It does not explicitly contrast with the close siblings update_payment_account/delete_payment_account/list_payment_accounts, though the create verb makes the distinction reasonably obvious.

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 phrase 'su cui registrare incassi e pagamenti' implies the purpose (accounts that back receipts and payments), which gives implicit when-to-use context. There is no explicit prerequisite, no when-not guidance, and no mention of which sibling to use for modifying an existing account.

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

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

No annotations are supplied, so the description carries the full burden for a mutation tool. It says nothing about required permissions, whether a method name must be unique, what happens on duplicate/conflict, or what the response contains; only that `data` mirrors the external API v2 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, front-loaded with what is created and immediately followed by the payload source and e-invoicing specifics. Nothing is redundant, though the reference to an external API schema is terse enough to be ambiguous about which fields are mandatory.

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 a create tool with a free-form nested object, no output schema, and no annotations, the description gives the essential pointers but not enough to call it safely without consulting external docs. The unsupported `data` payload is the main remaining gap.

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 50%: company_id is self-documented, but `data` is an untyped object with additionalProperties {} and no shape at all. The description partially compensates by pointing to the Fatture in Cloud API v2 schema and naming key sub-fields (ei_payment_method, details: [{title, description}]), which is real added meaning but leaves most of the payload opaque.

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 ('Crea un metodo di pagamento') plus where it surfaces ('mostrato in fattura'), so the agent can tell it apart from create_payment_account/list_payment_methods. It does not explicitly distinguish payment method from payment account, which is the closest sibling, so it stays below a 5.

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?

Usage is only implied: it names the invoice context and gives field-level guidance for electronic invoicing (ei_payment_method like MP05, details array). There is no statement of when to use this instead of create_payment_account or update_payment_method, and no prerequisites or exclusions.

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

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

No annotations are supplied, so the description carries the full behavioral burden, yet it only says it creates a catalog entry. It does not mention duplicate-name handling, validation failures, required business fields, permissions, or reversibility — all relevant for an unannotated mutation tool.

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?

Two short sentences with the action front-loaded and no filler. However, the extreme brevity leaves the bulk of the payload unexplained, so conciseness comes at the cost of usefulness.

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?

With a nested, completely undocumented `data` object, no output schema, and no annotations, the description should explain at least the shape or key fields of the product payload. Instead it defers entirely to external API documentation an agent may not have access to.

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 50%: company_id is documented in the schema with its default fallback, but `data` is an open object with no property documentation. The description only points to 'the Fatture in Cloud API v2 schema', which is an external reference rather than inline meaning, so it does not compensate for the undocumented nested payload.

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 ('Crea un prodotto o servizio a listino'), which clearly distinguishes it from siblings like update_product or create_client. It does not explicitly name alternatives, but the verb+resource pair is unambiguous.

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?

There is no guidance on when to use this versus update_product, list_products, or create_client/create_supplier, and no mention of prerequisites such as needing an existing price list or company context. The agent must infer the entire usage context from the tool name.

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

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

With no annotations supplied, the description carries the full burden of behavioral disclosure. It says only that it creates something; it does not state that the operation is a non-reversible write, whether numbering/registration is applied, what validation errors may occur, or what the response contains.

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?

Two short sentences, front-loaded with the verb and resource, with zero filler. The second sentence is a compact pointer rather than an explanation, which is efficient but leaves the definition thin.

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 a mutation tool with a free-form nested payload, no annotations, and no output schema, the description is far too sparse: it delegates the entire payload specification to external API documentation without any summary of required fields or required permissions.

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 50% and the required `data` parameter is a free-form nested object with no schema description at all. The sentence '`data` segue lo schema dell'API v2 di Fatture in Cloud' is genuinely useful because it tells the agent where to find the shape of an otherwise opaque payload, though it adds nothing about company_id (which the schema already documents).

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 ('Crea un corrispettivo') and disambiguates the Italian term with the parenthetical '(scontrino / ricevuta giornaliera)', so an agent knows a daily receipt is being created. It does not explicitly name the create/update/delete receipt siblings, but the CRUD verb makes the distinction obvious.

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?

There is no guidance on when to use this instead of create_issued_document or create_received_document, nor any mention of prerequisites, prerequisites around company selection, or whether the document is created as draft or final. The agent must infer all usage context from the tool name.

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

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

With no annotations supplied, the description carries the full disclosure burden. It does contribute one genuinely valuable behavioral constraint — that payments_list must cover the whole amount_gross even for simple expenses, a common cause of API rejection — but says nothing about the created document's resulting state (draft vs registered), duplicate detection, or what the response contains. This is partial coverage for a mutation tool.

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 short sentences with no filler, front-loading the resource and document types before the payload constraints. The only inefficiency is the reliance on an external schema reference rather than a self-contained statement, which is compact but shifts work onto the reader.

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 a create tool whose main parameter is an entirely freeform nested object, no output schema, and no annotations, the description is thin. An agent cannot determine the minimum viable payload, whether the document lands in draft, or how failures manifest, and must consult external API v2 documentation it may not have.

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 description coverage is 50%: company_id is fully documented in the schema with its default resolution, while `data` is a freeform object with additionalProperties and zero structural documentation. The description mitigates this only by pointing to the external Fatture in Cloud API v2 schema and calling out the payments_list/amount_gross rule, leaving the bulk of the nested payload semantics to outside knowledge.

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 ('Crea un documento ricevuto') and enumerates the covered subtypes (spesa, nota di credito passiva, DDT passivo), which lets an agent distinguish it from create_issued_document or create_receipt. It stops short of explicitly naming any sibling as an alternative, so it is clear but not fully differentiated.

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 enumeration of document types implies when the tool applies, and the note about payments_list implies a precondition for calling it. However, there is no explicit guidance on when to use create_received_document versus create_archive_document, register_pending_received_documents, or create_receipt, and no mention of required prerequisites such as supplier or VAT type setup.

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

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

No annotations are provided, so the description carries the full behavioral burden. It never says whether creation is idempotent, whether duplicate VAT numbers are rejected, what permissions or company scoping are required, or what the response contains after a successful create.

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?

Two short sentences, front-loaded with the action and immediately followed by the payload note. Nothing is wasted, though the terseness is partly under-specification rather than efficiency.

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 a mutation tool taking a free-form nested `data` object with no output schema and no annotations, the definition is well short of complete. An agent cannot determine the payload shape, success behavior, or error conditions from this description alone.

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?

The schema documents company_id but leaves `data` as a bare object with additionalProperties, so the description's only contribution is a pointer to the external "API v2 di Fatture in Cloud" schema. That pointer helps locate the shape but does not explain required fields, nested structures, or validation rules inline, which is a real gap for a nested-object payload.

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?

"Crea un fornitore" states a specific verb plus resource, which is unambiguous and matches the tool name. It does not distinguish this from sibling mutations such as update_supplier or create_client, but the create semantic is clear enough to act on.

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?

There is no guidance on when to use this versus update_supplier (e.g., create-vs-upsert behavior), no prerequisites, and no mention of what to do if the supplier already exists. The agent must infer usage from the name alone.

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

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

No annotations are supplied, so the description carries the full burden. It discloses that `data` follows the Fatture in Cloud API v2 schema and adds a real behavioral constraint (ei_type needed for non-VAT natures), but says nothing about required permissions, whether creation is idempotent, what happens on duplicate rates, or what is returned.

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 short sentences, front-loaded with the action and then the payload convention. No filler, though the API-version reference is terse enough that it may leave the reader needing external documentation.

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 a mutation tool with a nested free-form object and no annotations or output schema, the definition covers the essential shape but outsources field-level detail to an external API doc the agent may not have. Return values and error behavior are omitted, which is acceptable only because there is no output schema to lean on.

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 50%: company_id is documented in the schema, while `data` is an opaque object with additionalProperties. The description partially compensates by pointing to the API v2 schema and naming the ei_type field, but it does not enumerate the fields `data` accepts, leaving the main parameter underspecified.

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 ("Crea") and resource ("un aliquota IVA o natura di esenzione"), so the agent knows this creates a VAT rate or exemption nature. It does not explicitly contrast itself with update_vat_type, but the create verb makes the distinction from update/list/get siblings clear enough.

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 one useful conditional: for operations without VAT, supply ei_type (nature, e.g. N2.2) plus a regulatory description/reference. It does not say when to use this versus update_vat_type or duplicate an existing rate, nor mention prerequisites like permissions.

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

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

The destructiveHint=true annotation already flags this as a destructive operation, so the description's main added value is disclosing that deletion is soft ("finiscono nel cestino") and reversible via recover_document. That is genuinely useful context beyond the annotation, though it omits permission requirements, the company scoping behavior, and whether/when trash items are purged permanently.

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?

Two short sentences with zero waste; the action is front-loaded and the recovery consequence follows immediately. 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?

For a simple two-parameter destructive tool with an annotation covering the safety profile, the description supplies the essential missing piece (soft delete plus recovery route). Remaining gaps, such as parameter roles and the permanent-purge timeline, are minor.

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 description coverage is 50%: company_id is documented in the schema but id is not, and the description says nothing about either parameter. It neither clarifies what id refers to (archive document identifier) nor explains the company_id default or scoping implications, so it adds no meaning beyond the schema.

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 states a specific verb and resource ("Elimina un documento d'archivio"), which lets an agent distinguish it from the many sibling deletes (delete_received_document, delete_issued_document, delete_receipt) by resource type. It stops short of explicitly naming those siblings, so it is clear but not maximally differentiating.

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?

Usage is only implied: delete an archive document when you want it removed. The description does point to the recovery path ("si recuperano con recover_document"), which is a useful alternative reference, but it gives no explicit when-to-use/when-not-to-use guidance relative to update_archive_document or the other delete_* tools.

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

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

destructiveHint=true already tells the agent this is a destructive write, so the description only adds the identity of the deleted object. It says nothing about irreversibility, whether a deleted entry can be recovered (notably sibling tools recover_document and list_deleted_documents exist), or whether dependent records are affected.

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?

A single short sentence with zero filler, front-loading the action and resource. It is efficient, though the brevity is a symptom of under-specification rather than discipline.

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 a destructive mutation with no output schema and an undocumented required identifier, the definition leaves too much unsaid: no confirmation semantics, no error behavior, no recoverability note. It is not complete enough for an agent to invoke safely without inspecting the schema and guessing.

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 50%: company_id is documented in the schema, but the required id parameter has only a type and integer bounds, with no meaning given in the schema and none added by the description. Whether id is the cashbook entry ID and what happens on an unknown id is left entirely implicit.

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 ("Elimina") and a specific resource ("movimento di prima nota"), and clarifies the domain as receipts and payments. It does not explicitly differentiate itself from update_cashbook_entry or delete_receipt, but the named resource is unambiguous enough to separate it from siblings.

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?

No guidance on when to delete versus update or void an entry, no preconditions, and no warning that the operation is irreversible. The agent must infer the entire usage context from the name alone.

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

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

The destructiveHint annotation already tells the agent this is a destructive operation, so the description's job is to add context such as permanence, cascading effects on linked documents, or required permissions — it supplies none of this. It does not contradict the annotation, but it is a bare restatement of a mutation.

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?

It is short with no filler, but the brevity comes from under-specification rather than economy — there is no front-loaded scope, target, or warning to anchor the call.

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 a destructive, irreversible-style operation with 50% parameter coverage and no output schema, the description omits the essentials: whether deletion is permanent, what happens to clients referenced by existing documents, and what the call returns or errors on.

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 50%: company_id is documented in the schema, but the required id parameter is undocumented anywhere. The description does nothing to compensate, so the agent must guess whether id is a client identifier and what happens if company_id is omitted.

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?

"Elimina un cliente" only restates the tool name (delete_client) in another language; it adds no scope, no constraints, and no differentiation from siblings such as delete_supplier or update_client. An agent learns nothing it could not infer from the identifier alone.

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?

There is no guidance on when to use this versus alternatives (e.g., update_client to deactivate, or whether related records must be handled first). No preconditions, no exclusions, no mention of a confirmation or recoverability step.

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

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

Annotations already declare destructiveHint=true, so the safety profile is known, but the description adds nothing beyond that: it does not state that deletion is irreversible, whether related records or attachments are affected, or what the caller gets back. For a destructive one-way operation this leaves the real behavioral questions unanswered.

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?

It is a single short sentence with no filler, so there is nothing to trim. The problem is the opposite of verbosity: the sentence is under-specified rather than wasteful.

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 a destructive mutation with no output schema and only half the parameters documented, the description should carry more weight than one sentence. An agent is left without confirmation of irreversibility, cascade effects, or return behavior.

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 description coverage is only 50%: company_id is documented in the schema but id has no description, and the description text contributes nothing about either parameter. It neither explains that id is the F24 identifier nor clarifies the company scoping fallback, so it fails to compensate for the coverage gap.

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 names a specific verb ("Elimina") and resource ("modello F24"), so an agent can tell it removes an F24 record. However, it largely translates the tool name delete_f24 rather than adding scope, and it does not distinguish itself from sibling mutations like update_f24 or from delete_* tools on other resources.

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?

There is no when-to-use guidance at all: nothing says under what conditions an F24 should be deleted rather than updated or left alone, and no alternative tool is mentioned. The agent must infer usage purely from the verb in the name.

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

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

Annotations only carry destructiveHint=true; the description adds substantive behavior beyond that by disclosing that documents are moved to a trash (cestino) and are recoverable via recover_document, so the agent knows the effect is reversible. It does not cover restrictions on deletion, side effects on numbering, or what the response returns, but for a two-sentence description this is meaningful disclosure that does not contradict the annotation.

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?

Two sentences, front-loaded with the verb and resource, then the recovery behavior. The document-type list earns its place by helping the agent match user intent, and there is no filler.

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?

With no output schema and only a destructiveHint annotation, the description carries most of the burden and does supply the reversibility story and target scope. The remaining gap is the absence of any constraint about which issued documents may not be deleted, which matters for a destructive tool in a billing domain.

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 50% and the `id` parameter has no schema description at all. The description indirectly resolves this by framing the target as an issued document, telling the agent which resource namespace the id belongs to, but it adds nothing about `company_id` or about id format/nonexistence handling. Baseline 3 for the partial coverage.

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+resource ("Elimina un documento emesso") and enumerates the affected document types (fattura, nota di credito, proforma, preventivo, ordine, DDT), which lets an agent distinguish this from delete_received_document and delete_archive_document without opening a schema. It stops short of naming those siblings explicitly, so it is clear rather than airtight.

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?

Usage is implied rather than stated: the agent learns deletion is soft and that recover_document is the undo path, which is genuine routing information. There is no explicit when-to-use/when-not guidance and no stated preconditions (e.g. whether documents already sent to SDI or already paid can be deleted), leaving real ambiguity for a destructive operation with many delete_* siblings.

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

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

Annotations already declare destructiveHint=true, so the safety profile is known. The description adds domain context — that the account is used to record receipts and payments — which hints at possible referential constraints, but it never says whether the deletion is permanent, blocked when transactions exist, or requires specific permissions.

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?

A single short sentence with the verb front-loaded and no filler. Nothing in it is redundant.

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 a destructive mutation with an undocumented required parameter and no output schema, the description should cover irreversibility, dependency handling, and the identifier to supply. None of that is present, so an agent could invoke it incorrectly.

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 50%: company_id is documented in the schema, but the required id parameter has no description anywhere. The description adds no meaning about which identifier is expected or how it is obtained, so it fails to compensate for the schema gap.

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?

Description states a specific verb ("Elimina") and resource ("conto di saldo"), clarified with concrete examples (banca, cassa, carta), so an agent knows exactly what is removed. It does not explicitly differentiate itself from sibling update_payment_account or list_payment_accounts, but the delete verb is unambiguous.

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?

There is no guidance on when to delete versus update or deactivate an account, and no preconditions are stated (e.g., whether an account with linked cashbook entries can be removed). The agent must infer the usage scenario entirely from the verb.

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

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

The destructiveHint annotation already tells the agent this removes data, so the description only needs to add context. It contributes the fact that the target is an invoice-displayed payment method, but says nothing about irreversibility, what happens to existing documents referencing the method, or required permissions.

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?

A single short sentence with the verb and scope front-loaded and no filler. Its brevity is appropriate, though it borders on under-specification given the tool is destructive.

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 a destructive mutation with no output schema and half its parameters undocumented, the description should carry more weight. It omits what the deletion does to invoices already using the method, whether it can be undone, and how company_id is resolved.

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 description coverage is only 50%: company_id is documented in the schema, but id carries no description. The description adds no parameter meaning at all and does not explain the company-scoping default (FIC_COMPANY_ID or the token's single company), leaving the undocumented required id entirely unretailed.

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 concrete verb and resource ("Elimina un metodo di pagamento") and narrows scope to methods shown on invoices, with an example (bonifico con IBAN). It does not, however, distinguish itself from nearby siblings such as delete_payment_account, which an agent could easily confuse with a payment method.

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?

No guidance on when to delete versus update or simply stop using a payment method, and no mention of the sibling tools that would handle adjacent tasks. The invoice-scoping phrase implies usage context but states no conditions or exclusions.

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

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

destructiveHint=true already tells the agent this is a destructive mutation, so the safety profile is covered by structured data. The description adds nothing beyond that: no statement about irreversibility, whether the deletion is soft (cf. list_deleted_documents/recover_document) or hard, or what happens to references. For a deletion tool this is a real gap.

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?

A single short sentence with the operation front-loaded and zero filler. It is efficient, though its brevity comes at the cost of under-specification rather than being genuinely complete.

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 a destructive, id-required mutation with no output schema and an undocumented required parameter, the definition says far too little. It should at minimum cover reversibility/soft-delete behavior and confirm what the id refers to.

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 50%: company_id is documented in the schema, but the required 'id' has no description at all. The description adds no meaning about what the id identifies or whether company_id scoping affects the deletion, so it fails to compensate for the coverage gap.

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 names a specific verb and resource ('Elimina un prodotto o servizio a listino'), so an agent immediately knows this removes a catalog product/service. It does not, however, distinguish itself from the many sibling delete_* tools (delete_supplier, delete_vat_type, delete_client), relying on the name alone for that routing.

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?

There is no guidance on when to use this versus update_product (e.g., deactivate/hide instead of delete) or list_products/get_product for finding the id first. No prerequisites, no mention of consequences for products already referenced on issued documents.

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

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

destructiveHint=true already establishes that this mutates data, so the description would need to add value: whether deletion is permanent or recoverable (recover_document and list_deleted_documents exist as siblings), whether related records cascade, or what auth/company scoping applies. None of that is present, so nothing is added beyond the annotation.

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?

A single front-loaded sentence with a useful parenthetical gloss and no filler; it does not waste the reader's time. It is, however, terse to the point of leaving gaps better filled here than nowhere.

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 a two-parameter tool with no output schema and one annotation, the description covers the bare minimum of what the tool does. Given that this is a destructive operation in a crowded family of delete_* tools, the absence of reversibility and scoping information leaves it short of what the complexity warrants.

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 50%: 'id' carries no description at all, and the description never says what that id identifies (a corrispettivo id as returned by list_receipts/get_receipt) or how company_id interacts with it. With a coverage gap this size the description should have compensated and does not.

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 ('Elimina un corrispettivo') and glosses the domain term with '(scontrino / ricevuta giornaliera)', so the object of the operation is unambiguous. It does not, however, distinguish this from near-identical siblings such as delete_received_document, delete_issued_document, or delete_f24, which an agent must choose between.

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?

There is no when-to-use guidance, no statement of prerequisites or permissions, and no pointer to the sibling alternatives (e.g. delete_received_document vs delete_issued_document). The only usage signal available is the destructiveHint annotation, which the caller must infer from rather than being told directly.

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

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

The destructiveHint=true annotation already flags this as a write/destroy operation, but the description adds the crucial behavioral fact that the deletion is a soft delete into a trash bin and is reversible via recover_document. That changes an agent's risk calculus materially and is genuine value beyond the annotation. It does not cover authorization requirements or behavior when the document is already deleted.

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?

Two short sentences, front-loaded with the action and resource, then the recoverability note. No filler, no repetition of the tool name, and every clause carries information.

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 a destructive, no-output-schema tool, the description covers what is affected and that it is recoverable, which is the information an agent most needs before calling it. Minor gaps remain: no mention of permission requirements, error behavior on an already-deleted or nonexistent id, or confirmation of which id domain is expected.

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 50%: company_id carries a description with its fallback default, while id is undocumented but self-evident given the tool name. The description adds no parameter meaning beyond the schema (it never states that id is the received-document identifier or whether it accepts a UUID vs numeric ID). With the schema doing most of the work on a two-parameter tool, a baseline 3 is appropriate.

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 states a specific verb ('Elimina') and a specific resource ('un documento ricevuto'), and even enumerates the document subtypes it covers (spesa, nota di credito passiva, DDT passivo). An agent can distinguish it from delete_issued_document or delete_receipt by the resource noun, though those siblings are never named explicitly.

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 gives clear usage context by explaining that deletion is non-final and the recovery path is recover_document, which effectively names the alternative tool for undoing the action. It stops short of stating when-not-to-use (e.g. prefer update_received_document or archive instead of deleting), so it is not a full 5.

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

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

The destructiveHint annotation already signals this is a destructive operation, but the description adds nothing beyond that: it does not say whether the deletion is permanent or soft, whether it cascades to received documents or references, or what errors occur when the supplier is in use. For a destructive operation this is a significant gap.

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 single sentence contains no filler, but brevity here reflects under-specification rather than efficiency. Nothing is front-loaded about consequences or scope because nothing beyond the verb is present.

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 a destructive mutation with an undocumented required parameter and no output schema, the description should disclose irreversibility, side effects on related records, and failure conditions. None of that is present, leaving the definition insufficient for safe invocation.

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 description coverage is only 50%: company_id documents its default fallback, but the required id parameter has no description in either the schema or the tool description. The description offers no compensation, so the agent gets no confirmation that id refers to a supplier identifier or how to obtain it.

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?

"Elimina un fornitore" translates directly to "delete a supplier," which is a restatement of the tool name delete_supplier rather than an explanation of its scope. It gives no detail distinguishing it from siblings like update_supplier or get_supplier beyond the verb implied by the name itself.

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?

There is no guidance on when to delete a supplier versus updating or deactivating one, and no mention of prerequisites such as whether the supplier must have no linked documents. The agent must infer all usage conditions from the name alone.

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

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

The destructiveHint annotation already declares this as a destructive operation, so the description's only job is to add context — and it adds none. It does not say whether deletion is permanent, what happens to documents referencing the VAT rate, or what error occurs if the rate is in use. For a destructive mutation this is a significant gap, though it does not contradict the annotation.

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?

A single short, front-loaded sentence with no filler. It is efficient, though the brevity contributes to the under-specification noted elsewhere.

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 a destructive tool with no output schema and a required undocumented identifier, the description should cover irreversibility and referential constraints. It covers none of this, so an agent has no basis for judging the consequences of a successful call.

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 50%: company_id is documented in the schema with its default resolution, but the required 'id' has no description. The description never clarifies that 'id' is the VAT type identifier nor relates it to list_vat_types/get_vat_type, leaving half the parameters unexplained in both places.

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?

Names a specific verb (Elimina) and resource (aliquota IVA / natura di esenzione), which tells an agent exactly what is removed. It does not differentiate itself from the sibling delete/update tools by name, but the resource is unambiguous.

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?

There is no guidance on when to delete versus deactivate or update via update_vat_type, and no mention of prerequisites such as whether the rate must be unused. The intended usage is only inferable from the tool name.

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

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

With no annotations supplied, the description carries the full burden and does well: it discloses the side effects that matter most (the copy is not sent to SdI and not emailed), explains that deadlines shift by the original interval, and offers a dry-run preview path. It omits whether the copy lands as a draft, any permission/numbering prerequisites, and what is returned.

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 sentences, front-loaded with the identity of the operation and its preserved/regenerated fields, then the side-effect caveat, then the dry_run tip. The parenthetical "(come «Duplica», ma completo)" is a small waste but everything else 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?

For a 6-parameter tool with a nested overrides object, no annotations and no output schema, the description covers the copy semantics and safety caveats well but leaves the override capability entirely undocumented and says nothing about the returned document or its initial state. An agent could call it correctly, but not exploit it fully.

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 67%, so the schema already documents date, number, company_id and the rich overrides template syntax. The description adds real meaning for date/number by explaining they are regenerated (new date, next free number) rather than copied, but it never mentions the large nested overrides object, which is the highest-complexity part of the schema.

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 and resource ("Copia un documento esistente") and enumerates exactly what is preserved (cliente, righe, bollo, metodo e conto di pagamento) versus what is regenerated (nuova data, numero successivo, scadenze spostate). It does not, however, distinguish itself from close siblings such as bulk_duplicate, transform_document or create_issued_document, so an agent must infer the boundary.

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?

There is one concrete usage instruction — use dry_run=true to preview before creating — which is genuinely actionable. But there is no guidance on when to choose this over bulk_duplicate, transform_document, or plain create_issued_document, and the 'when not to use' case is only implied by the no-SdI/no-email note.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds one piece of value beyond the annotations — that the response includes remediation instructions, not just a code — which matters since there is no output schema. It says nothing about preconditions (must the invoice actually be rejected?) or about what happens when no rejection exists.

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?

A single compact clause with no filler, and the key concept (rejection reason) is front-loaded. It is efficient, though the brevity comes partly at the cost of the guidance dimensions above.

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 a two-parameter read tool with no output schema, the description covers the 'what' but leaves the identifier's meaning and the lookup's preconditions unstated. Adequate to attempt a call, but an agent has to guess what 'id' refers to when constructing it.

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 50%: company_id is documented, but the required 'id' has no schema description. The description does not clarify that 'id' is the document/invoice identifier or how scope interacts with company_id, so it fails to compensate for the coverage gap.

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 names a specific resource and outcome: the SdI rejection reason of an electronic invoice, plus correction guidance. An agent can tell this is a diagnostic lookup rather than a CRUD operation. It does not, however, distinguish itself from near-neighbours such as verify_einvoice or get_einvoice_xml, so it stops short of a 5.

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?

There is no when-to-use guidance at all: nothing says to call this after a rejected send, nor that verify_einvoice or get_einvoice_xml are the alternatives for different questions. The agent must infer the trigger condition from the tool name alone.

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

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

The annotations only carry openWorldHint=true, so the description must supply the rest. It usefully discloses that sender, recipient, subject and body are pre-filled from the Fatture in Cloud account settings, which is real context beyond the schema, but it does not state that the mail is dispatched immediately and irreversibly, nor what permissions or failure modes apply.

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?

Two short sentences with no filler, and the outbound action is front-loaded ahead of the defaults note. Slightly weaker only because the second sentence reads as a single merged clause rather than a clearly separated behaviour note.

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 a single-shot side-effecting send with no output schema and only one required parameter, the description covers what the tool does and where defaults come from, which is close to sufficient. The missing piece is confirmation of immediate dispatch/unrecoverability, which matters for an outbound-email mutation.

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 description coverage is 57%, and the description compensates by signalling that the sender/recipient/subject/body parameters are optional because defaults exist, and that a PDF can be attached. It still adds nothing about the required id, send_copy, company_id, or the comma-separated recipient_email format.

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?

"Invia il documento per email al cliente" states a specific verb (invia) and resource (documento) plus the channel (email) and the fact that link and PDF are included. It is clearly distinct from send_einvoice or list_sent_emails, though it never names those siblings explicitly.

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?

Usage is only implied: an agent can infer this is the tool for emailing an existing document to a customer, but the description gives no explicit conditions, no prerequisites (e.g. document must exist / be issued), and does not route to bulk_email or send_einvoice for the related cases.

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

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

readOnlyHint=true already tells the agent this is a safe read, and the description only adds the vague qualifier "completo", which hints the payload is fuller than a list entry but doesn't say what fields or related data come back. No mention of error behavior for a missing id or of cross-company access implications.

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?

It is a single short sentence with no padding, but brevity here comes at the cost of substance rather than from disciplined editing. There is no structure beyond one noun phrase.

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?

With no output schema, an undocumented id parameter, and no annotations beyond readOnlyHint, the description should explain what a "complete detail" includes and how the id is sourced. For a 2-parameter retrieval tool it leaves too much to inference.

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 50%: company_id is documented in the schema, but id carries no description. The description does not explain that id refers to an archive document identifier or that company_id resolves to a default company, so it fails to compensate for the gap.

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 phrase "Dettaglio completo di un documento d'archivio" does convey retrieving a single archive document in full, which implicitly contrasts with list_archive_documents. However, it never uses a retrieval verb and never names the sibling or the required identifier, so the agent must infer that this is the get-one counterpart.

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?

There is no when-to-use guidance, no mention of alternatives such as list_archive_documents, and no stated prerequisite for obtaining the id. The agent gets no routing logic beyond the name.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description's only added behavioral content is the domain hint that entries are receipts and payments. It says nothing about what happens when the id is not found, whether the detail spans linked documents or installments, or what scoping company_id imposes beyond what the schema already states.

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?

One short sentence with the resource and the "complete detail" qualifier front-loaded; there is no filler. It is however on the terse side for a tool whose return shape is undocumented.

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 a simple two-parameter read tool with readOnlyHint and no output schema, the definition is barely sufficient: it identifies the entity but never indicates what the "full detail" contains. Since no output schema exists, some indication of return content would have been valuable.

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?

The company_id parameter is well documented in the schema (including its default resolution), while id has no description at all, leaving coverage at 50%. The description clarifies that the id identifies a cashbook movement, but adds no format or constraint details beyond that.

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?

Names the resource precisely ("un movimento di prima nota") and the operation ("dettaglio completo"), and the parenthetical "(incassi e pagamenti)" scopes which entries are covered. It implicitly contrasts with list_cashbook_entries by promising full detail of a single entry, though it never names that sibling.

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?

Usage is only implied: "dettaglio completo" signals fetching one record's full detail rather than a list, but there is no explicit when-to-use statement, no mention of the list_cashbook_entries alternative, and no preconditions (e.g. that the entry must exist or belong to the given company).

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

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

readOnlyHint=true already establishes this is a safe read, so the bar is lower, yet the description adds essentially nothing beyond "complete detail" — no mention of what happens with an invalid or foreign-company id, nor of error behavior. Since there is no output schema, the description should have described what "complete detail" actually contains, and it does not.

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?

A single short sentence with no wasted words, but the brevity comes at the cost of nearly all substantive content. It is efficient rather than well-structured or front-loaded.

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 a simple two-parameter read tool this is thin: no output schema exists, the required id has no documentation anywhere, and the description never explains what the returned "complete detail" comprises. An agent could call it, but with little confidence about the identifier format or response shape.

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?

The description is silent on both parameters. With only 50% schema coverage, the undocumented required "id" parameter is left for the agent to guess, and the company_id fallback semantics (FIC_COMPANY_ID or the token's only company) are only found in the schema, not reinforced or explained in the description.

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?

"Dettaglio completo di un cliente" identifies the resource (a single client) and indicates a full-record retrieval rather than a list, which implicitly separates it from list_clients. However, there is no explicit verb and no stated contrast with siblings like get_supplier or list_clients, so the agent must rely on the tool name for the operation.

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?

There is no guidance on when to call this versus list_clients or client_statement, and no prerequisites such as needing a valid client id. The agent must infer usage entirely from the name.

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

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

The readOnlyHint annotation already establishes the safety profile, so the description only needs to add context. It does add what the payload contains and that plan usage is optional, but it says nothing about the default company resolution behavior or the shape of the returned plan-usage breakdown.

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?

One compact sentence that front-loads the resource and parenthetically lists the returned sections. Nothing is wasted, though the parenthetical list is slightly compressed and could separate the optional flag more clearly.

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 a two-parameter read-only getter with no output schema, the definition covers what data comes back and the optional flag. It is adequate but thin: nothing describes the structure of the returned company object or how the default company is resolved when company_id is omitted.

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 50%: company_id is documented in the schema, but plan_usage has no schema description. The description compensates by explaining that the flag yields plan usage per category, giving the boolean meaning beyond its name, though it still omits units or granularity of that breakdown.

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 the resource (company data) and enumerates the three domains returned: registry, plan, settings, plus the optional plan usage. It is a clear read operation, but it does not distinguish itself from the sibling list_companies, so an agent must infer that this one returns details for a single company.

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?

There is no guidance on when to call this versus list_companies, api_quota, or tax_profile_get. The only conditional hint is 'se richiesto' for plan usage, which is a parameter note rather than a usage rule, and no prerequisites or exclusions are stated.

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

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

The readOnlyHint annotation already marks this as a non-mutating read. The description adds real value by disclosing that without save_to it returns a link, while with save_to it writes the PDF to a file or folder. That local filesystem write is a side effect worth noting against a readOnly annotation, though it concerns the caller's disk rather than backend data, so it is a tension rather than a clear contradiction. It does not describe the link format or errors for unsupported document types.

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?

Two compact sentences with no padding, and the core purpose (PDF link) is front-loaded. The parenthetical scope note is efficient rather than redundant. Slightly terse given what is left unsaid, but nothing wasteful.

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 a 3-parameter tool with no output schema, the description conveys the main behavior and the save_to effect adequately. However, it never clarifies what the id references, what the returned link looks like, or whether behavior differs across the covered document types. Adequate but with clear gaps for a tool whose output (a link) is central.

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 description coverage is only 33% (id and save_to have no schema descriptions), so the description carries extra weight. It does explain save_to's effect (downloads to a file/folder), but leaves id and the link-versus-download default implicit. It partially compensates for the coverage gap but not fully.

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+resource: it returns the PDF link of a document, and notes it also covers DDT and accompanying invoices (fattura accompagnatoria). This is clearer than a bare name restatement. It stops short of distinguishing itself from the many sibling document getters (get_issued_document, get_received_document), but the retrieval target (the PDF) is unambiguous.

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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives among the dozens of sibling document tools. The only contextual cue is that save_to triggers a download, which is parameter behavior rather than usage routing. An agent must infer on its own when to reach for this versus the other get_* document tools.

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

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

readOnlyHint=true is consistent with the description — no API resource is mutated, and the description discloses the two output modes (save to file vs return in response). However, it does not clarify that save_to causes a local filesystem write, nor what the returned content looks like (raw string, base64, size) when save_to is omitted.

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?

Two short, front-loaded sentences with zero filler: the core action first, then the branching behavior of save_to. Every clause carries information.

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 a simple read-only retrieval tool the essentials are present, and the return-vs-save behavior is spelled out despite there being no output schema. The gaps — semantics of include_attachment and the exact shape of the returned XML — keep it from being complete.

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 description coverage is only 25%, so the description needs to compensate. It does explain save_to's dual meaning (file path or folder), which the bare schema does not, but leaves include_attachment and the meaning of id (document identifier, presumably) entirely undocumented in both places.

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 states a specific verb and resource: 'Scarica l'XML FatturaPA di un documento' (downloads the FatturaPA XML of a document). This clearly separates it from the get_document_pdf sibling, though it never names an alternative explicitly.

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 gives a concrete usage rule for one branch: with save_to it writes to disk (path or folder), otherwise it returns the XML. It offers no guidance on when to prefer this over siblings like get_document_pdf, send_einvoice, or verify_einvoice, so context selection is only implied.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds only 'complete detail' and says nothing about not-found behavior, permissions, or what data is included beyond the record itself.

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?

It is a single front-loaded sentence with no wasted wording. Its brevity is appropriate structurally, though it leaves important details unstated.

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 a simple read-only retrieval tool, the description still lacks the required identifier semantics and any indication of when to use this versus list_f24. It is under-specified for the two-parameter schema and gives no return-shape context, though no output schema exists.

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 50%: company_id is documented in the schema, but the required id parameter has no description. The tool description mentions neither parameter, so it does not compensate for the missing id semantics.

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 identifies the resource (F24) and indicates a single-record detail retrieval, which distinguishes it from list_f24. The verb is implicit rather than stated, but the purpose is still clear.

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 gives no explicit guidance on when to use get_f24 instead of list_f24 or other F24 siblings. At best, 'dettaglio completo' implies looking up details after identifying a record, but this is not stated.

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

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

The readOnlyHint=true annotation already tells the agent this is a non-mutating read, so the description is not obliged to restate safety. Beyond that it discloses nothing behavioral: not what the "complete detail" includes (line items, totals, attachments, e-invoice status), not what happens on a missing or foreign id, and not the company-scoping fallback behavior implied by company_id.

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?

A single front-loaded sentence with no filler; the parenthetical type list earns its place by defining scope. It stops at adequate rather than exemplary because the enumeration consumes most of the sentence while the actionable guidance stays absent.

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 tool is simple (2 params, no nested objects, no output schema), and the annotation covers the safety profile, so the description needs only to identify the resource and its record types, which it does. The remaining gap is that an agent cannot tell what fields the "dettaglio completo" response will contain before calling.

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 50%: company_id is documented in the schema with its default resolution rule, while id has no schema description at all. The description only indirectly clarifies that id refers to an issued document, without saying whether it is an internal numeric id rather than the visible document number, so it partially compensates but leaves a real ambiguity.

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?

"Dettaglio completo di un documento emesso" supplies a clear verb (retrieve full detail) and a well-scoped resource, and the parenthetical enumerates the document types it covers (fattura, nota di credito, proforma, preventivo, ordine, DDT). The "emesso" qualifier implicitly separates it from get_received_document and get_archive_document, but no sibling is named explicitly.

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?

Usage is only implied: the agent can infer this is the single-record fetch for issued documents, presumably after list_issued_documents. There is no explicit when-to-use statement, no mention of what to do when the id is unknown, and no exclusion of alternatives such as get_document_pdf or get_einvoice_xml.

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

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

readOnlyHint=true is consistent with a 'get' tool, so no contradiction. The description adds value by disclosing that the payload covers upcoming section numbers, defaults, VAT rates and templates — non-obvious return content for a no-output-schema tool — but says nothing about scope (per company? per document type?) or fallback behavior.

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?

One short sentence with the returned data front-loaded and the usage hint trailing, with no filler. It is dense but readable, though the compressed noun list ('sezionale, valori predefiniti, aliquote e modelli') is slightly opaque without domain familiarity.

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 a 2-param read-only tool with no output schema, an agent needs to know what comes back and how to use it; the description lists the payload categories and the pre-creation use case, which is adequate. It is still missing the link between the 'type' parameter and the returned defaults, which is the one thing that would make the call unambiguous.

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 50%, and the undocumented half is the important one: the 11-value 'type' enum has no description in the schema and the description never explains that the returned defaults vary by document type. 'Sezionale' and 'modelli' hint at document-type-dependent content but give no mapping, so the agent must guess how 'type' changes the result.

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 names the resource loosely (next free numbers, defaults, rates, templates) but the verb is only implied by the tool name, not by the sentence itself. It is distinguishable from create_issued_document via the 'utile prima di creare un documento' clause, but the phrasing is a list of returned data rather than a crisp statement of what the tool does.

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?

'Utile prima di creare un documento' gives a clear triggering context, so an agent knows to call it in the pre-creation step. However, no alternative is named (e.g. whether a plain get_company_info or list_vat_types call would serve instead), and there are no exclusions or notes about whether the call is required.

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