Retrieve the SdI rejection reason for an electronic invoice and get clear correction guidance so you can fix and resubmit it.
Motivo dello scarto SdI di una fattura elettronica, con le indicazioni per correggerla.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| company_id | No | Azienda su cui operare. Default: FIC_COMPANY_ID o l'unica azienda del token |
Changes observed during successful MCP inspections.
v0.5.1Does 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.