Skip to main content
Glama

explain_tax_brackets

Find your Swiss tax bracket and marginal rate: enter location and taxable income to see bracket, rate, and next threshold.

Instructions

Show the statutory rate ladder and where an income sits in it.

Explains the number rather than just producing it: which bracket the household is in, the marginal rate there, and how far the next threshold is. The cantonal figure is the simple tax (einfache Staatssteuer), which the canton and municipality then multiply by their own rates.

The tax amount always comes from ESTV itself. The ladder is rebuilt from the published scale, which a few cantons express as a formula rather than a table; there the amount is still exact and ladder is simply absent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoWhich scale to explain.cantonal
languageNode
locationYesTax location id, postal code or municipality name.
tax_yearNo
has_childrenNoWhether the household has dependent children, which selects the married/family scale in most cantons.
relationshipNosingle
taxable_incomeYesTaxable income to locate in the scale, CHF.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

With no annotations, the description carries full burden. It discloses the data source (ESTV), how the ladder is built (from published scale, absent for formula cantons), and the nature of the cantonal figure. It does not address performance, auth, or errors, but covers key behavioral traits for this tool.

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 concise (several sentences) with the core purpose front-loaded. Every sentence adds value, covering purpose, behavior details, and edge cases without excess. It is well-structured for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's 7 parameters (2 required) and existence of an output schema (so return values need not be explained), the description covers purpose, data source, and edge cases. It lacks some context on parameter semantics and when to use vs siblings, but is largely complete for this use case.

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 57% (4 params described). The tool description does not elaborate on parameter usage beyond the purpose; it adds no clarification for the 3 undescribed params (language, tax_year, relationship). While it explains output concepts, it doesn't compensate for missing schema descriptions.

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 shows the statutory rate ladder and explains an income's position, including bracket, marginal rate, and distance to next threshold. It distinguishes from merely calculating tax by emphasizing explanation, and notes the data source and edge cases for formula-based cantons.

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 implicitly guides use for explanatory purposes ('explains the number rather than just producing it'), and the sibling list includes calculate_tax, suggesting when to use this alternative. However, it lacks explicit when-not-to-use or direct alternative names.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/noaahh/estv-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server