mcp-fattura-elettronica-it

Validate Cii Invoice

validate_cii_invoice

Validate CII CrossIndustryInvoice XML for structural correctness by parsing it into an EN16931Invoice and checking required core fields. Returns valid status with warnings or errors.

Instructions

Validate a CII CrossIndustryInvoice XML string for structural correctness.

Performs structural validation by parsing the XML into an EN16931Invoice and checking that required core fields are present and non-empty.

Note: this tool does NOT validate against the normative CII D16B XSD schema. For full schema validation use a dedicated CII or ZUGFeRD validator.

On success returns {'valid': true, 'warnings': list[str]}. On failure returns {'valid': false, 'errors': list[str]}. On parse error returns {'valid': false, 'errors': ['XML parse error: ...']}.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`xml_string`	Yes	CII CrossIndustryInvoice XML string to validate. Must contain a root rsm:CrossIndustryInvoice element.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.5Jun 7, 2026

TDQS

A4.2/5.0

Behavior4/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 does it well. It explains how validation happens (parse into EN16931Invoice, check required fields), what it does not do (XSD validation), and enumerates the three possible return shapes including the parse-error case. It lacks explicit statements about side effects, but the pure-validate operation makes them unlikely.

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?

The description is well-structured and front-loaded, clearly separating purpose, limitations, and return values. The return-format explanation is somewhat redundant given that an output schema exists, but it does not clutter the description enough to lose more than one point.

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?

This is a single-parameter validation tool with an output schema, and the description covers the operation, its limitations, and all return cases. Even without annotations, an agent can invoke it correctly without needing additional information.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already documents the parameter thoroughly. The description adds context about the structural parsing behavior, but it does not meaningfully expand the parameter's semantic beyond the schema.

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 states a specific verb and resource: validate a CII CrossIndustryInvoice XML string. It further clarifies the validation scope (structural correctness, required core fields), which clearly distinguishes it from schema-level validation tools like validate_fattura_xsd or validate_ubl_invoice.

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?

The description explicitly states what the tool is not for (normative CII D16B XSD validation) and recommends a dedicated CII/ZUGFeRD validator for that, giving clear when-not guidance. It does not explicitly name sibling tools as alternatives, but the distinction is clear enough to allow an agent to choose correctly.

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

Deploy Server