AI2Fin (2Fin) Tax MCP
Server Details
Free public tax MCP: GST/VAT, income, company & capital-gains tax for 50+ countries, source-cited.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.8/5 across 8 of 8 tools scored.
Each tool has a clearly distinct purpose: capital gains tax, company tax, country comparisons, GST/VAT computation, personal income tax, student loan repayments, superannuation, and tax rate lookup. No two tools overlap in functionality.
All names use snake_case and are descriptive, with a mix of verb-first (compare_countries, compute_gst_vat, tax_rate_lookup) and noun-first (cgt_estimate, company_tax_estimate) patterns. Slight inconsistency but still highly readable and predictable.
8 tools cover a comprehensive set of tax estimation and lookup tasks without being excessive. The number is well-scoped for a tax-focused MCP server.
The tool set covers major tax areas (personal, corporate, capital gains, GST, super, student loans, rate lookups) but is primarily Australia-focused. Missing tools for other jurisdictions or niche taxes, but descriptions clearly note limitations.
Available Tools
8 toolscgt_estimateAustralian capital gains tax estimateARead-onlyIdempotentInspect
Estimate Australian capital gains tax for a resident individual by taxing the gain at the marginal rate on top of other income (the difference of two income-tax calculations). Use it for AU asset-sale questions (shares, property, crypto); for pay without an asset sale use income_tax_estimate — other countries' CGT is not covered and returns an error. Applies capital losses before the 50% discount for assets held over 12 months, per ATO ordering; the main-residence exemption and non-resident rules are out of scope.
| Name | Required | Description | Default |
|---|---|---|---|
| income | Yes | Other taxable income for the year in AUD (salary etc.) — sets the marginal rate the gain stacks on | |
| costBase | Yes | Cost base in AUD — what the asset cost, including eligible incidental costs | |
| proceeds | Yes | Sale price of the asset in AUD | |
| capitalLosses | No | Capital losses to offset, in AUD — applied against the gross gain before any discount | |
| heldMoreThan12Months | Yes | True when the asset was held over 12 months, which halves the taxable gain (the 50% CGT discount) |
Output Schema
| Name | Required | Description |
|---|---|---|
| source | Yes | The national tax authority the figures were verified against (e.g. 'ATO — ato.gov.au') |
| country | Yes | Always AU — this tool is Australia-only |
| taxYear | Yes | Financial year whose brackets were used |
| grossGain | Yes | Proceeds minus cost base, floored at 0 (AUD) |
| cgtPayable | Yes | Extra tax caused by the gain (AUD) |
| disclaimer | Yes | General-information note that must accompany any figure shown to a person |
| lossOffset | Yes | Capital losses actually applied (AUD) |
| mayBeStale | Yes | True once the verification date is over a year old — re-confirm with the authority |
| taxableGain | Yes | Gain added on top of other income (AUD) |
| dataVerifiedOn | Yes | ISO date the rate data was last confirmed against the authority |
| discountApplied | Yes | Whether the 50% discount halved the taxable gain |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds valuable behavioral context: how tax is calculated (difference of two income-tax calculations), ordering of capital losses before 50% discount, and what is out of scope. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose and method, followed by usage guidance and behavioral details. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage, rich annotations, and an output schema present, the description provides all needed context: what the tool does, when to use it, its limitations, and detailed parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond schema, explaining how parameters interact (income sets marginal rate, capital losses apply before discount, heldMoreThan12Months halves gain).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it estimates Australian CGT for resident individuals, lists asset types (shares, property, crypto), and distinguishes from sibling tools like income_tax_estimate and other countries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use for AU asset-sale questions, not for pay without asset sale (referencing income_tax_estimate), and notes other countries' CGT is not covered. Also mentions exclusions like main-residence exemption and non-resident rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_tax_estimateCompany tax estimate (AU, US, GB, IN, CA)ARead-onlyIdempotentInspect
Estimate company/corporate income tax on an annual profit for Australia, the US, the UK, India or Canada — the five countries with source-verified company rates — applying the small-business/concessional rate where it covers all income. Use it for company profit questions in those countries; individuals belong to income_tax_estimate, and any other country’s headline rate to tax_rate_lookup. Headline-rate arithmetic only: US state tax, Canadian provincial tax, Indian surcharge/cess and UK marginal relief are flagged in the response note but not computed. A negative profit returns an explanation (losses carry forward), never a negative tax.
| Name | Required | Description | Default |
|---|---|---|---|
| profit | Yes | Annual taxable profit in local currency; a negative value (a loss) returns an explanatory message instead of tax | |
| country | Yes | Country with source-verified company-tax data | |
| smallBusiness | No | Apply the small-business/concessional rate — only honoured where it covers all income (AU base-rate entity, IN s.115BAA); GB/CA thresholds are noted instead |
Output Schema
| Name | Required | Description |
|---|---|---|
| tax | Yes | Company tax on the profit (local currency, rounded) |
| note | Yes | What the headline calculation excludes (state/provincial tax, surcharge/cess, marginal relief …) |
| source | Yes | The national tax authority the figures were verified against (e.g. 'ATO — ato.gov.au') |
| country | Yes | Country estimated |
| afterTax | Yes | Profit after tax |
| taxLabel | Yes | The country's name for the tax, e.g. 'Corporation Tax' |
| disclaimer | Yes | General-information note that must accompany any figure shown to a person |
| mayBeStale | Yes | True once the verification date is over a year old — re-confirm with the authority |
| rateApplied | Yes | Rate actually applied, as a fraction |
| dataVerifiedOn | Yes | ISO date the rate data was last confirmed against the authority |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent behavior. The description adds details: small-business rate application conditions, flags for certain taxes, and negative profit behavior (returns explanation, not negative tax). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no unnecessary words. All information is relevant and efficiently presented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description covers edge cases (negative profit, partial tax computation) and provides complete guidance for usage. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context beyond schema: profit parameter's negative value behavior and smallBusiness parameter's conditions per country. The description enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'estimate', the resource 'company/corporate income tax', and the scope (five countries). It distinguishes from siblings by specifying that individuals use income_tax_estimate and other countries use tax_rate_lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it (company profit questions in those countries) and when not to (individuals, other countries). It also notes limitations like US state tax not being computed, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_countriesMulti-country tax comparisonARead-onlyIdempotentInspect
Compare headline tax rates — GST/VAT, top personal income tax and company tax — across several countries at once. Use it to shortlist or contrast jurisdictions (relocation, expansion, pricing); for one country's full detail use tax_rate_lookup, and to apply a rate to an amount use compute_gst_vat. Codes the dataset does not cover are reported back in unmatchedCodes rather than silently dropped; every matched row cites its national tax authority.
| Name | Required | Description | Default |
|---|---|---|---|
| countries | Yes | Countries to compare — two or more makes a meaningful comparison |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | One row per matched country |
| source | Yes | The national tax authority the figures were verified against (e.g. 'ATO — ato.gov.au') |
| disclaimer | Yes | General-information note that must accompany any figure shown to a person |
| mayBeStale | Yes | True once the verification date is over a year old — re-confirm with the authority |
| dataVerifiedOn | Yes | ISO date the rate data was last confirmed against the authority |
| unmatchedCodes | Yes | Requested codes with no data — nothing was guessed for these |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent nature. Description adds value by explaining unmatched codes are reported rather than silently dropped, and that each matched row cites its tax authority.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two well-structured sentences plus a third for handling unmatched codes. Front-loaded with core purpose, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers purpose, usage, alternatives, error handling, and data provenance. Given read-only nature and output schema, no gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each property. The description adds minor usage hint about 'two or more makes a meaningful comparison' but does not significantly enhance beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool compares headline tax rates (GST/VAT, personal income, company tax) across multiple countries, and explicitly distinguishes from sibling tools tax_rate_lookup and compute_gst_vat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use cases (shortlisting jurisdictions, relocation, expansion, pricing) and when to use alternatives (tax_rate_lookup for single country detail, compute_gst_vat for applying rates). Also mentions unmatched codes behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_gst_vatGST/VAT add or remove calculatorARead-onlyIdempotentInspect
Add or remove a country's GST/VAT on a monetary amount, returning the net / tax / gross split. Use it to convert between tax-exclusive and tax-inclusive prices (invoices, quotes, receipts); for the rates themselves use tax_rate_lookup. Pure arithmetic on the country's current standard rate, rounded to 2 decimals, in the country's local currency. Countries without a single national GST/VAT (e.g. the US) return an explanatory error instead of a wrong number.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 'add' puts tax on top of a net amount; 'remove' extracts the tax already inside a gross amount | add |
| amount | Yes | The monetary amount in the local currency — tax-exclusive when mode=add, tax-inclusive when mode=remove | |
| country | Yes | 2-letter ISO 3166-1 code of the country whose GST/VAT rate applies (case-insensitive) |
Output Schema
| Name | Required | Description |
|---|---|---|
| net | Yes | Amount before tax (local currency, 2 dp) |
| tax | Yes | The GST/VAT portion (local currency, 2 dp) |
| code | Yes | 2-letter ISO country code |
| mode | Yes | Which conversion was performed |
| rate | Yes | Standard rate applied, as a fraction |
| gross | Yes | Amount including tax (local currency, 2 dp) |
| source | Yes | The national tax authority the figures were verified against (e.g. 'ATO — ato.gov.au') |
| country | Yes | Country name |
| disclaimer | Yes | General-information note that must accompany any figure shown to a person |
| mayBeStale | Yes | True once the verification date is over a year old — re-confirm with the authority |
| taxLocalName | Yes | The tax's local name, e.g. 'GST', 'VAT' |
| dataVerifiedOn | Yes | ISO date the rate data was last confirmed against the authority |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral details beyond annotations: pure arithmetic, rounded to 2 decimals, local currency, and error on countries without single national GST/VAT. Annotations declare readOnlyHint, idempotentHint, destructiveHint, all consistent with description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loaded with primary function and key details. Every sentence provides necessary information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all critical aspects: purpose, usage, parameters, edge cases (US error), and distinguishes from sibling. With output schema present, description need not detail return values. Complete for a tool with 3 parameters and an enum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description elaborates on each parameter beyond schema: mode with 'add' and 'remove' semantics, amount interpretation based on mode, country as 2-letter ISO code case-insensitive. Schema coverage is 100% and description adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it adds or removes GST/VAT on a monetary amount, returning net/tax/gross split. It distinguishes from sibling tool tax_rate_lookup by specifying that this tool performs arithmetic conversions, not rate lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (converting between tax-exclusive/inclusive prices for invoices, quotes, receipts) and where not to use (countries like the US return an error). Names alternative tool tax_rate_lookup for rate retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
income_tax_estimateIncome tax & take-home estimate (AU, NZ)ARead-onlyIdempotentInspect
Estimate personal income tax and take-home pay for Australia or New Zealand from gross annual income, using effective-dated brackets that roll over automatically each financial year (AU includes the Medicare levy and Low Income Tax Offset). Use it for individual salary and take-home questions in AU or NZ only — other countries return 'not available' rather than a guess; their headline rates live in tax_rate_lookup. This is a resident-individual estimate, not a filing calculation: deductions and offsets beyond LITO are out of scope, and for compulsory HELP/HECS study-loan repayments use student_loan_repayment.
| Name | Required | Description | Default |
|---|---|---|---|
| income | Yes | Gross annual income in local currency (AUD for AU, NZD for NZ), before tax | |
| country | Yes | Country with bracket data: AU (Australia) or NZ (New Zealand) | |
| taxYear | No | Financial-year label like '2025-26'; omit to use the current financial year in that country's timezone |
Output Schema
| Name | Required | Description |
|---|---|---|
| lito | Yes | Low Income Tax Offset applied (AU only; 0 otherwise) |
| gross | Yes | Gross annual income used |
| source | Yes | The national tax authority the figures were verified against (e.g. 'ATO — ato.gov.au') |
| country | Yes | Country estimated |
| taxYear | Yes | Financial year the brackets belong to |
| currency | Yes | Currency of every monetary field (AUD or NZD) |
| takeHome | Yes | Gross minus total tax |
| totalTax | Yes | Total tax after levies and offsets |
| incomeTax | Yes | Income tax before levies and offsets |
| disclaimer | Yes | General-information note that must accompany any figure shown to a person |
| mayBeStale | Yes | True once the verification date is over a year old — re-confirm with the authority |
| medicareLevy | Yes | Medicare levy (AU only; 0 for NZ) |
| dataVerifiedOn | Yes | ISO date the rate data was last confirmed against the authority |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. Description adds context: uses effective-dated brackets that auto-roll, includes Medicare levy and LITO, is a resident-individual estimate. No contradictions; description enhances transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph that front-loads main purpose. It is relatively concise but could benefit from slight structuring (e.g., bullet points for scope). No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of tax estimation (two countries, automatic bracket rollover, Medicare levy, LITO, exclusions), the description is thorough. Output schema exists, so return values need not be explained. Covers when to use, exclusions, and sibling links.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description mentions 'gross annual income' and 'financial year' but does not significantly add meaning beyond schema descriptions. The schema already provides clear descriptions and examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it estimates personal income tax and take-home pay for AU or NZ from gross annual income, using effective-dated brackets. It distinguishes from sibling tools like tax_rate_lookup and student_loan_repayment, specifying exact scope and exclusions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (individual salary/take-home in AU/NZ), when not to use (other countries return 'not available', deductions/offsets beyond LITO out of scope, HELP/HECS goes to student_loan_repayment), and names alternative tool (tax_rate_lookup for other countries' rates).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
student_loan_repaymentAustralian HELP/HECS study-loan repaymentARead-onlyIdempotentInspect
Estimate the compulsory annual study or training loan repayment (HELP, HECS, VSL, SFSS, SSL, AASL) for an Australian resident from their repayment income, using the marginal system introduced in 2025-26 with effective-dated thresholds that roll over each financial year. Use it for "how much HELP/HECS will I repay" questions in AU; it does not cover the loan balance, indexation or voluntary repayments, and applies to Australia only. Repayment income is broader than taxable income — it adds back reportable super contributions, reportable fringe benefits, net investment loss and exempt foreign income; pass that combined figure.
| Name | Required | Description | Default |
|---|---|---|---|
| taxYear | No | Financial-year label like '2025-26'; omit to use the current Australian financial year | |
| repaymentIncome | Yes | ATO repayment income in AUD (taxable income + reportable super + reportable fringe benefits + net investment loss + exempt foreign income) |
Output Schema
| Name | Required | Description |
|---|---|---|
| source | Yes | The national tax authority the figures were verified against (e.g. 'ATO — ato.gov.au') |
| country | Yes | Always AU — this tool is Australia-only |
| taxYear | Yes | Financial year whose thresholds were used |
| repayment | Yes | Compulsory repayment for the year (AUD) |
| disclaimer | Yes | General-information note that must accompany any figure shown to a person |
| mayBeStale | Yes | True once the verification date is over a year old — re-confirm with the authority |
| minThreshold | Yes | Income at or below which the repayment is nil (AUD) |
| effectiveRate | Yes | repayment ÷ repayment income, as a fraction |
| dataVerifiedOn | Yes | ISO date the rate data was last confirmed against the authority |
| repaymentIncome | Yes | Repayment income used (AUD) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about the marginal system (2025-26), effective-dated thresholds, and the broader definition of repayment income. These are behavioral traits beyond what annotations convey, though it does not detail return structure (but output schema exists). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of about 80 words, front-loading the main purpose. Every sentence adds essential information with no filler. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. The description covers purpose, scope, exclusions, parameter guidance, and behavioral context. For a straightforward estimation tool with good annotations, it is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters described). The description adds meaning by explaining the repayment income concept beyond the schema's bullet list, and notes that taxYear can be omitted for current year. This adds concrete value for agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it estimates compulsory annual study loan repayment for Australian residents using a marginal system with effective-dated thresholds. It specifies loan types (HELP, HECS, VSL, etc.) and directly addresses the user query 'how much HELP/HECS will I repay'. It distinguishes itself from sibling tools by being specific to Australia and study loans, not other tax or investment topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: for estimating compulsory repayments in Australia. It also lists exclusions: 'does not cover the loan balance, indexation or voluntary repayments'. It provides context on repayment income composition. However, it does not explicitly say when not to use it or compare against specific sibling tools, though the scope is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
superannuation_estimateAustralian superannuation estimateARead-onlyIdempotentInspect
Estimate Australian superannuation for an employee: the compulsory Superannuation Guarantee contribution (12% from 2025-26), concessional (before-tax) contributions cap usage, the 15% in-fund contributions tax, and the Division 293 high-earner surcharge — all effective-dated so a future budget year is picked automatically. Use it for "how much super will I get / can I contribute / will I be taxed" questions in AU; it does not model fund fees, insurance, investment returns, non-concessional contributions or carry-forward caps, and applies to Australia only. Salary sacrifice and personal deductible contributions add to the concessional total; other taxable income is only needed to test the Division 293 threshold.
| Name | Required | Description | Default |
|---|---|---|---|
| taxYear | No | Financial-year label like '2025-26'; omit to use the current Australian financial year | |
| salarySacrifice | No | Voluntary before-tax (concessional) contributions in AUD | |
| ordinaryEarnings | Yes | Ordinary time earnings the Superannuation Guarantee applies to, in AUD (usually salary/wages) | |
| otherTaxableIncome | No | Other taxable income in AUD — only used to test the Division 293 high-earner threshold | |
| personalDeductible | No | Personal contributions claimed as a tax deduction in AUD (also concessional) |
Output Schema
| Name | Required | Description |
|---|---|---|
| sgRate | Yes | Superannuation Guarantee rate applied, as a fraction |
| source | Yes | The national tax authority the figures were verified against (e.g. 'ATO — ato.gov.au') |
| country | Yes | Always AU — this tool is Australia-only |
| taxYear | Yes | Financial year whose parameters were used |
| div293Tax | Yes | Division 293 surcharge (extra 15%), 0 when it does not apply (AUD) |
| disclaimer | Yes | General-information note that must accompany any figure shown to a person |
| mayBeStale | Yes | True once the verification date is over a year old — re-confirm with the authority |
| div293Applies | Yes | Whether the Division 293 high-earner surcharge applies |
| dataVerifiedOn | Yes | ISO date the rate data was last confirmed against the authority |
| concessionalCap | Yes | Concessional contributions cap for the year (AUD) |
| guaranteeAmount | Yes | Compulsory employer SG contribution for the year (AUD) |
| contributionsTax | Yes | 15% contributions tax on concessional contributions within the cap (AUD) |
| excessConcessional | Yes | Concessional contributions above the cap (AUD) |
| guaranteeableEarnings | Yes | Earnings the SG applied to after the maximum contribution base cap (AUD) |
| concessionalContributions | Yes | SG + salary sacrifice + personal deductible, all concessional (AUD) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: it is 'effective-dated so a future budget year is picked automatically', explains that salary sacrifice and personal deductible contributions add to concessional total, and other taxable income is only for Division 293 threshold. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 3-4 sentences, each sentence adding value. It is front-loaded with the main purpose, then lists modeled components, then exclusions. Slightly verbose but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of Australian superannuation (5 parameters, 1 required, 100% schema coverage, output schema exists), the description covers what it does, what it models, what it excludes, effective-dating behavior, and usage guidance. It is complete for an agent to understand the tool's domain and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds conceptual meaning: it explains the relationship between salary sacrifice and personal deductible (both concessional) and that otherTaxableIncome is only for Division 293 threshold. This provides context beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it estimates Australian superannuation, listing specific components (Superannuation Guarantee, concessional cap, in-fund tax, Division 293 surcharge). It distinguishes from siblings by being specific to AU super and mentioning what it does not model (fund fees, insurance, etc.), aligning with the sibling tools list which includes other tax estimates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use it for how much super will I get / can I contribute / will I be taxed questions in AU' and lists exclusions ('does not model fund fees, insurance, investment returns, non-concessional contributions or carry-forward caps'), providing clear when-to-use and when-not-to-use guidance. It also restricts applicability to Australia only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tax_rate_lookupCountry tax rate lookupARead-onlyIdempotentInspect
Look up one country's headline tax rates: GST/VAT standard and reduced rates, top personal income tax rate, and company tax rate. Use it for a single country; to see several countries side by side use compare_countries, and to apply GST/VAT to an amount use compute_gst_vat. Rates come from a fixed dataset verified against the national tax authority — every answer names its source and verification date, and an unsupported country returns a clear error rather than a guess.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | 2-letter ISO 3166-1 code of the country to look up (case-insensitive) |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | 2-letter ISO country code |
| source | Yes | The national tax authority the figures were verified against (e.g. 'ATO — ato.gov.au') |
| country | Yes | Country name |
| taxFamily | Yes | Consumption-tax family, e.g. 'GST', 'VAT' or a non-VAT system like retail sales tax |
| disclaimer | Yes | General-information note that must accompany any figure shown to a person |
| mayBeStale | Yes | True once the verification date is over a year old — re-confirm with the authority |
| companyRate | Yes | Headline company tax rate (display string) |
| reducedRates | Yes | Reduced rates as fractions; empty when none |
| standardRate | Yes | Standard consumption-tax rate as a fraction (0.1 = 10%) |
| taxLocalName | Yes | The tax's local name, e.g. 'GST', 'USt' |
| incomeTopRate | Yes | Top personal income tax rate (display string; may note surcharges) |
| dataVerifiedOn | Yes | ISO date the rate data was last confirmed against the authority |
| standardRateDisplay | Yes | Standard rate formatted for display |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent; description adds transparency about data source (fixed dataset, verified by tax authority), output including source/verification date, and error handling for unsupported countries. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with purpose, then usage guidance and behavioral notes. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with output schema, the description covers when to use, how to use, what returns, data provenance, error handling. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with full description, pattern, and examples. Description does not add additional detail beyond the schema (just repeats '2-letter ISO code'). Baseline score 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool looks up tax rates for a single country, naming specific types of rates (GST/VAT, income, company). It distinguishes from siblings by specifying single vs. multi-country and GST/VAT calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool (single country) and provides alternative tools 'compare_countries' for side-by-side and 'compute_gst_vat' for applying rates. Also notes behavior for unsupported countries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!