Delete a payment method, such as a bank transfer with IBAN, from an invoice record. Use it to remove obsolete or incorrect payment details tied to a company's invoicing data.
Elimina un metodo di pagamento mostrato in fattura (es. bonifico con IBAN).
| 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 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.