Skip to main content
Glama
Fatture in Cloud MCP Server

Fatture in Cloud MCP Server

update_vat_type

Idempotent

Modify a VAT rate or exemption nature by sending only the fields to change; for non-VAT operations, include ei_type and a description or legal reference.

Instructions

Modifica un aliquota IVA o natura di esenzione: passa solo i campi da cambiare. Per operazioni senza IVA serve ei_type (natura, es. N2.2) e una descrizione/riferimento normativo.

Input Schema

NameRequiredDescriptionDefault
idYes
dataYes
company_idNoAzienda su cui operare. Default: FIC_COMPANY_ID o l'unica azienda del token

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A3.9/5.0
Behavior3/5

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

Only idempotentHint is supplied by annotations; the description adds the important behavioral fact that this is a partial merge update ('passa solo i campi da cambiare'). It says nothing about permissions, what happens to documents already using the rate, validation failures on an unknown nature code, or return shape, which matters for a tax-configuration mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two front-loaded sentences with no filler: the mutation and partial-update rule come first, the exemption-case requirement comes second. Every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the two branches an agent must distinguish (ordinary rate change vs exempt nature) for a tool with a nested free-form payload and no output schema. Missing pieces are the meaning of `id` and the effect on existing documents, which are secondary but non-trivial for a config mutation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33% and `data` is a free-form object with additionalProperties, so the description carries real weight by naming the fields to pass and the ei_type nature convention plus legal reference. It still leaves `id` unexplained (implicitly the VAT type id) and does not enumerate allowed nature codes.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Modifica un aliquota IVA o natura di esenzione', which is clearly distinct from create_vat_type/delete_vat_type implied by the verb, and adds partial-update scope. It never names a sibling explicitly, so the differentiation is inferred 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operative guidance: pass only the fields to change, and for VAT-exempt operations supply ei_type (e.g. N2.2) plus a description/legal reference. It does not state when to use this instead of create_vat_type or delete_vat_type, so alternatives are left implicit.

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

Deploy Server

Other Tools