mcp-fattura-elettronica-it

Build Sport Worker Exemption Dato Gestionale

build_sport_worker_exemption_dato_gestionale

Creates an AltriDatiGestionali entry for the sport-worker IRPEF exemption (ESENZSPORT) for compensation exempt up to EUR 15,000/year under art. 36, D.Lgs. 36/2021.

Instructions

Build the AltriDatiGestionali entry for the sport-worker IRPEF exemption codifica.

Covers compensation under art. 36, comma 6, D.Lgs. 36/2021 (lavoro sportivo dilettantistico), exempt from the taxable base up to EUR 15,000/year. Sets TipoDato to 'ESENZSPORT' — verified against AdE Allegato A – Specifiche Tecniche 1.9.1 (in force 2026-05-15). RiferimentoTesto/RiferimentoNumero are not mandated for this codifica (unlike e.g. 'ALI-COMP', which requires RiferimentoNumero); both are left to the caller's discretion here.

Pass the returned dict's 'AltriDatiGestionali' value inside a list to add_linea_dettaglio()'s altri_dati_gestionali parameter — or pass the dict itself if you are constructing the list manually.

On success returns {'AltriDatiGestionali': {'TipoDato': 'ESENZSPORT', ...}}. On failure (invalid riferimento_data) returns {'error': ''}.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`riferimento_data`	No	Optional reference date (YYYY-MM-DD) for RiferimentoData.
`riferimento_numero`	No	Optional cumulative annual compensation amount (EUR) to record in RiferimentoNumero. Not mandated by the spec for this codifica — a convenience for callers who want to track it on the invoice.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.7.0Aug 21, 2026

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it does substantial work: it discloses the success return shape, the failure shape for invalid riferimento_data, that the value is verified against Specifiche Tecniche 1.9.1 effective 2026-05-15, and that certain fields are deliberately not mandated. It doesn't discuss side effects, idempotence, or permission requirements; acceptable for a pure builder with no side effects, it meets expectations.

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 ~150 words across three tightly organized paragraphs, and every sentence earns its place: the triggering legal condition, the exact TipoDato value with its specification reference, the non-mandated fields, integration instructions, and return contract. No filler or repetition of the tool name.

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 2-parameter, 0-required builder with a matching output schema, the description covers everything an agent needs to invoke and consume it correctly. It describes success/failure formats, the target parameter of a sibling tool, and the legal/regulatory trigger for correct selection.

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%, giving a baseline of 3. The description reinforces that RiferimentoNumero is not mandated and a caller convenience, but the schema text already contains that. The ALI-COMP contrast adds some interpretive value but doesn't materially deepen the meaning of the two parameters beyond what the schema already provides.

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 names a specific verb-resource pair ('Build the AltriDatiGestionali entry for the sport-worker IRPEF exemption codifica') and pins down the exact output value (ESENZSPORT) and legal basis (art. 36 comma 2, D.Lgs. 36/2021). It distinguishes itself from related codifiche by contrasting with 'ALI-COMP', which requires RiferimentoNumero.

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?

It provides clear context: compensation exempt up to EUR 15,000/year under the cited article, and explains the ALI-COMP contrast to help the caller decide whether RiferimentoNumero matters. It also gives concrete integration instructions on how to consume the result (via add_linea_dettaglio() or a manual list). It doesn't explicitly say 'use this instead of tool X', so it falls just short of the explicit when-not-to-use tier.

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

Deploy Server