Skip to main content
Glama
MaurizioLisanti

fatturapa-mcp-server

generate_invoice_report

Aggregate batches of FatturaPA XML invoices into a structured report with totals, supplier/customer breakdowns, and anomaly summaries, while isolating unparseable documents.

Instructions

Aggregate a batch of FatturaPA XML documents into a structured report.

Processes each invoice through extract_invoice_data and find_invoice_anomalies, then aggregates the results into totals, supplier/customer breakdowns, and an anomaly summary. Documents that cannot be parsed are counted separately in the errors list; they do not affect the monetary totals. Never logs or persists XML content.

Progress notifications: one step per invoice (1..N), then a final step (N+1) for the aggregation phase.

Args: xml_contents: List of raw FatturaPA XML strings to process. title: Optional report title; defaults to "Invoice Report". ctx: Optional MCP context for structured log emission.

Returns: An InvoiceReportResult TypedDict with aggregated statistics, party breakdowns (suppliers/customers), and an anomaly summary.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNo
xml_contentsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYes
errorsYes
currencyYes
customersYes
suppliersYes
total_vatYes
generated_atYes
total_amountYes
total_invoicesYes
valid_invoicesYes
invalid_invoicesYes
anomalies_summaryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations to lean on, the description carries the full burden and delivers: unparseable documents are counted in an errors list and excluded from monetary totals, XML content is never logged or persisted, and progress notifications follow a defined 1..N plus N+1 sequence. These are exactly the behavioral traits an agent needs and cannot get from structured fields.

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?

Front-loaded with the purpose sentence, followed by behavior, then Args/Returns. The structure is scannable and every section earns its place, though the Args/Returns prose partially repeats what the output schema already conveys.

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 a two-parameter batch tool with an output schema, the description supplies error semantics, privacy guarantees, progress-notification behavior, and a parameter rundown. Nothing material an agent needs to invoke it correctly 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 coverage is 0%, so the description must compensate, and it does: xml_contents is described as a list of raw XML strings, title is documented as optional with the 'Invoice Report' default, and ctx is explained as an optional MCP context for logging (not even present in the schema). It could add more on expected XML validity or size limits, but coverage is solid.

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?

States a specific verb (aggregate) and resource (FatturaPA XML documents) and the output (structured report). It distinguishes itself from siblings by explaining it composes extract_invoice_data and find_invoice_anomalies rather than performing those jobs itself.

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 makes clear this is the batch aggregation entry point built on top of the extraction and anomaly siblings, so an agent can infer when to reach for it versus the single-invoice tools. It stops short of explicitly naming when NOT to use it or listing alternatives by name.

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