F
licenseA
qualityD
maintenanceEnables AI assistants to help compile the Italian Modello 730 income tax return by providing IRPEF calculations, deduction tools, and tax rule guidance.
12
22
TaxCompass — Italian tax tools
Server Details
Sourced Italian tax tools for AI agents: cited primary-source search + a deterministic tax engine.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.5/5.0
Tool DescriptionsA
Average 4.6/5 across 4 of 4 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a distinct purpose: single calculation, comparison, source listing, and search. No overlap in functionality.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with clear, descriptive names (calculate_italian_tax, compare_italian_regimes, list_tax_sources, search_italian_tax_sources).
Tool Count4/5
4 tools is slightly lean but covers core needs (calculation, comparison, information retrieval). A few more specialized tools could be added, but the count is reasonable.
Completeness4/5
The tool set covers tax calculation, comparison, and legal source retrieval. Minor gaps exist (e.g., no tool for historical data or customized deductions beyond cost_ratio), but the search tool can supplement.
Available Tools
4 toolscalculate_italian_taxARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| regime | No | forfettario_15 | |
| cost_ratio | No | ||
| coefficient | No | ||
| revenue_eur | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| breakdown | Yes | Full numeric breakdown (taxes, contributions, net, effective rate). |
| disclaimer | Yes |
Tool Definition Quality
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds valuable context: it is 'deterministic calculation (not an estimate)', and explains that breakdown.eligible is False when regime does not apply. This goes beyond the annotations without contradicting them.
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 well-structured: a one-line purpose, then a clarifying sentence about determinism and the eligible flag, then a detailed Arg list. Every sentence adds value, with no repetition or fluff.
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 4 parameters (1 required) and the existence of an output schema (not shown), the description covers all necessary aspects: parameter semantics, edge cases (eligible flag), and behavioral traits. No gaps are apparent.
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 coverage is 0%, but the description's Args section fully explains all four parameters: revenue_eur, regime (lists allowed values), coefficient (range 0.40-0.86, default 0.78 for professional-services, ignored by ordinario), and cost_ratio (0-1, used by ordinario/impatriati). This adds crucial meaning absent from 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 clearly states 'Compute exact Italian tax for one regime at a given annual revenue.', which specifies the verb (compute) and resource (Italian tax for one regime). This distinguishes it from sibling tools like compare_italian_regimes (which compares multiple regimes) and list/search tools (which deal with 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 provides clear context by noting the deterministic nature and explaining when breakdown.eligible is False. It does not explicitly contrast with sibling tools or state when not to use it, but the parameter guidance (e.g., coefficient only for forfettario) implies appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_italian_regimesARead-onlyIdempotentInspect
Compare all Italian regimes side by side at one revenue level.
Runs forfettario (5% & 15%), ordinario, and ordinario + impatriati through
the deterministic engine and returns them sorted by net income (best first),
each with its full breakdown and eligibility.
Args:
revenue_eur: Gross annual revenue in EUR.
coefficient: Forfettario coefficiente di redditività (0.40–0.86); omit
for the professional-services default (0.78).
cost_ratio: Deductible costs as a fraction of revenue (0–1) for the
ordinario regimes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cost_ratio | No | ||
| coefficient | No | ||
| revenue_eur | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | One breakdown per regime, best net income first. |
| disclaimer | Yes | |
| revenue_eur | Yes | Gross annual revenue (EUR) the regimes were evaluated at. |
Tool Definition Quality
A4.8/5.0
Behavior5/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 significant behavioral details: it runs through a 'deterministic engine', sorts results by net income (best first), and returns full breakdown and eligibility for each regime. No contradictions with annotations.
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?
Description is highly concise with no redundant words. It is well-structured: a one-line purpose statement, a brief behavior summary, and a clear list of argument descriptions. Every sentence earns its place.
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 tool has 3 parameters and an output schema, the description adequately explains the deterministic comparison, output sorting and contents (breakdown, eligibility). The presence of an output schema reduces the need to detail return values. For a comparison tool, this is complete.
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 coverage is 0%, but the description provides thorough explanations for all three parameters: revenue_eur (gross annual revenue), coefficient (forfettario coefficient, range 0.40–0.86, default 0.78), and cost_ratio (deductible costs fraction 0–1 for ordinario). This adds critical context beyond the schema's defaults and types.
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 explicitly states the tool compares all Italian regimes side by side at one revenue level, naming the specific regimes (forfettario 5% & 15%, ordinario, ordinario + impatriati) and indicating output is sorted by net income. This clearly distinguishes it from siblings like 'calculate_italian_tax' (single regime) 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 indicates the tool is for comparing multiple regimes at a given revenue level. It implies this is the right choice when a side-by-side comparison is needed, but does not explicitly state when to use alternatives like 'calculate_italian_tax' for a single regime or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tax_sourcesARead-onlyInspect
List the primary sources the corpus can search, and what each covers.
Use this to discover the valid `sources` filter values for
`search_italian_tax_sources` and to understand the corpus's coverage.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| sources | Yes | |
| disclaimer | Yes |
Tool Definition Quality
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds that it returns list of sources and their coverage, and that it helps discover valid filter values for a sibling tool, providing full behavioral context.
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?
Two sentences, no waste. First sentence states purpose, second explains usage. Front-loaded and efficient.
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 0-parameter tool with output schema and helpful annotations, description fully covers purpose and context, including relationship to sibling tool.
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?
Input schema has 0 parameters, so baseline is 4. Description adds nothing about parameters as there are none.
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 it lists primary sources and what each covers, and explains its use for discovering valid filter values for search_italian_tax_sources. This distinguishes it from siblings (calculate, compare, search).
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?
Explicitly guides to use for discovering valid sources filter values and understanding corpus coverage. Does not specify when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_italian_tax_sourcesARead-onlyInspect
Search TaxCompass's primary-source corpus and return passages to cite.
Hybrid semantic + keyword retrieval over Italian tax & company-law primary
sources: Normattiva (statute), Agenzia delle Entrate (circolari & guidance),
INPS (social security), pinned tax-year tables (IRPEF brackets, INPS rates,
forfettario thresholds & coefficienti di redditività), the ATECO 2025 code
catalogue, and EU/treaty sources.
Each result carries a `chunk_id`, `source`, and (usually) a `url`. Cite the
`url` and quote the `text`; do not assert Italian tax facts the passages
don't support. Queries work in any language, but Italian keywords improve
recall against the (Italian) legal corpus.
Args:
query: What to search for. Keyword-dense Italian phrasing works best.
sources: Optional subset to restrict to (see `list_tax_sources` for keys).
Omit to search everything. Unknown keys are ignored.
k: Max passages to return (1–12).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| query | Yes | ||
| sources | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of passages returned. |
| query | Yes | The query that was run. |
| passages | Yes | Retrieved passages, most relevant first. |
| disclaimer | Yes | Usage + citation guidance. |
| sources_searched | Yes | Source keys actually searched (after filtering). |
Tool Definition Quality
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. The description adds that it uses hybrid semantic+keyword retrieval, returns chunk_id, source, url, and text, and warns against asserting unsupported facts. No contradiction with annotations.
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?
Well-structured with a clear opening summary, followed by details on sources, output, and parameters. Front-loaded with purpose. While thorough, it is concise for the amount of information provided.
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 tool's complexity, 0% schema coverage, and presence of output schema, the description is highly complete. It covers retrieval method, output fields, parameters, and citation instructions. No gaps identified.
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%, but the description fully explains each parameter: query (keyword-dense Italian phrasing), sources (optional, refer to list_tax_sources), and k (max passages 1-12). Adds meaningful guidance beyond the schema's default values and types.
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 clearly states the tool searches TaxCompass's primary-source corpus and returns passages for citation. It lists specific sources (Normattiva, Agenzia delle Entrate, INPS, etc.) and distinguishes from siblings like calculate_italian_tax and compare_italian_regimes by focusing on retrieval and citation.
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?
Provides guidance on query language (Italian keywords improve recall), when to use (to find citations), and how to use parameters. It also instructs the agent not to assert unsupported facts. Lacks explicit when-not-to-use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
OpenAccountantsofficial
AlicenseAqualityAmaintenanceOpen-source, accountant-verified tax computation skills for AI agents. 261+ skills across 172+ jurisdictions covering income tax, VAT/GST, payroll, corporate tax, crypto, and cross-border planning. Every skill is verified section-by-section by licensed CPAs and chartered accountants. 3 tools (list_skills, get_skill, get_skill_sections) and 1 prompt (skill-review).3323AGPL 3.0- AlicenseAqualityCmaintenanceStructured business intelligence for AI agents. 5.5M verified entities across 34 countries, 40.3M BORME mercantile acts, EU VAT validation, GLEIF, healthcare registries. 20 tools.61MIT
- AlicenseAqualityCmaintenanceProvides access to official Spanish fiscal data and tools based on AEAT and BOE sources, covering income tax, VAT, and regional deductions. It enables AI assistants to answer tax-related queries and verify filing deadlines using verified information.103113MIT
