estv-tax

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct aspect of Swiss tax calculation: location lookup, deduction listing, income tax from gross vs taxable amounts, municipal comparisons, capital payment tax, withdrawal planning, inheritance, company tax, and rate explanation. Even similar tools like compare_locations and find_cheapest_nearby are differentiated by radius constraints and scope. The descriptions clearly separate every tool's role, leaving no ambiguity.
Naming Consistency4/5
Most tools follow a verb_noun pattern (find_location, list_deductions, calculate_tax, compare_locations), but there are minor deviations: 'deduction_value' is a noun phrase instead of a verb, and 'calculate_tax_from_taxable_amounts' uses a longer prepositional phrase. The pattern is still predictable and readable, with only a couple of outliers.
Tool Count5/5
With 13 tools, the set is well-scoped for a Swiss tax calculator. It covers individual income tax, capital withdrawals, inheritance, company tax, location comparisons, and deduction analysis without unnecessary overlap. Each tool addresses a specific use case an agent would reasonably request, and the count is within the ideal 3-15 range.
Completeness5/5
The tool surface covers the full tax calculation lifecycle: locating a tax jurisdiction, understanding deductible lines, computing tax from gross income or taxable amounts, comparing municipalities, planning capital withdrawals, and computing special taxes (inheritance, company). Also included are tools for explaining brackets and valuing deductions, making the set comprehensive for the stated domain.
Average 4/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It does disclose that the tool ranks municipalities by tax burden and that the search is radius-based. However, it does not explain that the ranking depends on the supplied household profile (income, relationship, children, confession), which is material for correct use.
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 short, front-loaded with the core action, and adds only a helpful real-world framing in the second paragraph. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 17-parameter tool with no annotations and only 41% schema coverage, this description is too sparse. It does not mention the required income1 input or that tax burden is computed for a household profile, so an agent could invoke it with just coordinates and radius and get an incomplete or misleading result.
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 coverage is only 41%, so the description should compensate. It adds useful meaning to latitude/longitude/radius by framing them as the office/station and commuting distance. But it omits the required income1 parameter and gives no guidance on the many household-profile parameters that affect the ranking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific action and resource: 'Rank municipalities within a radius of a point by tax burden.' This clearly sets it apart from the tax-calculation siblings, though it does not explicitly name an alternative tool.
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 gives a concrete use scenario: finding the cheapest place to live within commuting distance of a location. It instructs the agent to pass coordinates and a radius, but it does not state when not to use the tool or reference alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that capital withdrawals are taxed separately at a reduced rate and that the tool can either compute a single figure or rank places. Yet it doesn't specify return format, error handling, or side effects (likely none), leaving some behavioral aspects opaque.
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 short paragraphs with no filler. The description front-loads the purpose and then adds a key parameter behavior, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters and a low schema coverage, the description is insufficient. It doesn't explain the meaning of many inputs, nor what the output looks like (despite an output schema), nor constraints beyond schema min/max. The complexity warrants more detail than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 36%, and the description only clarifies the `location` parameter by listing valid inputs and the ranking mode. Other parameters like `gender`, `tax_year`, `confession1`, `relationship`, etc., remain undocumented in both schema and description, leaving the agent to guess their semantics.
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 defines the tool as 'Tax on a lump-sum payout from pillar 2 or pillar 3a', which is specific and distinct from general tax tools. It also explains the separate reduced-rate taxation and the ranking mode, making the purpose immediately unambiguous.
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 indicates when to use it: for capital withdrawal taxes, and how to trigger ranking via 'capitals' or 'switzerland'. However, it does not explicitly mention alternatives like calculate_tax for regular income, so the guidance is contextual but not fully exclusive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals that only the extremes plus summary statistics are returned for full-Switzerland scans, which is genuine added value. However, it doesn't disclose behavior for narrow scopes, authentication needs, or how the summary statistics are composed, leaving gaps for a tool with zero annotation cover.
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?
Three sentences, front-loaded with the core purpose, followed by the behavioral caveat and the narrowing advice. Efficient and orderly, though the second sentence is somewhat dense. No redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, covering return values, and the core purpose plus narrowing workflow is clear. But with 16 parameters and only 38% schema coverage, the description does not explain how the household is assembled (which fields belong to person 1 vs person 2, what children_ages or relationship drive), leaving meaningful ambiguity for a complex input set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38% across 16 parameters, so the description should compensate — but it only references `scope` and `only_cantons`. The household parameters (income1/2, age1/2, confession1/2, children_ages, relationship) and income_type fields are left entirely unexplained, so an agent cannot correctly structure a household input from this definition.
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 states a specific verb (rank), resource (municipalities), and basis (total tax burden for one and the same household), and explicitly frames the question it answers ('where would I pay the least?'). It is clearly distinct from siblings like calculate_tax and find_cheapest_nearby, so an agent can select it without ambiguity.
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 explicit guidance on the default full-Switzerland scan (~2100 municipalities) and instructs narrowing with `scope` or `only_cantons` to target a specific region or canton. It communicates when the result set is restricted, though it does not name a specific alternative tool to prefer in other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It explains the purpose and rationale but does not disclose behavior such as fuzzy matching, multiple possible results, no-match behavior, language sensitivity, or how tax_year affects the resolution. The agent is left to infer these from the schema and output 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 two sentences with no filler. It front-loads the core action and result, then adds a concise justification for why this lookup matters. Every sentence earns its place.
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 four parameters and the presence of an output schema, the description provides enough context to understand what the tool returns and why it is needed. It is slightly incomplete only because it lacks explicit usage boundaries relative to sibling location-related tools, but overall it is adequate for a straightforward lookup tool.
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 coverage is 75%, so most parameters are already documented in the schema. The description adds useful domain context about why query resolves to a tax_location_id, but it does not add meaning for limit, language, or tax_year beyond what the schema already provides. This matches the baseline for schema-supported parameters.
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 uses the specific verb 'Resolve' and names the exact resource: a place name or postal code to an ESTV tax location id. It also gives the domain rationale for why this id matters, which clearly distinguishes it from calculation-focused sibling tools like calculate_tax and compare_locations.
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 implies this is a prerequisite step for calculations by explaining that every calculation is anchored on a tax_location_id. However, it does not explicitly say when not to use this tool or name alternatives such as find_cheapest_nearby or compare_locations, so it stops just short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds useful context about cantonal rate variation and location-driven ranking, but does not mention read-only behavior, defaults, or how the tax result is structured. The output schema helps, but the description itself is somewhat minimal.
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 compact and front-loaded: the first sentence states the core purpose, and the second gives the most important usage pattern without redundant detail. Every sentence earns its place.
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 large 12-parameter schema, a detailed output schema, and strong per-parameter descriptions, the tool description does not need to explain every field. It supplies the missing context: what the tool is for, who it targets, and how to invoke the ranking mode. It could have been more explicit about sibling distinctions, but is otherwise complete enough for correct invocation.
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 high at 83%, so the schema already documents most parameters. The description adds meaning beyond the schema by explaining that location values like canton codes, 'capitals' and 'switzerland' trigger ranking, and by framing the calculation around company profit and capital taxes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes profit and capital tax for companies (GmbH, AG or similar), which distinguishes it from personal-tax siblings like calculate_tax. It also hints at a ranking behavior via location, adding functional clarity beyond the tool name alone.
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 explicitly explains when to use the tool: pass a canton code, 'capitals' or 'switzerland' as location to rank places, and notes this is the usual reason to call it. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. 'Report' implies a read-only operation, and the absence of parameters suggests no side effects, but this is only implied, not explicitly stated. For an introspection tool with no parameters, the behavior is fairly clear, but it does not disclose exactly what 'currently covers' means or whether results vary by location.
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 a single sentence, front-loaded with the core action and subject. There is no filler or redundant content; every word adds meaning.
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?
With no parameters and an output schema present, the description fully explains what the tool does. The absence of details on return format is acceptable because the output schema is provided. For its simplicity, the description is complete.
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?
The tool has zero parameters, so the schema is empty. Per the rubric, with 0 parameters the baseline is 4. The description does not need to explain parameter semantics since 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?
The description uses a specific verb ('Report') and a specific resource ('which tax years each ESTV calculator currently covers'). This clearly distinguishes the tool from sibling tools that deal with calculations, comparisons, or deductions, none of which address tax-year coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Since it takes no parameters and is a simple query, the intended use might be obvious, but the description does not explicitly state prerequisites, context, or when it would be preferable to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does substantial work: it discloses that rates are cantonal and vary enormously, that spouses/direct descendants are usually exempt, that unrelated beneficiaries/unmarried partners may pay about a quarter, and that relationship outweighs amount. It doesn't discuss output shape, but the presence of an output schema covers that.
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?
Three sentences, each earning its place: domain context, behavioral insight, and usage modes. The only slight weakness is the opening fragment, but the overall size and front-loading are appropriate.
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?
For a 7-parameter tool with an output schema, the description gives the essential domain logic and the two main query modes without restating schema fields. It could more explicitly say that providing a specific beneficiary and location returns a single tax calculation, but the existing wording is sufficient for an agent to call the tool correctly.
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 moderate at 71%, and the description enriches the two most complex parameters: beneficiary (relationship matters more than amount; omitting it changes the query mode) and location (canton code/'capitals'/'switzerland' triggers ranking). Other parameters are adequately documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as covering inheritance and gift tax and frames the key determinant (beneficiary relationship), so an agent can see what domain it covers. It lacks an explicit verb like 'calculates', but the tool name and first sentence make the purpose unambiguous, and the domain distinguishes it from sibling tax calculators.
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 second half gives concrete usage instructions: omit beneficiary to list all relationships for a place, or pass a canton code/'capitals'/'switzerland' to rank places for a relationship. It does not explicitly name alternatives such as calculate_tax, but the scenarios are specific enough to guide correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It discloses that the tool returns default values, marks editable lines, and notes that non-editable lines are computed by the model. It also reveals the integration point with calculate_tax. It does not explicitly state whether the call is read-only, but 'Show' strongly implies a non-mutating operation.
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 adds only essential detail: what line items are returned, which are editable, how overrides work, and which lines are model-computed. Every sentence earns its place; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output semantics and the connection to calculate_tax well, and an output schema exists to cover return structure. However, with 14 parameters, no annotations, and only 29% schema description coverage, the input side is under-served. The agent can infer some meaning from parameter names and defaults, but the description does not explain how household characteristics map to the deduction sheet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, so the description needed to compensate by explaining how parameters like location, income1, tax_year, relationship, and others affect the output. It does not; it focuses entirely on the output shape and the link to calculate_tax. The example deduction ids (PRAEMIEN3A, SCHULDZINSEN) relate to the output, not to the input parameters.
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 and resource: 'Show the deduction/budget sheet ESTV derives for a household.' It then clarifies the exact scope by saying it returns every line item with default values and distinguishes editable from non-editable lines. This clearly differentiates it from calculate_tax and other siblings.
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 explains how the tool relates to calculate_tax: editable lines can be overridden through the `deductions` argument of calculate_tax, keyed by id. This implies the intended workflow of inspecting defaults before overriding them, though it does not explicitly state 'use this when...' or list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does meaningful work: it discloses the same-year aggregation rule, states that splitting within one year saves nothing, and warns the agent to read `caveats` in the result before acting. This gives the agent important information about the tool's model and limitations beyond what the schema provides.
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 three short sentences with no filler. The purpose is front-loaded, followed by the tax rationale and a practical caveat warning. Every sentence earns its place.
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?
For a 13-parameter planning tool with an output schema and no annotations, the description explains the core objective, the tax rule being modeled, and directs attention to result caveats. It does not enumerate every input dependency or the returned plan structure, but the schema and output schema cover those. It is sufficiently complete for an agent to decide when and how to invoke the tool.
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 54%, so the schema already documents several key parameters such as location, total_capital, first_year, tranches, max_tranches, years_between, and age_at_first_withdrawal. The description adds conceptual context but no per-parameter detail and does not compensate for undocumented demographic parameters like gender, confession, relationship, or number_of_children. The score reflects adequate but not exceptional parameter guidance.
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 and resource: 'Find the cheapest way to split a lump-sum withdrawal across tax years.' It clearly signals an optimization/planning tool and distinguishes it from siblings like calculate_capital_payment_tax by focusing on multi-year splitting rather than single-payment tax calculation. The objective is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a clear use case: optimizing a lump-sum pension withdrawal across calendar years, and explains why splitting matters due to progressive taxation and same-year aggregation. However, it does not explicitly name alternatives or say when not to use this tool, such as when a single-year capital payment tax calculation is needed via calculate_capital_payment_tax. The guidance is therefore implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool uses ESTV's detailed model and derives social-insurance contributions and standard deductions from gross figures, which is beyond what the schema reveals. This helps the agent understand the calculation behavior and why certain inputs suffice. No contradictions with annotations (none provided), so score is limited by not describing output format or edge cases, but behavioral context is solid.
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 two short paragraphs. The first sentence states the purpose, and the second paragraph explains the model and gives actionable guidance. Every sentence earns its place; there is no repetition or fluff. The information is front-loaded with the core purpose, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters) and low schema coverage, the description is not fully complete. It communicates the high-level model and the optional deduction flow but does not explain how to set parameters like relationship, confession, children_ages, or how to interpret location. The output schema exists, so return values are covered, but the input attribution for many parameters remains unclear. It is adequate for a high-level overview but lacks depth for a complex tool.
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 coverage is only 44%, so the description needs to compensate. It explains that income, wealth, and family situation are the core inputs, and that deductions are optional overrides from list_deductions. However, it does not explain parameters like age, children_ages, relationship, confession, or location, leaving many parameters under-specified. It adds value for the deductions and overall model but doesn't fully compensate for the low schema coverage.
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 states a specific action and resource: 'Compute federal, cantonal, municipal and church tax for a household.' This clearly distinguishes it from siblings like calculate_tax_from_taxable_amounts, which computes from taxable amounts, and other tax tools. The scope (household) and the authoritative model (ESTV) are also explicit, leaving no ambiguity about what the tool does.
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 gives explicit guidance to call `list_deductions` first when real deductions are needed, which is a clear alternative/ prerequisite step. However, it does not explicitly contrast with `calculate_tax_from_taxable_amounts` or other siblings, so the agent must infer when to use this tool instead. The context 'you only need income, wealth and family situation' implies this is the right tool for gross-figure inputs, but the exclusion of alternatives is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses that the cantonal figure is 'einfache Staatssteuer', that the amount comes from ESTV, and that the `ladder` may be absent for formula-based cantons. These specifics go beyond the generic read-only implication of 'show' and add real, useful behavioral context. It does not explicitly state that the tool makes no modifications, but the verbs and content strongly imply a non-mutating operation.
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?
The description is concise and well-structured: a one-line summary, followed by a paragraph on explanatory behavior, and a final note on an edge case. Each sentence contributes useful information without redundancy. It is not as tight as a two-sentence version, but it earns a 4 for efficiency and logical flow.
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?
The tool is moderately complex (7 parameters, 2 required, with an output schema). The description covers the core purpose, differentiates from alternatives, and discloses an important edge case (ladder absence). It does not explain the output structure, but that is covered by the output schema. It also omits explicit guidance on `tax_year` or `language`, though these are self-explanatory. Overall, an agent has enough context to choose and invoke this tool correctly.
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 of 7 parameters have descriptions). The tool description adds minimal parameter-specific meaning: it references 'the household' in connection to bracket determination, but this is already implied by the `has_children` and `relationship` parameters. The description does not clarify syntax, units, or the meaning of `ladder` absence per parameter. It adds marginal value beyond the schema, so a 3 is appropriate.
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 'Show the statutory rate ladder and where an income sits in it', which names a specific verb, resource, and outcome. It further differentiates itself from pure tax computation by saying 'Explains the number rather than just producing it', making the tool's purpose unmistakable and distinct from siblings like calculate_tax.
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 conveys when to use this tool ('Explains the number rather than just producing it'), implying a contrast with calculation-only tools, but it never names an alternative explicitly or states a when-not condition. This is clear context but lacks explicit exclusions, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the behavioral disclosure burden. It clearly states that inputs must be already-taxable amounts and that no gross-salary processing is involved, and it surfaces the important caveat that cantonal and federal taxable income can differ. It does not describe output structure or side effects, but this is a pure calculation tool and the output schema covers return 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 compact and well-structured: the main action is in the first sentence, the usage trigger in the second, and the domain caveat in the third. There is no filler or redundant repetition of schema fields.
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?
For a 10-parameter tool, the description provides the essential contextual cue that distinguishes it from calculate_tax and warns about the typical federal/cantonal discrepancy. The output schema exists, so return-value details are not required here. It is slightly light on family/confession parameter guidance, but those are enumerated in the schema and are standard tax inputs.
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 only 40%, so the description should compensate. It does clarify the key income parameters by stating they are assessed taxable amounts, not gross salaries, and it explains the federal/cantonal distinction. However, it says nothing about tax_year, confession, relationship, or children_ages, leaving the agent to rely on schema titles and enums for many parameters.
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 opening sentence names a specific operation ('apply the tax scales') on a specific input class ('amounts already known to be taxable'). The second sentence clearly separates this tool from gross-salary-based tax calculation, which is exactly the relevant distinction among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger condition: use this when the user is reading figures off a tax assessment or return rather than providing a gross salary. It also contrasts with the gross-salary alternative, effectively telling the agent which path not to take.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It explains that the tool sweeps a budget line, reports tax saved at each level plus marginal saving per franc, and also shares a non-obvious behavioral trait: progressive rates make the last franc worth more, and the return flattens at bracket boundaries. This gives the agent a mental model of the tool's output dynamics.
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 three sentences, each earning its place. The first states the purpose, the second explains the mechanism, and the third illuminates the progressive-rate behavior. It is front-loaded with the core value proposition and contains no fluff or redundancy.
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 complexity (17 params, output schema present), the description provides a coherent overview of what the tool does and how the sweep works. It does not detail every parameter, but the schema covers required fields and the output schema covers return structure. The only minor omission is explicit mention of household inputs, but the description's focus on the deduction sweep is sufficient for an agent to understand the core intent.
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 only 41%, so the description should compensate for the undocumented params. It does add context around key parameters: 'pillar 3a by default' clarifies deduction_id, and 'sweeps a budget line' clarifies amounts and max_amount. However, many household parameters (age, confession, children, etc.) remain unexplained, so the description only partially compensates for the schema gaps.
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 and resource: 'Measure what a deduction is actually worth to this household.' It goes on to explain the sweep of a budget line and reporting of tax saved, which clearly differentiates it from siblings like calculate_tax or list_deductions. The purpose is unambiguous and actionable.
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 implies when to use the tool: when you need to understand the value of a specific deduction to a household. It provides context but does not explicitly name alternatives or exclusions; however, the context is strong enough for an agent to infer the right scenario. No misleading guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![swiss-tax-calculator-mcp MCP server](https://glama.ai/mcp/servers/Aiyatullah/swiss-tax-calculator-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Aiyatullah/swiss-tax-calculator-mcp)

Score Badge

Copy to your README.md:

[![swiss-tax-calculator-mcp MCP server](https://glama.ai/mcp/servers/Aiyatullah/swiss-tax-calculator-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Aiyatullah/swiss-tax-calculator-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Aiyatullah/swiss-tax-calculator-mcp'

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