estv-mcp

by noaahh

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct tax calculation or query scenario. While `calculate_tax` and `calculate_tax_from_taxable_amounts` both compute tax, they differ in input types (gross vs taxable amounts). Similarly, `compare_locations` and `find_cheapest_nearby` both rank municipalities but one is global with optional filtering and the other is radius-based. Overall, descriptions clearly differentiate purposes, minimizing confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using lowercase with underscores (e.g., `find_location`, `calculate_tax`, `explain_tax_brackets`). The verbs are action-oriented (find, list, calculate, compare, get, plan, explain) and the nouns describe the domain entity. No mixing of conventions, making the pattern predictable.
Tool Count5/5
With 13 tools, the server covers the core Swiss tax calculation domain comprehensively without being bloated. Each tool serves a distinct purpose: location resolution, deduction listing, multiple tax computations (income, capital, inheritance, company), comparison utilities, planning, and bracket explanation. The count feels well-scoped for the complexity of the domain.
Completeness5/5
The tool set covers the full lifecycle of typical Swiss tax queries: resolving locations, understanding deductions, computing taxes from various inputs, comparing municipalities, optimizing capital withdrawals, and explaining brackets. Missing aspects like tax form filing or historical data are outside the server's stated purpose. The surface is complete for calculation and planning tasks.
Average 3.8/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
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that capital withdrawals are taxed separately at reduced rate by canton, but lacks details on other behavioral traits (e.g., how defaults are applied, error handling, or output structure). Since annotations are absent, description carries full burden but falls short.
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?
Extremely concise and front-loaded: defines purpose in first sentence, then adds a key usage hint. Every sentence provides value with no redundancy.
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 11 parameters, 3 required, and output schema present, the description is too sparse. It omits explanations for most parameters and does not guide the agent on how to use defaults or interpret results.
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?
Only location parameter is given additional meaning (ranking behavior). With schema coverage at 36%, most parameters (top, gender, capital, etc.) are left unexplained, failing to compensate for low 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?
Description clearly states it calculates tax on lump-sum payouts from pillar 2 or 3a, using specific verbs and resource. It also hints at ranking behavior, distinguishing it from sibling tools 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on using location values 'capitals' or 'switzerland' for ranking vs. single computation, but does not explicitly state when to use this tool over alternatives like plan_capital_withdrawals or calculate_tax.
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 must fully disclose behavioral traits. It mentions ranking by tax burden but does not explain that the tool computes taxes based on many personal financial parameters (income, wealth, age, etc.), nor does it describe output format or limitations. The description is too brief for a complex tool.
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 short and front-loaded with the core action. The motivational sentence adds context but is not strictly necessary. Overall, it is efficient and easy to parse.
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's complexity (17 parameters, many required, with an output schema), the description is too incomplete. It does not explain the output, the tax calculation dependency, or the ranking criteria. The description fails to provide a complete picture for an AI agent to use the tool correctly without external knowledge.
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 41%, meaning many parameters lack schema descriptions. The tool description only mentions coordinates and radius, ignoring the financial parameters (income, wealth, age, etc.) that are crucial for tax calculation. The description adds minimal meaning beyond what the schema 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 clearly states the tool's purpose: 'Rank municipalities within a radius of a point by tax burden.' It uses a specific verb ('rank') and resource ('municipalities'), and the motivational example ('where is the cheapest place to live?') distinguishes it from sibling tools like 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 provides a clear use case: staying within commuting distance and finding the cheapest location. It instructs the user to 'Pass the coordinates of the office or station and a radius.' However, it does not explicitly mention when not to use this tool or reference alternatives like compare_locations.
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 provided, so description must convey behavior. It implies a read-only calculation but does not explicitly state non-destructive nature or other behavioral traits like data modification or rate limits.
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, front-loaded purpose, no wasted words. Highly concise.
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 12 parameters and an output schema, the description covers the primary use case (ranking locations) but lacks depth on other scenarios. It is adequate but not comprehensive.
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?
With 83% schema coverage, the schema already documents most parameters. The description adds value by explaining the 'location' parameter usage for ranking, but does not enhance understanding of other complex parameters like 'patent_box_relief'.
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 it calculates profit and capital tax for companies, and mentions ranking locations. It distinguishes from siblings like 'calculate_tax' and 'compare_locations', but could be more explicit about the return format.
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 hints at when to use (ranking places) and why cantonal rates differ, but does not explicitly state when not to use or mention alternatives like 'calculate_tax'.
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 must cover behavioral traits. It reveals that the tool automatically derives social-insurance contributions and standard deductions from gross figures, which is a key behavioral detail. However, it does not disclose potential side effects, authorization needs, rate limits, or what happens to conflicts with standard deductions. Given the complexity, the transparency is adequate but not thorough.
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, consisting of two short paragraphs. It is front-loaded with the main purpose, followed by the model explanation, and ends with a usage guideline. There is no redundant or unnecessary information, making it easy to read and understand quickly.
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 has 16 parameters and an output schema, the description provides sufficient context for an agent to decide when to use it. It explains the model's behavior and mentions a sibling tool. The schema handles parameter details, so the description doesn't need to repeat them. It feels complete for a tool of this complexity.
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?
The schema description coverage is 44%, so many parameters already have descriptions in the schema. The description adds context by emphasizing that only income, wealth, and family situation are needed, grouping the core parameters. It does not describe individual parameters beyond what the schema provides, but it does offer a high-level understanding. Baseline 3 is appropriate.
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 that the tool computes federal, cantonal, municipal and church tax for a household. It specifies the model used (ESTV) and the inputs needed (income, wealth, family situation). It distinguishes from sibling `list_deductions` by mentioning it as a prerequisite for optional deductions, but does not explicitly differentiate from other siblings like `calculate_tax_from_taxable_amounts`.
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 on when to use the tool: when you have gross income, wealth, and family situation. It advises calling `list_deductions` first if you want to supply optional deductions like pillar 3a. This helps the agent understand prerequisites and when to use this tool versus a sibling. However, it does not explicitly state when not to use it.
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?
Given no annotations, the description carries full burden. It explains why tax_location_id is needed but does not disclose behavioral details such as whether multiple results can be returned, what happens if query is ambiguous, authentication requirements, or error handling. The schema shows a limit parameter implying multiple results, but description says 'resolve to' (singular), causing ambiguity.
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 fluff. First sentence states the primary purpose; second provides necessary context about why the result matters. Every word 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 an output schema exists (not shown), description need not detail return values. It covers essential purpose and motivation for using the tool. However, it lacks usage guidance and behavioral details, but overall is adequate for a lookup tool with clear purpose.
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 high (75%) and most parameters have descriptive explanations (limit, query examples, language enum, tax_year purpose). The description adds general context about the output being a tax_location_id but does not elaborate on individual parameters beyond the query. Baseline 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 uses the verb 'Resolve' and specifies the resource: a place name or postal code to an ESTV tax location id. It clearly distinguishes itself from sibling calculation tools by being a lookup tool for tax location IDs.
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 implies usage when needing a tax location id from a place name, but does not explicitly state when to use or not use this tool compared to siblings like compare_locations or find_cheapest_nearby. No alternatives or exclusions are mentioned.
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?
With no annotations provided, the description must fully disclose behavioral traits. It only states the tool reports coverage, but does not explicitly confirm it is read-only, note any authentication requirements, or mention side effects. For a tool with no parameters, this is insufficient transparency.
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, concise sentence that communicates the tool's purpose without extraneous words. It is efficient and front-loaded, earning a top score.
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 simplicity of the tool (no parameters, with output schema), the description is fairly complete. It covers the main purpose, though it could clarify terms like 'ESTV calculator' or 'covers' for absolute clarity. Overall, it meets the needs for a report 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?
There are no parameters, so the description naturally adds no parameter-level detail. Since schema coverage is 100% (empty schema), the baseline is 4. The description is adequate; it does not need to elaborate further on 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 clearly states the tool's function: reporting which tax years each ESTV calculator covers. It uses a specific verb ('Report') and resource ('tax years each ESTV calculator'), making the purpose unambiguous and differentiating it from sibling tools that focus on calculations or location.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or context such as 'use this to check available data before running calculations'. This lack of usage direction weakens its utility for an AI agent.
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 carries the full burden. It describes the tool as applying tax scales, which is a stateless calculation. It does not explicitly state that it is read-only or has no side effects, but that is implied. It does not mention auth needs, rate limits, or potential destruction. For a calculation tool, this is adequate but not exhaustive.
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 extremely concise: two sentences and a note. Every sentence provides essential information without fluff. It is front-loaded with the action verb 'Apply', making the purpose immediately clear.
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 has 10 parameters, an output schema exists, and it is a calculation tool, the description adequately covers the key usage scenario and differentiates from gross-salary-based calculation. It could be more complete by explicitly referencing the sibling 'calculate_tax' tool or describing the output format, but the output schema mitigates that need.
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 40% (4 of 10 parameters have descriptions). The description adds context for the main required parameters (taxable incomes) by explaining they come from assessment, but does not add semantic detail for the other 6 parameters. The description provides marginal value beyond the schema, but does not fully compensate for gaps.
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 applies tax scales to amounts already known to be taxable, and distinguishes from gross salary calculations. It specifies the use case (reading from tax assessment). However, it could be more explicit about differentiating from the sibling tool '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 explicitly says when to use this tool ('when the user reads figures off a tax assessment... instead of a gross salary'), providing clear context. It does not mention when not to use it or alternatives, but the sibling list includes 'calculate_tax', which an agent could infer. The note about cantonal/federal differences is helpful for understanding parameter usage.
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 returns every line item with default values and distinguishes editable vs non-editable lines. It does not mention side effects, but the read-only nature is implied. It provides useful behavioral context beyond what a bare schema would give.
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 long, well-structured, and front-loads the purpose. Every sentence adds value: purpose, output format, and relation to sibling tool. No wasted words.
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?
Despite having an output schema, the description omits any link between input parameters and the output deductions. With 14 parameters and low schema coverage, the description should provide more context on how parameters influence results. It explains the output well but is incomplete for a complex tool.
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 29%, meaning most parameters lack descriptions in the schema. The tool description does not explain any parameters or how they affect the output. Given this gap, the description should have compensated but did not, leaving agents uninformed about input 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 states 'Show the deduction/budget sheet ESTV derives for a household', specifying both the verb ('show') and the resource (deduction sheet). It distinguishes from sibling tools by mentioning how editable lines can be overridden in `calculate_tax`, providing context on how this tool fits into the workflow.
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?
Although the description does not explicitly state when to use or not use this tool, it strongly implies that it is a read-only preview for default deductions before using `calculate_tax` for overrides. This provides clear context but lacks explicit alternative scenarios or when-not-to-use instructions.
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 full burden. It explains that payouts within the same calendar year are aggregated before tax, and that the tool searches for the cheapest split. It also warns to read caveats. However, it does not disclose side effects, auth needs, or rate limits.
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 four sentences with a front-loaded purpose statement. Every sentence adds value: purpose, rationale, caveat, and an instruction to read results. No 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?
The tool has 13 parameters and an output schema. The description covers the core logic (progressive tax, within-year aggregation) and advises reading caveats. It does not describe the output format, but the existence of an output schema mitigates this. A minor gap is not detailing how 'cheapest' is determined.
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 description partially compensates by giving context about total_capital, first_year, and age_at_first_withdrawal through the narrative. But it does not explain parameters like gender, language, or location beyond what the schema 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 clearly states the tool's purpose: 'Find the cheapest way to split a lump-sum withdrawal across tax years.' It uses a specific verb ('find'), a specific resource ('cheapest way to split'), and distinguishes from sibling tools like 'calculate_capital_payment_tax' by focusing on multi-year optimization.
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 explains when to use the tool (when withdrawing a pension pot) and warns against splitting within a year because it saves nothing. However, it does not explicitly compare with sibling tools or state when not to use it (e.g., for a single-year calculation).
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?
The description discloses that tax varies by canton and beneficiary relationship matters more than amount. It explains two usage modes, which is good behavioral context. With no annotations, it carries the burden well.
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?
Three sentences packed with essential information, front-loading key points (cantonal variation, beneficiary importance). No wasted words.
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 complexity of inheritance tax and 7 parameters, the description covers main usage modes and key factors. It does not explain language or tax_year, but those are standard. Output schema may fill gaps.
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 71%, with language and tax_year lacking descriptions. The description adds meaning for location and beneficiary (e.g., how to use them for different views), but does not cover all parameters. It partially compensates for missing schema info.
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 calculates inheritance and gift tax, which is cantonal, and emphasizes the importance of beneficiary relationship. It uses specific verbs and resources, distinguishing it from sibling tools 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 provides explicit guidance on how to use the beneficiary and location parameters: omit beneficiary to see all relationships, or pass a location to rank. It gives context but does not explicitly state when to use this tool over siblings.
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?
No annotations exist, so description carries the burden. It discloses a key behavioral trait: when scanning all Switzerland, only extremes and summary statistics are returned. It also suggests workarounds. However, it does not detail what 'total tax burden' includes or other side effects, but for a read tool this is sufficient.
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: purpose, use case, and limitation/workaround. Every sentence earns its place, with no wasted words. The structure is front-loaded with the core purpose.
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 (16 params, no annotations, has output schema), the description covers the essential: what it does, limitations, and how to narrow. It relies on output schema for return format. It is mostly complete but could mention what 'total tax burden' encompasses (e.g., all levels of tax).
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 38%, low, so description should compensate. It adds meaning by explaining that `scope` and `only_cantons` narrow results, but it does not elaborate on income, wealth, or other household parameters. The description provides high-level context but lacks depth 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 description clearly states the tool ranks municipalities by total tax burden for a household, answering 'where would I pay the least?'. It uses specific verbs ('rank') and resource ('municipalities'), and distinguishes from siblings by focusing on comparison across all of Switzerland, with nods to sibling tools like 'find_cheapest_nearby' implicitly via scope limitations.
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 tells when to use (to find least tax location) and provides explicit guidance on limitations: scanning all 2100 municipalities returns only extremes and summary stats, so narrow with `scope` or `only_cantons`. It lacks explicit comparisons to siblings but implies usage context well.
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?
Despite no annotations, the description fully discloses behavioral traits: it sweeps a budget line, reports tax saved at each level and incremental savings, and explains the impact of progressive rates and bracket boundaries on the output.
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 at four sentences, front-loaded with the purpose, and efficiently uses each sentence to convey key information without 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?
Given the tool's complexity (17 parameters, output schema exists), the description covers the core functionality and output but lacks details on prerequisites, error cases, or parameter relationships, leaving some gaps for a complete understanding.
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?
The description adds minimal parameter context beyond mentioning the default deduction type ('pillar 3a'). With 17 parameters and only 41% schema coverage, the description should compensate for undocumented parameters but does not elaborate on required inputs like location and income1.
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's purpose: 'Measure what a deduction is actually worth to this household' and describes the action: 'Sweeps a budget line ... and reports the tax saved at each level'. It uniquely focuses on deduction value, differentiating from sibling tools like calculate_tax or list_deductions.
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 implies when to use the tool (to evaluate deduction value with progressive rates) but does not explicitly mention alternatives or when not to use it. It provides clear context for its application.
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 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.

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:

[![estv-mcp MCP server](https://glama.ai/mcp/servers/noaahh/estv-mcp/badges/card.svg)](https://glama.ai/mcp/servers/noaahh/estv-mcp)

Score Badge

Copy to your README.md:

[![estv-mcp MCP server](https://glama.ai/mcp/servers/noaahh/estv-mcp/badges/score.svg)](https://glama.ai/mcp/servers/noaahh/estv-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/noaahh/estv-mcp'

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