Validates the XML of an electronic invoice, checking required fields and formats without sending it, so you can catch errors before submission to SdI.
Verifica formale dell'XML della fattura elettronica: campi obbligatori e formati. Non invia nulla.
| 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?
The readOnlyHint annotation already declares this a safe read, and the description corroborates it with 'Non invia nulla', adding reassurance that no transmission side effect occurs. However, for a verification tool the crucial behavioral fact is what a failed verification produces (error list? boolean? exception?), and neither an output schema nor the description supplies that.
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 what is verified listed first and the no-side-effect guarantee front-loaded as a second clause. No filler and nothing that repeats the tool name.
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 is the only place the return value could be described, and it says nothing about what the verification yields or how failures are reported. Combined with the undocumented 'id' parameter, the definition leaves an agent guessing at both inputs and results for what should be a simple tool.
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 carries a default-resolution note in the schema, but 'id' is a bare integer with no description anywhere. The description never clarifies whether 'id' is the issued-document id, the received-document id, or the invoice XML identifier, which is exactly the ambiguity an agent would stumble on here.
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 ('Verifica formale dell'XML della fattura elettronica') and narrows the scope to 'campi obbligatori e formati'. The closing clause 'Non invia nulla' draws the boundary against the send-oriented siblings (send_einvoice, bulk_send_einvoice), so an agent can separate the two without opening a 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?
The phrase 'Non invia nulla' implicitly tells the agent this is a validation step to run before any send operation, and it explicitly excludes the sending use case. What's missing is a direct pointer to the alternatives, e.g., whether to use einvoice_rejection_reason instead when the invoice has already been rejected, or get_einvoice_xml to inspect the payload.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.