mcp-fattura-elettronica-it

Validate Cedente Prestatore

validate_cedente_prestatore

Validate and construct the seller (CedentePrestatore) block for FatturaPA invoices, checking required fields, fiscal codes, and VAT data before XML generation.

Instructions

Validate and build the CedentePrestatore (seller) block for FatturaPA.

Use this as step 4 in the invoice generation workflow, after build_transmission_header() and before validate_cessionario(). Call get_regime_fiscale_codes() first if you need to look up the RF code.

Gruppo IVA (VAT-group) sellers: when id_codice is a VAT-group IdFiscaleIVA, pass codice_fiscale set to the Codice Fiscale of the specific participating member company issuing this invoice, never the group's own CF. This mirrors the buyer-side rule enforced by SdI scarto code 00327 (see mcp_fattura_elettronica_it.sdi.notifications.SCARTO_CODE_REFERENCE); SdI does not publish an equivalent seller-side control code, but the same distinction applies structurally.

Validates: either denominazione or both nome+cognome must be provided (mutually exclusive); regime_fiscale must be a valid RF01–RF19 code; Italian Partita IVA (id_paese='IT') must be exactly 11 digits; codice_fiscale, if provided, must be 16 alphanumeric characters (individuals) or 11 digits (companies/VAT groups).

On success returns {'CedentePrestatore': {...}} ready to pass to generate_fattura_xml(). On failure returns {'error': ''} listing all validation issues joined by '; '.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`cap`	No	Italian postal code (5 digits) or foreign equivalent.
`nome`	No	First name (Nome), for individual sellers.
`comune`	No	City/municipality of the registered office.
`cognome`	No	Last name (Cognome), for individual sellers.
`nazione`	No	ISO 3166-1 two-letter country code of the registered office.	IT
`id_paese`	Yes	ISO 3166-1 two-letter country code of the seller (e.g. 'IT').
`id_codice`	Yes	Partita IVA (11 digits) or foreign VAT number of the seller.
`indirizzo`	No	Street address (via, piazza…) of the registered office.
`denominazione`	No	Company name (Denominazione). Mutually exclusive with nome+cognome.
`codice_fiscale`	No	Codice Fiscale of the seller, optional. Set this when id_codice is a VAT-group (Gruppo IVA) IdFiscaleIVA: value must be the Codice Fiscale of the specific participating member company, never the group's own CF. Emitted as DatiAnagrafici/CodiceFiscale, between IdFiscaleIVA and Anagrafica per the XSD element order.
`regime_fiscale`	No	Fiscal regime code RF01–RF19. Use get_regime_fiscale_codes() for the complete list. Most companies use RF01 (ordinary regime).	RF01

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.7.0Aug 21, 2026

addedInput schema / properties / codice_fiscale

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Codice Fiscale of the seller, optional. Set this when id_codice is a VAT-group (Gruppo IVA) IdFiscaleIVA: value must be the Codice Fiscale of the specific participating member company, never the group's own CF. Emitted as DatiAnagrafici/CodiceFiscale, between IdFiscaleIVA and Anagrafica per the XSD element order."
+}

First observedv0.2.0Apr 28, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden, and it does so thoroughly. It discloses validation rules, the Gruppo IVA special handling rule, the exact success/error return contract, and relevant SdI domain context. This goes well beyond what the schema or annotations would imply on their own.

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?

The description is long but densely informative and well structured. It front-loads the purpose, then adds workflow placement, the critical Gruppo IVA exception, validation rules, and the return contract in logical order. Every paragraph earns its place given the domain complexity.

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

Completeness5/5

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

For an 11-parameter validation/build tool with no annotations, the description is complete: it explains the workflow position, the special VAT-group behavior, all key validation invariants, and the return shape. The schema already documents individual parameters, and the output schema covers the return structure, so nothing essential is missing.

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 description coverage is 100%, so the baseline is 3. The description adds semantics beyond the schema by specifying validation constraints: Italian Partita IVA must be exactly 11 digits, codice_fiscale must be 16 alphanumeric characters or 11 digits, and denominazione is mutually exclusive with nome+cognome. This is valuable extra meaning beyond the individual property descriptions.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Validate and build the CedentePrestatore (seller) block for FatturaPA.' This clearly distinguishes it from sibling validate_cessionario, which is explicitly the buyer-side counterpart, and grounds it in the invoice generation workflow as step 4.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

It gives explicit workflow placement: 'Use this as step 4 in the invoice generation workflow, after build_transmission_header() and before validate_cessionario().' It also names get_regime_fiscale_codes() as the sibling to call for RF code lookup, giving the agent actionable routing between related tools.

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

Deploy Server