TaxCompass — Italian tax tools

calculate_italian_tax

Read-onlyIdempotent

Compute exact Italian tax for one regime at a given annual revenue.

Deterministic calculation (not an estimate): substitute/income tax, INPS
social contributions, net income, and effective rate. `breakdown.eligible`
is False when the regime doesn't apply to the inputs (e.g. forfettario above
the €85k cap) — present that as "not eligible", not as a real option.

Args:
    revenue_eur: Gross annual revenue in EUR.
    regime: One of `forfettario_5`, `forfettario_15`, `ordinario`,
        `ordinario_impatriati`.
    coefficient: Forfettario coefficiente di redditività (0.40–0.86, set by
        the activity's ATECO group). Omit for the professional-services
        default (0.78). Ignored by non-forfettario regimes.
    cost_ratio: Deductible costs as a fraction of revenue (0–1), used by
        ordinario/impatriati. Ignored by forfettario.

Input Schema

TableJSON Schema

Name	Required	Default
`regime`	No	forfettario_15
`cost_ratio`	No
`coefficient`	No
`revenue_eur`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`breakdown`	Yes	Full numeric breakdown (taxes, contributions, net, effective rate).
`disclaimer`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 19, 2026
- addedOutput schema / $defs / Breakdown / properties / contributions_are_stand_in
```
Added value: +{
+  "default": false,
+  "title": "Contributions Are Stand In",
+  "type": "boolean"
+}
```
Changed3 schema fields changedSep 2, 2026
- addedOutput schema / $defs / Breakdown / properties / effective_rate / anyOf
```
Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
```
- changedOutput schema / $defs / Breakdown / properties / effective_rate / default
```
Previous value: -0New value: +null
```
- removedOutput schema / $defs / Breakdown / properties / effective_rate / type
```
Removed value: -"number"
```
First observedJun 7, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already mark the tool as read-only and idempotent; the description adds valuable deterministic behavior, exactness, and the meaningful distinction between 'not eligible' and a real calculated option. It also explains which parameters are ignored per regime, giving the agent behavioral expectations beyond the schema.

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 front-loaded with the core purpose and then moves into behavioral notes and parameter details. The structure is logical and every sentence adds information; the Args block is dense but directly needed because the schema provides no descriptions.

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 the output schema exists and the annotations cover safety, the description fills the remaining gaps: eligibility behavior, parameter constraints, defaults, and regime-specific applicability. An agent has everything needed to select and call this tool correctly without additional inference.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries full responsibility for parameter meaning, and it succeeds. It explains revenue_eur as gross annual revenue, defines each regime value, documents coefficient ranges (0.40–0.86) and the default (0.78), and clarifies cost_ratio semantics plus which regimes ignore it.

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 ('Compute'), a clear resource ('exact Italian tax for one regime'), and the key inputs ('annual revenue'). It explicitly narrows the tool's scope to a single regime, which clearly distinguishes it from sibling tools like compare_italian_regimes and list_tax_sources.

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 clearly frames this as a single-regime deterministic calculator, implying that cross-regime comparison belongs to the sibling compare_italian_regimes. It also instructs how to handle ineligible regimes ('present that as not eligible'), which guides correct output interpretation. It does not explicitly name the sibling alternative, but the context is strong.

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

All TaxCompass — Italian tax tools tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?