Skip to main content
Glama
cmendezs

mcp-fattura-elettronica-it

validate_cedente_prestatore

Validate and build the seller (CedentePrestatore) block for FatturaPA invoices. Checks required fields, fiscal regime code, and Italian Partita IVA format.

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.

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.

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
NameRequiredDescriptionDefault
id_paeseYesISO 3166-1 two-letter country code of the seller (e.g. 'IT').
id_codiceYesPartita IVA (11 digits) or foreign VAT number of the seller.
denominazioneNoCompany name (Denominazione). Mutually exclusive with nome+cognome.
nomeNoFirst name (Nome), for individual sellers.
cognomeNoLast name (Cognome), for individual sellers.
regime_fiscaleNoFiscal regime code RF01–RF19. Use get_regime_fiscale_codes() for the complete list. Most companies use RF01 (ordinary regime).RF01
indirizzoNoStreet address (via, piazza…) of the registered office.
capNoItalian postal code (5 digits) or foreign equivalent.
comuneNoCity/municipality of the registered office.
nazioneNoISO 3166-1 two-letter country code of the registered office.IT

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

No annotations provided, so description carries full burden. It details validation rules (mutual exclusivity, regime_fiscale range, Partita IVA digit count) and return value formats (success vs error). No contradictions.

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

Conciseness4/5

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

Description is relatively concise (around 10 lines) and front-loaded with purpose, usage, validations, and returns. Minor room for further tightening but well-structured overall.

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?

Given 10 parameters, full schema descriptions, and presence of output schema (per context signals), the description covers validation rules, integration points, and error handling, making it fully actionable.

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 baseline is 3. Description adds value beyond schema by explaining mutual exclusivity of denominazione vs nome+cognome and specific validation logic for Partita IVA digits, enhancing parameter context.

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?

Description clearly states 'Validate and build the CedentePrestatore (seller) block for FatturaPA' with specific verb (validate and build) and resource (CedentePrestatore block), and distinguishes from siblings like build_transmission_header and validate_cessionario via workflow ordering.

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?

Explicitly indicates step 4 in the workflow, after build_transmission_header() and before validate_cessionario(), and suggests calling get_regime_fiscale_codes() first for RF code lookup. Provides clear when-to-use and alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cmendezs/mcp-fattura-elettronica-it'

If you have feedback or need assistance with the MCP directory API, please join our Discord server