Ricerca fatture

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

Annotations declare readOnlyHint=true, so safety profile is covered. The description adds valuable context about the Premium account/delegation requirement and the 401 error for base accounts, plus the 10-day maximum date window. This goes beyond the annotations to reveal real operational constraints.

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?

Description is a single reasonably concise sentence followed by a brief NOTE about the Premium requirement. It's front-loaded with the core purpose. Slightly verbose with the enumerated filter list but acceptable. The note is important and 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 search/list tool with no output schema, it provides good context: filter capabilities, pagination, account requirements, and the 10-day window constraint. Given the tool operates on paginated results and has 14 params, the description covers the essential operational constraints well. Could mention result ordering or default behavior but is largely 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 100%, so all 14 parameters are documented in the schema itself. The description adds some context about senderCountry/senderVatcode being mandatory for Premium accounts (which the individual parameter descriptions also mention). The description doesn't add much beyond what the schema already conveys, so 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 clearly states the tool searches Italian electronic invoices (sent/received) on Aruba Fatturazione Elettronica with filters for period, status, document type, and counterparty. It clearly distinguishes from siblings (search vs get/detail/download/send/notifications). However, it doesn't explicitly name sibling alternatives for search functions, so slightly below 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?

Provides clear context about pagination and the Premium account requirement/delegation note (401 without delegations on base accounts). It states what it searches but doesn't explicitly say when to use it vs. siblings like get_invoice_detail. The 10-day window constraint on creationEndDate is helpful usage guidance.

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