Money, tax & business calculators kept current with 2026 rules — plus operator insights.
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.
Average 4.3/5 across 66 of 66 tools scored. Lowest: 3.5/5.
Each tool targets a distinct niche (e.g., specific country tax rules, loan types, or legal calculations), with detailed descriptions that clarify boundaries. However, the large number of tools (66) could cause some confusion for an agent trying to select the right one for a general query, especially when multiple tools relate to the same country.
Tool names follow a mostly predictable pattern: lowercase words separated by underscores, often starting with a country name (e.g., 'uk_stamp_duty_sdlt') or a topic (e.g., 'compound_growth'). There are minor deviations, such as abbreviations ('npv_irr', 'sip') and varying use of verbs, but overall the naming is clear and consistent.
At 66 tools, the server is unusually large and covers an extensive range of financial and legal calculators. While each tool justifies its existence, the count exceeds the typical well-scoped range (3–15), making the server feel bloated. A more modular design might improve coherence.
The tool set covers a wide array of domains: personal income taxes, property taxes, loan calculations, investment returns, and specific country regulations. Minor gaps exist (e.g., missing tools for corporate taxes, general retirement planning, or insurance), but the overall coverage is thorough and addresses many niche scenarios that general AI handles poorly.
app_store_developer_feesApp Store / Google Play / Steam Developer Take-Home CalculatorAWhat your app or game actually nets after Apple’s, Google’s, or Valve’s cut — including the 30 Jun 2026 Google Play restructure no AI model has memorized. Computes a developer’s real take-home on the App Store, Google Play, or Steam. General AI gets this wrong three ways. First, Google Play restructured its US/UK/EEA fees on 30 June 2026 — a 10%+5% / 25%+5% matrix keyed to when the user installed your app — which post-dates every model’s training data. Second, all three platforms have a “$1M tier” that works completely differently: Apple’s Small Business Program is opt-in with a prior-calendar-year eligibility test and a mid-year cliff; Google’s 15% bracket is automatic and marginal per calendar year; Steam’s tiers are marginal on per-app LIFETIME gross — models conflate the three into “15% under $1M”. Third, Apple’s EU (DMA) and US (external purchase links) fee situations are under active litigation, where a confident stale answer is the worst answer of all. This tool computes the exact net from the current schedules.
| Name | Required | Description | Default |
|---|---|---|---|
| appleSbp | No | Apple Small Business Program Apple only. Unlike Google’s automatic bracket, SBP is OPT-IN, and eligibility is tested on your PRIOR calendar year’s post-commission proceeds (≤ $1M). Crossing $1M proceeds mid-year flips future sales that year to 30% — a cliff, not a marginal bracket. | yes |
| platform | No | Platform The three stores’ fee structures are not variations on one formula — they are structurally different. This decides everything below. | apple |
| revenueType | No | Revenue type Apple and Google Play only — ignored for Steam. Apple drops any subscription to 15% after the subscriber’s first paid year; Google prices subscriptions on a separate (flat) schedule from one-time purchases. | oneTime |
| googleCohort | No | Install cohort (US/UK/EEA) Google US/UK/EEA, non-subscription revenue only. New installs pay 10%+5% on the first $1M/yr then 25%+5%; existing installs pay a flat 20%+5%. Real revenue is usually a mix — run both to bracket your blend. | newInstalls |
| googleRegion | No | Google Play buyer region Google Play only. Google restructured US/UK/EEA fees effective 30 June 2026 — a service fee plus a separate 5% billing fee, keyed to when the user installed your app. Rest-of-world keeps the classic 15%-to-$1M / 30% schedule. | row |
| annualRevenue | No | Gross revenue ($) Gross annual consumer spend, before the store’s cut. STEAM IS DIFFERENT: enter this app’s LIFETIME gross, not annual — Steam’s tiers are marginal on per-app lifetime revenue, so where you sit depends on everything the app has ever earned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description aligns (calculator, no writes). Adds beyond: mentions litigation for Apple fees and that stale answers are bad, enhancing trust. 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?
Lengthy but every sentence adds value. Front-loaded with purpose, then explains nuances. Could be slightly more concise, but well-organized.
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?
Thoroughly covers platform differences, restructure details, litigation, and tier misconceptions. No output schema, but the description clearly states what is computed (net take-home). Complete for a complex calculator tool.
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 detailed parameter descriptions. The tool description does not add further parameter-level info, but provides overarching context. Baseline 3 is appropriate.
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 the tool computes net take-home for app stores (Apple, Google, Steam) after platform fees. Distinguishes from sibling financial calculators by specifying the unique domain of app store developer fees.
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?
Provides context on when to use (accurate developer fee calculations) and explicitly warns about common mistakes (post-training restructures, differing tier structures, litigation). Does not explicitly list when not to use, but implied by sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apr_to_apyAPR ↔ APY ConverterANominal vs effective rates — what a quoted APR really costs at your compounding frequency. Converts between nominal APR and effective APY at any compounding frequency. This is the difference between what a rate is called and what it actually does to your balance.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Convert | apr-to-apy |
| rate | No | Rate (%) | |
| periods | No | Compounding | 365 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to state behavioral traits. The description is consistent (no contradiction) but does not add extra transparency beyond the 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 two sentences long, no wasted words, and front-loads the core purpose. Every sentence adds value.
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 simplicity of the tool (3 parameters, no output schema), the description fully covers what it does and why it matters. No additional information seems necessary for correct use.
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 all three parameters. The tool description provides context ('nominal vs effective rates') but does not significantly enhance the meaning beyond the schema's minimal descriptions ('Convert', 'Rate (%)', 'Compounding'). Baseline of 3 is appropriate.
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 tool converts between nominal APR and effective APY at any compounding frequency, with a specific verb 'Converts' and resource 'nominal APR and effective APY'. It distinguishes itself from sibling financial calculators by focusing solely on this conversion.
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 explains the purpose ('what a quoted APR really costs at your compounding frequency') but does not provide explicit guidance on when to use vs. when not to use, or mention alternative tools. The context implies use for conversion, but lacks clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
australia_hecs_help_repaymentAustralia HECS-HELP Repayment & Indexation (2025-26 reform)AYour compulsory HELP repayment under the new marginal system, what indexation adds each 1 June, and how the 20% cut and old rules compare. Computes your compulsory HECS-HELP repayment under Australia’s reformed 2025-26 system — a marginal calculation (nil to $67,000, then 15% and 17% slices, then a flat 10% of total income at the top) that replaced the old flat-percentage-of-entire-income scale. Three reforms landed within a year (the marginal flip, indexation recut to the lower of CPI/WPI backdated to 2023, and a one-off 20% balance cut in July 2025), so general AI still computes the old system on the old thresholds. The tool also names the input people get wrong: ATO “repayment income” is not your salary — reportable super contributions and net investment losses are added back.
| Name | Required | Description | Default |
|---|---|---|---|
| balance | No | HELP debt balance today ($) Your current HELP balance (myGov → ATO → loan accounts). Used for the indexation and payoff-horizon estimates. The default is the national average debt. | |
| incomeYear | No | Income year Thresholds are indexed to average weekly earnings each year, so the year changes the answer. | 2026-27 |
| hadDebtJun2025 | No | Did you have a HELP balance on 1 June 2025? Balances as at 1 June 2025 received a one-off 20% cut (passed July 2025), applied automatically before that year’s indexation. | yes |
| repaymentIncome | No | ATO repayment income ($) NOT your salary. ATO “repayment income” = taxable income (excluding assessable FHSS released amounts) + reportable fringe benefits + total net investment loss (including net rental losses) + reportable super contributions + exempt foreign employment income. Salary-sacrificed super and negative-gearing losses are added back — a $95k salary with $10k reportable super contributions is $105k repayment income. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds behavioral context: the tool uses a marginal calculation, handles three reforms (marginal flip, indexation recut, 20% cut), and computes indexation and payoff-horizon estimates. This goes beyond the safety profile provided by 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 about 5 sentences long, each adding value. It front-loads the core purpose and then elaborates on key concepts. A bit lengthy but not wasteful; could be slightly more concise.
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's complexity (multiple parameters, three reforms, input nuance), the description provides a comprehensive overview. It explains the new system, the reforms, the key input mistake, and the parameters' roles. No output schema, but explanation of return is not needed for a computation tool.
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%. The description adds significant meaning: it explains 'repayment income' in detail (what is added back), clarifies the default balance as national average, and explains the income year enumeration for threshold indexing. This complements the schema effectively.
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 tool computes compulsory HECS-HELP repayment under Australia's 2025-26 reformed system, including indexation and comparison with old rules. The verb 'computes' and resource 'HECS-HELP repayment' are specific, and the mention of marginal system distinguishes it from siblings like income_tax or other financial calculators.
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 notes that 'general AI still computes the old system on the old thresholds', implying use this tool for the new system. It also warns about a common input mistake ('repayment income is not your salary'). However, it lacks explicit when-not-to-use or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
break_evenBreak-EvenAUnits and revenue needed to cover costs — and how much pricing moves it. Classic cost-volume-profit analysis: contribution margin, break-even units and revenue, margin of safety if you supply current volume, and the leverage a price change has on all of it.
| Name | Required | Description | Default |
|---|---|---|---|
| price | No | Price per unit | |
| fixedCosts | No | Fixed costs / month Rent, salaries, software — costs that don’t vary with volume. | |
| currentUnits | No | Current monthly units Optional — adds margin-of-safety analysis. | |
| variableCost | No | Variable cost per unit Materials, shipping, payment fees — costs incurred per unit sold. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known to be non-destructive. The description adds context on the specific analyses performed (contribution margin, break-even, margin of safety, price leverage) and the optional nature of current volume, which enhances understanding of the tool's behavior beyond the 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 two sentences, front-loaded with the core purpose, and contains no unnecessary words. Every sentence adds meaningful information, achieving maximum conciseness.
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?
Despite no output schema, the description enumerates all key outputs (contribution margin, break-even units and revenue, margin of safety, price leverage). Combined with detailed parameter descriptions, the tool's functionality is fully conveyed for a data analysis tool of moderate complexity.
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 parameters are well-documented. The description adds value by explaining how parameters relate to outputs (e.g., 'current volume' enables margin-of-safety analysis) and summarizing the overall analysis, which goes beyond the schema 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 the tool computes break-even units and revenue, contribution margin, margin of safety, and price change leverage. It uses specific verbs like 'needed to cover costs' and 'how much pricing moves it', making the purpose unmistakable and distinct from siblings such as 'unit_economics'.
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 implies usage for cost-volume-profit analysis but does not explicitly state when to use this tool versus alternatives like 'unit_economics' or 'pricing_margin'. No when-not-to-use or alternative tools are mentioned, providing only implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cagrCAGR CalculatorBCompound annual growth rate — the honest average that volatile returns hide behind. CAGR between a start and end value over a period, plus the reverse projection — and why CAGR beats "average return" for judging any investment or revenue history.
| Name | Required | Description | Default |
|---|---|---|---|
| years | No | Years | |
| endValue | No | Ending value | |
| startValue | No | Starting value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, so no destructive effects. The description adds context about CAGR's advantage over average return and mentions reverse projection, but does not disclose additional behaviors beyond what annotations already convey. It is adequate but not exceptional.
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 sentence that is mostly informative but includes some editorial content ('the honest average that volatile returns hide behind'). While not lengthy, it could be more concise and focused on factual functionality.
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?
The description covers the main purpose (CAGR calculation and reverse projection) but lacks detail on what 'reverse projection' entails. Given no output schema and fully documented parameters, the description is moderately complete but could be more explicit about use cases and outputs.
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 the schema fully documents each parameter with descriptions and defaults. The tool description provides a high-level overview but does not add parameter-specific meaning beyond what the schema already provides.
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 computes CAGR between start and end values over a period, and includes reverse projection. It identifies the specific financial metric (CAGR) and contrasts it with 'average return,' but does not explicitly distinguish from sibling tools like 'compound_growth' or 'roi.'
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?
There is no explicit guidance on when to use this tool versus alternatives. The description implies it is for CAGR calculations, but does not provide when-to-use or when-not-to-use criteria, nor does it reference sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
car_loanCar Loan CalculatorAWhat a car actually costs you a month — priced for your market, where tax may or may not already be in the sticker. A car payment depends on something most calculators quietly assume: whether tax is added at purchase or already sitting in the advertised price. In the US, Canada and Japan it is added on top — and in most US states a trade-in is credited before tax is worked out. In the UK, the EU, Australia, Singapore and India, VAT or GST is already inside the sticker, so adding it again overstates the loan by the full tax rate. Pick the market and the rest follows, together with the negative-equity warning the dealership finance office will not give you.
| Name | Required | Description | Default |
|---|---|---|---|
| down | No | Down payment | |
| rate | No | Interest rate (APR) (%) | |
| price | No | Vehicle price | |
| market | No | Where are you buying? This is the input that decides whether the answer is right. Where tax is added at purchase (US, Canada, Japan) it is charged on top of the advertised price. Almost everywhere else — the UK, the EU, Australia, Singapore, India — VAT/GST is already inside the price, so adding it again overstates the loan. | US |
| months | No | Term (mo) | |
| tradeIn | No | Trade-in / part-exchange value In most US states a trade-in reduces the amount you are taxed on. Where tax is already in the price it simply lowers what you borrow. | |
| salesTax | No | Sales tax / GST added at purchase (%) Only applies in tax-added markets. Ignored where the advertised price already includes VAT/GST. | |
| vehicleType | No | Petrol or new-energy vehicle? Only changes the answer in China, where new-energy vehicles pay half the purchase tax for 2026–2027, capped at a ¥15,000 reduction. The full exemption ended on 31 December 2025. | ice |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses significant behavioral details beyond the read-only annotation: tax is added on top in US/Canada/Japan, already included in UK/EU/AU/SG/IN, trade-in credits before tax in most US states, salesTax ignored in inclusive markets, and vehicleType only matters in China. This gives a clear picture of how the calculator handles inputs and market variations.
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 considerably longer than typical, but each sentence contributes to explaining the critical tax logic and market differences. It is front-loaded with the purpose and uses a logical structure, though some details could be tightened without losing meaning.
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 no output schema, the description partially covers outputs by mentioning monthly cost and negative-equity warning, but it does not fully specify what the tool returns (e.g., total interest, total cost). The complex market logic and parameter interactions are well covered, but the output side is underexplained, leaving a gap for a calculator tool.
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 detailed parameter descriptions, so the baseline is 3. The description adds a bit of context about market-driven behavior and negative-equity warning, but it largely restates what the schema already explains (e.g., trade-in tax treatment). It does not materially enhance parameter understanding beyond the 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?
The description clearly states the tool computes monthly car loan cost ('What a car actually costs you a month') and emphasizes market-specific tax treatment, distinguishing it from generic loan or mortgage calculators. It also hints at a unique negative-equity warning, further separating it from siblings.
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 provides strong contextual guidance on when to use the tool—specifically for car loans in markets with tax-inclusive vs tax-exclusive pricing—and explains how market selection drives the calculation. It does not explicitly name alternative tools, but the focus on car-loan-specific tax logic implies when this is the right choice over generic tools like loan_payment or mortgage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
china_income_tax_salaryChina Salary Tax & Net Pay (cumulative withholding 累计预扣)AYour real China take-home month by month — under the cumulative method, where the same salary is taxed more each month as the year goes on. Computes monthly and annual individual income tax (IIT) on a China salary using the actual cumulative withholding method (累计预扣预缴法). Because tax is recomputed on year-to-date income, the same gross salary is withheld more each month as cumulative income climbs the brackets — so your take-home falls through the year. Simple monthly-bracket calculators (and general AI) get every month after the first bracket crossing wrong.
| Name | Required | Description | Default |
|---|---|---|---|
| monthlyGross | No | Monthly gross salary Assumed constant across the year. | |
| socialInsurance | No | Monthly social insurance & fund (个人部分) Your own 五险一金 deduction per month (专项扣除) — this reduces taxable income. Use the 五险一金 calculator to get it. | |
| specialDeductions | No | Monthly special additional deductions (专项附加扣除) Total of children’s education (2,000/child), childcare under 3 (2,000/child), elderly care (up to 3,000), housing loan interest (1,000) or rent (800–1,500), continuing education (400). These cut tax, not cash. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint, but the description goes far beyond by detailing the cumulative method's effect: tax increases each month, take-home falls. It also warns about common mistakes, giving rich behavioral context beyond what annotations offer.
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 appropriately sized for the tool's complexity. Every sentence earns its place: it explains the core concept, warns about common errors, and provides context for parameters. Key information is front-loaded.
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's complexity (cumulative method, three parameters) and no output schema, the description explains the behavior thoroughly. It lacks explicit mention of return values, but the output is likely a table or numbers, which is implicit. Still, it provides sufficient completeness for an agent to understand what the tool does.
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, but the description adds value by clarifying that monthlyGross is assumed constant, and directs users to another calculator for social insurance. These additions enhance understanding beyond the 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?
The description clearly states the tool computes China IIT using cumulative withholding method, and distinguishes it from simple monthly-bracket calculators by explaining that the same salary leads to decreasing take-home as the year progresses. The verb 'computes' and resource 'China salary tax and net pay' are specific.
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 implies when to use: for accurate China cumulative withholding tax, not simple calculators. It states that simple monthly-bracket calculators and general AI get it wrong, guiding users to this tool for correctness. However, it does not explicitly list alternative sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
china_retirement_pensionChina Retirement Age & Pension Estimator (2025 reform)AYour exact retirement date under China’s 2025 delayed-retirement reform, plus an estimated monthly pension. Computes your statutory retirement age and date under China’s 2025 progressive delayed-retirement reform (渐进式延迟法定退休年龄) — which staggers the age by birth month, gender, and job track — then estimates your monthly pension (基础养老金 + 个人账户养老金). The reform is under two years old, so general AI still quotes the old 60/55/50 ages; this uses the official cohort tables.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City / province Sets your province’s pension calculation base (养老金计发基数) — the number you would otherwise have to look up. Pick “Other” to enter your own below. | beijing |
| mode | No | Pension figures are… Choose “project” if you are still years from retiring: the account keeps growing at the 记账利率 and contributions keep landing, so today’s balance is not the retirement balance. | at-retirement |
| track | No | Which track are you on? The decisive input. For women it hinges on your file classification (管理/技术岗 vs 工人岗), not job title — and it is the single most disputed point, so choose carefully. | male |
| avgWage | No | Pension base override 社平工资 (optional) Leave 0 to use your city’s published base above. Enter a number only to override it (or for a city not listed). In “project” mode this is today’s base; it is grown to retirement. | |
| asOfYear | No | Today’s figures are from (year) Only used in “project” mode — the year your current balance/base are from. Years-to-retirement is counted from here. | |
| birthYear | No | Birth year Gregorian year, e.g. 1980. | |
| birthMonth | No | Birth month The reform buckets by birth month, so this changes the answer. | |
| growthRate | No | Annual salary / base growth (%) Project mode only. Assumed yearly growth of your salary and the local wage base — both future contributions and the indexed basic pension rise with it. | |
| bookingRate | No | Account crediting rate 记账利率 (%) Project mode only. The government-published annual rate credited to your individual account (记账利率) — recent years ~6%. This is not a market investment return. | |
| accountBalance | No | Individual account balance 个人账户储存额 The accumulated balance in your personal pension account. In “project” mode this is today’s balance; it is grown to retirement. | |
| contributionIndex | No | Average contribution index 平均缴费指数 Your contribution base ÷ local average wage, averaged over your career. Capped 0.6–3.0. 1.0 = you always paid on exactly the average wage. | |
| contributionYears | No | Contribution years 缴费年限 Total years contributed, including deemed years 视同缴费年限. In “project” mode this is years so far; the years until retirement are added. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms read-only behavior consistent with annotations. It adds transparency by noting the reform's recency and that it uses official tables, which is valuable beyond 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 clear and informative but somewhat dense. It front-loads the core purpose and then details parameters, making it effective though slightly lengthy.
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 high parameter count and lack of output schema, the description adequately explains all inputs and the reform context. It could be improved by briefly mentioning output format.
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?
All 12 parameters have detailed descriptions covering definitions, units, ranges, default values, and usage context (e.g., track being the most disputed point). This significantly enhances the 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?
The title and description clearly specify the tool computes retirement dates and pension estimates under China's 2025 reform. It distinguishes itself from sibling tools which are generic or for 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?
The description provides context on when to use (for China's reform) and warns against outdated AI knowledge, but does not explicitly state when not to use or mention alternative tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
china_severanceChina Severance Pay Calculator 经济补偿金 (N / N+1 / 2N)AStatutory severance under China’s Labour Contract Law — the N / N+1 / 2N branch and the 3×-average-wage cap, done right. Computes statutory economic compensation (经济补偿金) on leaving a job in China: the base N (one month per year of service, with the ≥6-month rounding), whether it becomes N+1 (pay in lieu of notice) or 2N (unlawful termination), and the two caps that switch on together for high earners — the base capped at 3× the local average wage and years capped at 12. The termination reason is the input that flips the answer, so it is the first question.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City Sets the local average wage whose 3× caps the severance base — a figure you would otherwise have to look up. Pick “Other” (or override below) if your city isn’t listed. | beijing |
| reason | No | How is employment ending? The decisive input. Resignation with no employer fault pays nothing; unlawful termination doubles it. If unsure which Art. 40 case applies, note that the “+1” is only for a non-fault dismissal given without 30 days’ written notice. | n |
| monthlyWage | No | Average monthly wage 月均工资 (pre-tax, incl. bonuses) Average of your last 12 months’ gross pay — base salary + bonuses + allowances, before tax and before your own social-insurance/fund deductions (应得工资). Excludes expense reimbursements. | |
| localAvgWage | No | Local average wage 社平工资 override (optional) Leave 0 to use your city’s figure above. The severance-cap caliber is legally negotiable in some cities (Hangzhou especially), so override if you have a specific figure. | |
| serviceYears | No | Years of service | |
| serviceMonths | No | …plus months The trailing part-year: ≥6 months counts as a full year, under 6 months as half a month’s pay. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which the description aligns with by stating 'computes statutory economic compensation.' Beyond annotations, the description details rounding rules, pay-in-lieu of notice, and unlawful termination doubling, adding valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the core purpose and key formulas. It is concise while covering essential details, though it could benefit from bullet points for clarity.
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?
The description thoroughly covers the calculation scope and key inputs but omits details about the output format (e.g., numeric break down of N, N+1, 2N). Given no output schema, this leaves some ambiguity for the agent.
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 detailed parameter descriptions. The description reinforces semantics by explaining the decisive role of the 'reason' parameter and the cap logic, adding value beyond the 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?
The description clearly states the tool computes statutory severance under China's Labour Contract Law, specifying the N/N+1/2N scenarios and the high-earner cap. It distinguishes itself from siblings like china_income_tax_salary and china_retirement_pension by focusing on severance.
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 explains that the termination reason is the key input and informs about the scenarios (N, N+1, unlawful). It implies usage when leaving a job in China but does not explicitly state when not to use or provide alternatives to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
china_social_insuranceChina Social Insurance & Housing Fund Calculator (五险一金)AHow much 五险一金 comes out of a China salary each month, and what it costs the employer on top. 五险一金 is not a percentage of this month’s pay, which is the assumption almost every calculator makes. Contributions are charged on a contribution base — your average monthly wage across the previous year — and that base is clamped between a floor of roughly 60% of the local average wage and a ceiling of 300% of it. The clamp is the whole story: it is why a high earner’s deduction stops growing past a certain salary, and why someone on a low wage pays a larger share of their pay than the headline rate suggests. Both numbers come out here — what leaves the payslip, and what the employer adds on top. Rates and both limits are set city by city and reset every July, so they are yours to enter; the defaults are Beijing 2025, for illustration.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City Sets the contribution-base floor and ceiling (the ~60%/300%-of-local-average band) — the numbers you would otherwise look up. Pick “Other” to enter your own. | beijing |
| gross | No | Monthly gross salary Used as the contribution base after clamping to the city floor/ceiling. If your official contribution base differs from gross, enter that instead. | |
| baseFloor | No | Base floor 下限 override (optional) Leave 0 to use your city’s floor. Override for a city not listed. | |
| baseCeiling | No | Base ceiling 上限 override (optional) Leave 0 to use your city’s ceiling. Salary above the ceiling is not charged. | |
| housingFundRate | No | Housing fund rate 公积金 (each side) (%) Employer-chosen 5–12%, matched by the employee. Shanghai caps at 7%. | |
| employeeSocialRate | No | Employee social-insurance rate (%) Sum of the employee’s pension (8%) + medical (~2%) + unemployment (~0.5%). Work-injury and maternity are employer-only. | |
| employerSocialRate | No | Employer social-insurance rate (%) Sum of employer pension (16%) + medical (~9%) + unemployment (~0.5%) + work-injury (~0.2–1.9%). City-dependent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description adds meaningful context by explaining the 60%/300% clamp, city-specificity, and July reset. It also clarifies the consequences for high/low earners, which goes beyond the annotation's safety profile. No contradiction detected.
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 detailed but well-structured, front-loading the main question and then introducing the key misconception. Each sentence contributes to understanding the tool's model, and no extraneous information is present.
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 the tool and absence of an output schema, the description adequately defines what outputs to expect ('what leaves the payslip, and what the employer adds on top'). It also sets up the user's responsibility to supply rates/limits. Minor gaps like the exact formula aren't needed because schema already provides parameter roles.
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?
The input schema has 100% description coverage, with each parameter already explained (e.g., 'gross' described as 'Used as the contribution base after clamping'). The tool description does not add new syntax or format details beyond the schema, so baseline 3 is appropriate.
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 tool computes both employee deductions and employer costs for China's 五险一金, with a specific verb ('comes out of') and resource ('China salary'). It distinguishes itself from sibling tools by emphasizing the contribution-base clamp rather than a simple percentage, making it distinct from tools like china_income_tax_salary.
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 explains the mechanism (contribution base vs. monthly pay) and the need for city-specific rates/limits entered by the user, providing clear context for when to use it. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compound_growthCompound GrowthAWhat a starting amount plus monthly contributions grows into over time. Projects the future value of a lump sum plus recurring monthly contributions at a given annual return, compounded monthly. Splits the outcome into what you put in versus what compounding earned, and sanity-checks the assumptions.
| Name | Required | Description | Default |
|---|---|---|---|
| rate | No | Annual return (%) Nominal annual return. 7% is a common long-run equity assumption. | |
| years | No | Years (yr) | |
| monthly | No | Monthly contribution | |
| principal | No | Starting amount |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds limited behavioral context beyond that. It mentions output splitting and sanity-checks, but does not elaborate on assumptions, edge cases, or computational limits.
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 clear, front-loaded sentences without fluff. The description efficiently conveys the tool's purpose and key outputs.
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 4 parameters fully described in schema and no output schema, the description explains the output format (split into contributions vs earnings, sanity-checks). It covers the essential information for an investor to understand the tool's results.
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 the schema already documents each parameter. The description adds output context (splitting, sanity-checks) but does not enhance parameter meaning beyond the 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 projects future value of a lump sum plus monthly contributions with compounding. It specifies splitting outcome into contributions vs earnings and sanity-checking assumptions. This is a specific verb+resource, and the tool's function is distinct among siblings like 'sip' or 'cagr'.
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?
Description implies usage for scenarios with both a starting amount and monthly contributions, but does not explicitly state when to use versus alternatives like 'sip' or 'cagr'. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
creator_platform_payoutCreator Platform Payout CalculatorAWhat you actually net on YouTube, Twitch, Patreon, Substack, or OnlyFans — after the platform cut AND the processing layer nobody advertises. Computes a creator’s real monthly payout after every fee layer on five platforms. Platform fees drift constantly and general AI quotes stale ones — Patreon moved new creators to a flat 10% on 4 Aug 2025 (models still recite the old 5/8/12 tiers), Twitch restructured its split into Plus Points in 2024, OnlyFans changed its payout minimum in Apr 2026. And the advertised "platform cut" is never the whole story: payment processing adds 3–7 points on the subscription platforms, and the per-transaction fixed fee makes small pledges dramatically more expensive — a $3 Patreon pledge loses about 8% to processing alone, a $50 pledge about 3.5%. This tool computes the all-in take rate, which no advertised number states.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Platform Each platform has a completely different fee structure — this decides everything below. | youtube |
| patreonPlan | No | Patreon fee plan Patreon only. Pages created after 4 Aug 2025 pay a flat 10%. Older pages keep their legacy 5/8/12% plan — but unpublishing your page permanently converts you to 10%. It is a one-way door. | new10 |
| twitchSplit | No | Twitch sub split tier Twitch only. Plus Points come from paid subs sustained over 3 months: Tier 1 = 1 point, Tier 2 = 2, Tier 3 = 6; gifted subs and Prime subs do NOT count. 100 points unlocks 60%, 300 points unlocks 70%, with a 12-month rate lock once qualified. | base |
| monthlyGross | No | Monthly gross platform revenue ($) Before ANY cut. For YouTube: the ad revenue allocated to your videos (for Shorts, your allocation from the creator pool). For subscription platforms: total pledges/subs at list price. | |
| youtubeStream | No | YouTube revenue stream YouTube only — ignored for other platforms. Shorts revenue is 45% of an allocation from a shared creator pool (computed after music licensing), so the allocation itself varies before this split applies. | longform |
| avgTransaction | No | Average pledge / sub size ($) Patreon and Substack charge processing per transaction, so the average pledge size changes the all-in rate. Patreon pledges of $3 or less use the micro rate (5% + $0.10) instead of the standard 2.9% + $0.30. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides rich behavioral context beyond the readOnlyHint annotation, such as dynamic platform fees, hidden processing layers, and one-way doors (e.g., Patreon plan changes). 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 effective but lengthy, containing necessary context like fee drift and processing costs. Every sentence adds value, but could be tightened while retaining clarity.
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?
The description thoroughly explains inputs and the computation's purpose, but without an output schema it doesn't specify the output format (e.g., single number vs breakdown). Adequate for the task, but could be more explicit about return values.
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?
With 100% schema description coverage, the description adds substantial meaning: e.g., platform enum explains fee structure, patreonPlan details one-way door, twitchSplit clarifies Plus Points, avgTransaction explains micro rate for small pledges. Fully compensates for any gaps.
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 tool computes a creator's real monthly payout after all fee layers on five platforms. It distinguishes itself from generic AI quotes and sibling tools like tax calculators by focusing on platform-specific payout nuances.
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 explains why this tool is needed (stale AI quotes, hidden processing fees) and implies use for accurate payout calculation. While it doesn't explicitly state when not to use it, the context is clear and no direct alternatives exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
credit_card_payoffCredit Card Payoff CalculatorBHow long your balance really takes to clear — and the minimum-payment trap in numbers. Months and total interest to pay off a credit card balance at your APR and monthly payment, with the concrete payoff acceleration from paying more — the math credit card statements are legally required to hint at and everyone ignores.
| Name | Required | Description | Default |
|---|---|---|---|
| apr | No | APR (%) | |
| balance | No | Balance | |
| payment | No | Monthly payment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's read-only. The description adds context about computing payoff duration and interest, but doesn't disclose assumptions, limitations, or edge cases.
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 verbose with informal language and hyperbolic phrases. It could be more concise while retaining key information.
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 simple calculator with 3 parameters and no output schema, the description adequately explains the purpose and outputs, though it lacks mention of edge cases or output format.
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 clear descriptions and defaults. The description does not add additional meaning or constraints beyond what the schema provides.
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 tool calculates months and total interest to pay off a credit card balance, with specific verb 'pay off' and resource 'credit card balance'. It distinguishes from siblings by focusing on credit card payoff specifics.
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?
No guidance on when to use this tool versus alternatives like loan_payment or mortgage. It does not provide exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
currencyCurrency ConverterAConvert between 31 currencies at the official ECB reference rate — and know what your bank adds on top. Converts any amount between 31 major currencies using the European Central Bank daily reference rate — the neutral mid-market rate — and tells you the part every converter hides: the spread your bank or card will add on top of it.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | To | EUR |
| from | No | From | USD |
| amount | No | Amount |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that it uses ECB daily rates and outputs the bank spread. No contradictions. It could mention rate update frequency but is transparent enough.
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 the primary action, no fluff. Each sentence adds distinct value: conversion + spread insight.
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?
Tool complexity is low with 3 optional parameters. Annotations and schema cover well. No output schema, but description indicates what it returns. Could mention rate update frequency, but sufficient.
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 all parameters (to, from, amount). The description adds no additional parameter-specific meaning, so baseline 3 is appropriate.
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 converts between 31 currencies using the ECB reference rate and also reveals the bank spread. It is the only currency conversion tool among siblings, so no ambiguity.
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 implies usage for currency conversion with mid-market rate and spread estimation. No explicit when-not or alternatives, but sibling tools are all different financial calculators, so confusion is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emiEMI CalculatorALoan EMI, total interest, and the flat-rate trap that makes 10% cost like 18%. Equated Monthly Instalment for any loan — home, car, personal — with total interest over the tenure and the one warning every borrower comparing offers needs: flat rate and reducing-balance rate are not the same thing.
| Name | Required | Description | Default |
|---|---|---|---|
| rate | No | Interest rate (reducing balance) (%) | |
| months | No | Tenure (mo) | |
| principal | No | Loan amount |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the tool is safe. The description adds valuable behavioral context by warning about the flat-rate vs. reducing-balance rate difference, which helps agents interpret results.
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 somewhat verbose and casual, including an exclamation and a metaphor ('flat-rate trap'). It front-loads outputs but could be more concise.
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?
No output schema is provided, so the description should explain return values. It mentions total interest and a warning but does not fully describe the output format (e.g., monthly EMI, total payment). Adequate but not 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 coverage is 100% with descriptions for each parameter (rate, months, principal) and defaults. The description does not add significant meaning beyond the schema, but the flat-rate warning indirectly relates to the rate parameter.
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 calculates Loan EMI, total interest, and includes a crucial warning about flat vs. reducing-balance rates. It distinguishes itself from sibling tools like loan_payment, mortgage, and car_loan by emphasizing the flat-rate trap.
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 says 'for any loan — home, car, personal' but does not explicitly state when to avoid this tool or provide direct alternatives. However, the sibling list implies other specialized calculators for specific loan types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fire_numberFIRE NumberAThe portfolio that makes work optional, and how far away it is. Computes your financial-independence target from annual spending and a safe withdrawal rate, then projects how many years your current savings and monthly contributions take to reach it.
| Name | Required | Description | Default |
|---|---|---|---|
| swr | No | Withdrawal rate (%) The classic "4% rule". Lower is safer. | |
| rate | No | Expected annual return (%) | |
| current | No | Current portfolio | |
| monthly | No | Monthly investing | |
| expenses | No | Annual spending |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's statement of computations is consistent and adds context about the internal logic. However, it does not disclose limitations such as ignoring inflation or return variability.
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 two sentences, front-loaded with purpose, and contains no redundant words. It efficiently conveys the tool's function.
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?
The description explains the two outputs (target amount and years to reach it), which is adequate for a projection tool with no output schema. It could mention whether inflation or fees are considered, but overall it is sufficient for an AI agent.
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 descriptions cover 100% of parameters with clear meanings. The description adds no new semantic detail beyond naming the inputs (e.g., 'annual spending', 'safe withdrawal rate'), so it meets the baseline for high-coverage 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?
The description clearly states the tool computes a financial-independence target and projects years to reach it, using specific verbs like 'computes' and 'projects'. It distinguishes itself from sibling tools like 'savings_goal' and 'runway' by focusing on FIRE concepts.
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 does not explicitly state when to use this tool versus alternatives like 'savings_goal' or 'runway'. It implies use for financial independence calculations but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
france_conges_arret_maladieFrance Paid-Holiday Accrual During Sick Leave (post-2024 rules)AHow many congés payés your sick-leave months actually earn under the April 2024 law — the opposite of what most of the internet still says. Computes the paid-holiday days (congés payés) you acquire in a reference period (1 June – 31 May) that includes sick leave, under France’s April 2024 reform (loi 2024-364 “DDADUE”, Code du travail L3141-3/-5/-5-1). Until that law, ordinary sick leave earned NO paid holiday — decades of French web pages and the AI trained on them still say so — but the law now says the opposite: ordinary sick months accrue 2 jours ouvrables per month (capped at 24 sick-accrued days per period) and work-accident/occupational-illness (AT/MP) months accrue the full 2.5, with the old one-year limit removed. The decisive input is the absence type — it changes both the rate and the cap — and the 15-month carry-over clock that only starts when your employer informs you decides whether the days survive at all.
| Name | Required | Description | Default |
|---|---|---|---|
| convention | No | Your company counts holiday in… The Code counts in jours ouvrables (6-day weeks, 30/year max). Many companies convert to jours ouvrés (5-day weeks, 25/year) — the ×5/6 conversion must never leave you worse off. | ouvrables |
| sickMonths | No | Months on sick leave in the reference period (mo) Months of sick absence between 1 June and 31 May (the legal reference period). Count each month the arrêt covered. | |
| absenceType | No | What kind of sick leave? THE gate — ordinary sick months accrue 2 jours ouvrables/month (sick-accrued portion capped at 24 per period); AT/MP months accrue the full 2.5, and the old one-year limit on AT/MP accrual is gone. | nonOccupational |
| workedMonths | No | Months worked in the same period (mo) Months actually worked (or otherwise fully assimilated to work — maternity leave, training…) in the same 1 June – 31 May period. Sick + worked cannot exceed 12. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation (true), the description discloses behavioral details such as the impact of absence type on accrual rate and cap, the removal of the one-year limit for AT/MP, and the 15-month carry-over clock. This adds significant value beyond 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 informative but verbose, containing nearly 200 words. While it front-loads the key point, it could be more concise without losing necessary context.
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?
The description covers the tool's purpose and inputs thoroughly, including legal background. However, it does not explicitly describe the output format (e.g., the number of days or a breakdown). Given there is no output schema, an explicit mention of return values would enhance completeness.
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?
Although schema description coverage is 100%, the description enriches each parameter with legal context and practical implications. For example, it explains why absenceType is a 'gate' and what the cap means. This goes well beyond the schema 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 the tool computes paid-holiday days acquired during sick leave under France's April 2024 law. It uses specific verbs like 'computes' and defines the resource precisely. It distinguishes itself from sibling tools by being a France-specific HR calculator.
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 provides clear context for when to use this tool (when you have sick leave months in a reference period and want to know accrual under the new law) and emphasizes the decisive input (absenceType). It does not explicitly state when not to use or list alternatives, but the context is strong enough for an agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
freelance_rateFreelance Rate CalculatorAThe hourly rate that actually pays your target income — after unbillable time, overhead, and tax. Works backward from target income to the rate you must charge: subtracting non-billable time, business overhead, time off, and the self-employment tax gap that makes a freelance hour worth less than an employed one.
| Name | Required | Description | Default |
|---|---|---|---|
| overhead | No | Business costs / year Software, equipment, insurance, coworking, accounting. | |
| weeksOff | No | Weeks off / year Vacation + sick + dry spells between clients. | |
| taxBuffer | No | Tax & contributions buffer (%) Income tax + self-employment/social contributions on profit. | |
| targetIncome | No | Target annual take-home | |
| billableHours | No | Billable hours / week Realistic for full-time freelancing: 20-30. Sales, admin, and email are not billable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by explaining the backward calculation logic (subtracting non-billable time, overhead, tax gap). No contradictions.
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 that front-load the purpose and efficiently explain the methodology. No wasted 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?
Almost complete: explains the inputs and logic but does not explicitly mention the output format. With no output schema, a brief note on return value would improve completeness. Otherwise covers the tool's operation well.
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 tool description provides overall context but does not add per-parameter meaning beyond the schema. However, it explains why taxBuffer includes self-employment tax, adding slight 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?
The description clearly states the tool's purpose: calculating the hourly rate needed to achieve a target income after accounting for unbillable time, overhead, and tax. It distinguishes itself from sibling tools like 'us_freelance_vs_employee' and 'true_hourly_wage' by focusing on rate setting.
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 implies when to use (to determine a freelance rate), but does not explicitly mention when not to use or name alternatives. Given the clear use case, it still provides good guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
germany_elterngeldGermany Elterngeld Calculator (Basiselterngeld & ElterngeldPlus)AYour monthly Elterngeld under current BEEG law — the exact three-segment replacement rate, the €300–€1,800 clamp, and the cohort income caps (€175k / €200k / €300k) that changed twice in twelve months. Computes German parental allowance (Elterngeld): the eligibility income cap that depends on your child’s birth date (€175,000 for births from 1 April 2025; €200,000 for the year before; €300,000/€250,000 earlier — general AI quotes stale caps or invents a €150,000 single cap that has never existed), the exact BEEG §2 sliding replacement rate (67% only between €1,000–1,200 net — 65% above €1,240, up to 100% at low incomes), the €300–€1,800 Basiselterngeld clamp unchanged since 2007, ElterngeldPlus (half the amount, double the months), Geschwisterbonus, and Mehrlingszuschlag for multiples.
| Name | Required | Description | Default |
|---|---|---|---|
| variant | No | Which variant? ElterngeldPlus pays half the Basis amount for double the months — designed for working part-time while receiving. Both are shown; this picks the headline. | basis |
| household | No | Household Only the pre-Apr-2024 cohort has different caps by household type. Single parents can claim all partner months themselves. | couple |
| multiples | No | Children in this birth Twins = 2. Mehrlingszuschlag adds €300 per additional child of the same birth (€150 in Plus months). | |
| monthlyNet | No | Your average monthly net earned income before birth (€/mo) Average monthly NET earned income of the 12 months before birth (before Mutterschutz for the mother). Months on Elterngeld for an older child, on Mutterschaftsgeld, or ill due to pregnancy are skipped — the window reaches further back instead. | |
| birthCohort | No | When is (was) your child born? The decisive input: the eligibility income CAP depends on the child’s birth date — €175k / €200k / €300k(couples)-€250k(singles). This cohort trap is what general AI misses entirely (it also invents a €150k single cap that has never existed). | from2025 |
| siblingBonus | No | Geschwisterbonus (sibling bonus)? Applies while at least one other child under 3 (or two others under 6) lives in the household: +10% of your Elterngeld, minimum €75 (€37.50 in Plus months). | no |
| taxableIncome | No | Taxable income in the calendar year before birth (zu versteuerndes Einkommen) (€/yr) The household’s zu versteuerndes Einkommen per the Steuerbescheid — taxable income, NOT gross salary — in the calendar year before the birth. Over the cohort’s cap → no Elterngeld at all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Detailed description of calculation logic, cohort-dependent caps, sliding replacement rates, and bonuses. ReadOnlyHint is consistent; no contradictions. Adds significant behavioral context beyond 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?
Well-structured with a clear opening sentence, but the description is quite long. Could be slightly more concise, but the detail is justified by 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?
Covers all relevant aspects: eligibility, calculation rules, cohorts, bonuses, warnings about common mistakes. No output schema, but description is self-contained and 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?
Adds substantial meaning beyond the input schema by explaining the logic behind each parameter (e.g., cohort trap, income definitions). Schema coverage is 100%, but description enriches 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?
Clearly states it computes monthly Elterngeld under BEEG law with specific details on replacement rates, caps, and bonuses. Distinct from sibling tools, which are other calculators.
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?
Provides clear context on when to use (accurate German parental allowance calculation) and warns about common AI errors. No explicit when-not-to-use, but sibling differentiation is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gstGST CalculatorBAdd or extract GST — India slabs (5/12/18/28), Australia/NZ/Singapore/Canada rates. GST both directions — exclusive to inclusive and back — with the Indian slab structure (5/12/18/28%) and the single-rate systems (Australia 10%, New Zealand 15%, Singapore 9%, Canada 5% federal) built into the rate picker.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Direction | add |
| rate | No | GST rate | 18 |
| amount | No | Amount |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe read-only nature is covered. The description adds context about the built-in rate structures, which is useful. However, it fails to disclose what the tool returns (e.g., just the GST amount or total) and omits the '13%' rate option that appears in the schema.
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 redundant: 'Add or extract GST' and 'GST both directions — exclusive to inclusive and back' say the same thing, and the rate lists are repeated in both sentences. It could be condensed to one sentence without losing information.
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?
The tool is simple with three optional parameters and no output schema. The description explains core behavior and rate options but does not describe the output format or edge cases like the 13% rate. It is adequate but leaves notable 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 basic descriptions for mode, rate, and amount. The description adds meaning by explaining the rate sources (e.g., Australia 10%, India slabs), helping the user pick a rate. Yet it doesn't clarify the '13' rate likely representing Canadian HST, leaving a gap.
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 tool's purpose with a specific verb ('Add or extract GST') and resource (GST), and distinguishes it from siblings by naming the supported rate structures (India slabs, Australia/NZ/Singapore/Canada). The scope is explicit, making it obvious 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like the 'vat' tool. The description only explains what the tool does, not in what circumstances it should be chosen or excluded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
home_affordabilityHome Affordability CalculatorAHow much house you can afford — on the rule your lender actually uses, which differs between the US and the UK. Two countries give entirely different answers on the same income. US lenders underwrite on debt-to-income ratios — 28% of gross income on housing, 36% on all debt — which cap the monthly payment and let the loan fall out of it. UK and Australian lenders cap the loan itself at a multiple of income, around 4.5x, then stress-test the payment at a rate above the one you are quoted. This applies whichever rule is yours, and names the binding limit.
| Name | Required | Description | Default |
|---|---|---|---|
| down | No | Down payment saved | |
| rate | No | Mortgage rate (%) | |
| years | No | Term (yr) | |
| income | No | Gross annual income | |
| method | No | How does your lender decide? US lenders underwrite on two debt-to-income ratios. UK and Australian lenders cap the loan at a multiple of income (about 4.5×) and then stress-test the payment. The two produce materially different answers on the same income. | US |
| monthlyDebts | No | Existing monthly debt payments Car loans, student loans, card minimums — not rent or utilities. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this a safe read operation, and the description adds behavioral context by disclosing the methodology: it computes the binding constraint (payment-cap for US, loan-multiple for UK/AU) and names which limit is binding. This goes beyond the annotation by explaining how the tool arrives at its answer and what it will report.
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 front-loaded with the core question and uses about 100 words to explain the two rules. Each sentence contributes to understanding the tool's logic, but the explanation is somewhat lengthy and could be tightened. It remains appropriately sized for an educational calculator, yet it's not as concise as it could be.
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 no output schema, the description does a good job explaining the tool's return: an affordable house amount and which lending rule is binding. Combined with thorough parameter descriptions, this provides strong contextual coverage. It stops short of describing the exact output format (e.g., whether a breakdown is included), so it's not a 5.
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 descriptions cover 100% of parameters, including a detailed explanation of the 'method' enum. The tool description's discussion of the US/UK rules reinforces the method parameter but does not add new parameter-specific details beyond the schema. With high schema coverage, a baseline of 3 is appropriate.
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 opens with 'How much house you can afford' – a specific, actionable outcome – and then clearly differentiates the tool from sibling calculators by explaining the US debt-to-income rule versus the UK/Australian income-multiple rule. This makes it unambiguous that the tool calculates an affordability limit, not monthly payments or loan terms.
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 provides clear context for when to use the tool by explaining that it applies the lender's actual rule and handles both US and UK/Australian methods. It states 'This applies whichever rule is yours, and names the binding limit,' which implies universal applicability. However, it does not explicitly mention alternative tools or 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.
hong_kong_profits_taxHong Kong Profits Tax CalculatorAHong Kong profits tax at 8.25%/16.5% for corporations or 7.5%/15% for unincorporated businesses, with the connected-entity election. Hong Kong does not simply charge every company 16.5%. An eligible corporation pays 8.25% on the first HK$2 million of assessable profits and 16.5% above; an eligible sole proprietorship or partnership pays 7.5% and 15%. But only one connected entity can elect the two-tiered rates for a year. This calculator makes that hidden eligibility branch explicit and shows the saving against the full rate.
| Name | Required | Description | Default |
|---|---|---|---|
| profit | No | Assessable profits (HKD) Enter Hong Kong assessable profits after allowable deductions. Accounting profit, offshore-source questions and loss carry-forwards must be resolved before this figure. | |
| tiered | No | Can this entity use the two-tiered rates? Only one connected entity may elect the two-tiered rates in the same year. Control generally means more than 50% of capital, voting rights, or entitlement to capital or profits. | yes |
| entityType | No | Entity type | corporation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation by detailing the calculation logic, the connected-entity branch, and that it shows savings against the full rate. It does not contradict the annotations and gives a clear sense of how the tool behaves.
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 five sentences and front-loaded with the key rate information. Most sentences add value, but the second sentence ('Hong Kong does not simply charge every company 16.5%') partially restates the first, making the description slightly longer than necessary. Overall it is well-structured and informative.
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 no output schema, the description gives a reasonable indication of output by stating it 'shows the saving against the full rate.' It covers the key calculation inputs and the connected-entity election context, while the parameter schema handles input semantics. The tool is adequately complete for a calculator.
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?
The input schema already describes all three parameters with 100% coverage, so the baseline is 3. The description reinforces the meaning of the 'tiered' parameter by explaining the two-tiered rates and the connected entity election, but does not add syntax or format details beyond what the schema provides.
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 that this is a Hong Kong profits tax calculator with specific rates for corporations and unincorporated businesses, and it highlights the two-tiered rate system and connected-entity election. This differentiates it from generic income tax calculators and makes the tool's purpose unambiguous.
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 provides strong contextual guidance about when to use the tool by explaining the eligibility nuance for the two-tiered rates and the connected-entity election. However, it does not explicitly name alternative tools or state when not to use this calculator, such as distinguishing it from income_tax_hong_kong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
income_taxIncome Tax Calculator (24 countries)APersonal income tax for 24 countries/jurisdictions using current official progressive brackets: tax owed, effective rate, marginal rate, take-home pay. Countries: usa, uk, china, japan, germany, france, canada, australia, india, taiwan, south-korea, vietnam, thailand, indonesia, malaysia, spain, italy, portugal, brazil, mexico, argentina.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country key | |
| deduction | No | Deductions (optional; defaults to the country's standard deduction/allowance) | |
| annualIncome | Yes | Annual gross income in the country's local currency |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint and openWorldHint annotations by specifying the calculation basis ('current official progressive brackets') and the exact outputs (tax owed, effective rate, marginal rate, take-home pay). It does not contradict annotations. Slight gap: doesn't mention that deductions default to standard, but 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear front-loaded purpose and a country list. The list of 21 countries is useful but could be more compact; however, it's not excessive. The numeric mismatch (24 vs 21) is a minor blemish.
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 calculator tool with only three parameters and no output schema, the description covers the main purpose, outputs, and country scope. It lacks explicit mention of tax year or residency assumptions, but overall it is sufficient for an agent to select and invoke it. The country count inconsistency is the main gap.
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?
All three parameters have schema descriptions covering 100% of the semantics, with the deduction parameter already explaining its default behavior. The tool description adds no additional parameter meaning beyond the schema, so the baseline score of 3 is appropriate.
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 tool calculates personal income tax and lists the countries covered, along with the outputs it produces. However, it claims '24 countries' but the input schema enum contains only 21 countries, creating a minor factual inconsistency that could mislead an agent about coverage. It also does not explicitly differentiate from single-country sibling tools.
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?
No explicit guidance about when to use this tool versus the many country-specific income tax tools (e.g., china_income_tax_salary, income_tax_hong_kong, income_tax_singapore). The description implies usage for the listed countries but does not provide when-not-to-use or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
income_tax_hong_kongHong Kong (HK) Salaries Tax Calculator 2026/27AWhat your Hong Kong salary actually costs you in tax this year, after allowances — and whether the standard rate caps the bill. Hong Kong does not tax salaries with a bracket table. It runs two calculations and charges you the lower one: progressive rates of 2% to 17% on what remains after your allowances, or a flat standard rate on your income before any allowances at all — 15% on the first HK$5,000,000, 16% above it. Which one wins turns entirely on your allowances, so a married taxpayer with children crosses over at a far higher salary than someone single. Most calculators model only the progressive scale, and so does most AI, which is why both overstate the bill for higher earners, sometimes by a lot. This runs both, shows you which one binds and by how much, and takes off the year’s one-off reduction at the end.
| Name | Required | Description | Default |
|---|---|---|---|
| mpf | No | MPF mandatory contributions (HK$) Deductible up to HK$18,000 a year. Employee mandatory contributions only — voluntary ones are not deductible under this cap. | |
| year | No | Year of assessment Allowances rose in 2026/27 (basic HK$132,000 → HK$145,000). The one-off reduction for 2026/27 has not been announced yet, so it is treated as zero until the February 2027 Budget. | 2026/27 |
| income | No | Annual income (HK$) Total assessable income for the year — salary, bonus, commission, and the rental value of any employer-provided housing. | |
| status | No | Assessment basis The decisive input. Joint assessment doubles the basic allowance, which raises the income at which the standard rate takes over — the crossover is net income above 8.5 × allowances + HK$900,000. | single |
| parents | No | Dependent parents/grandparents aged 60+ HK$55,000 each for 2026/27 (HK$50,000 for 2025/26). The 55–59 band is half and is not modelled here. | |
| children | No | Children claimed HK$140,000 each for 2026/27 (HK$130,000 for 2025/26), for up to nine children. The extra year-of-birth allowance is not modelled. | |
| otherDeductions | No | Other deductions (HK$) Self-education (max 100,000), home-loan interest (100,000, or 120,000 with a young child), domestic rent (same), elderly residential care, annuity/TVC (60,000), VHIS. Enter the total. | |
| parentsLiveWith | No | Do those parents live with you? Living with you the whole year doubles the dependent-parent allowance. Easy to miss, and worth HK$55,000 of allowance per parent in 2026/27. | no |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds substantial context: it explains the two calculations, the lower-bill rule, the allowance-dependent crossover, and the treatment of the one-off reduction. This goes well beyond the annotation and helps the agent understand how results are computed, though it does not detail the return format.
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 long but every sentence earns its place: it explains the HK tax system, why mainstream calculators fail, and what the tool outputs. It is well-structured and front-loaded with purpose, though slightly verbose for a simple calculator.
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 a fully documented schema and readOnlyHint annotation, the description covers the tool's logic and key outputs (which method binds, the reduction). It does not specify the exact return object, but for a read-only calculator the explanation is adequate given the complexity.
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?
The input schema has 100% coverage, with each parameter described in detail (caps, exclusions, year-specific values). The tool description itself adds little parameter-specific detail, so the baseline of 3 applies; the schema carries the heavy lifting for parameter semantics.
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 this is a Hong Kong salaries tax calculator, with a specific verb ('costs you') and resource ('your Hong Kong salary'). It distinguishes itself from siblings by emphasizing the unique dual-calculation method (progressive rates vs. standard rate cap), which sets it apart from generic income tax tools or other jurisdictions.
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 implies when to use the tool — for accurate HK salaries tax, especially for higher earners where the standard rate may bind — and contrasts it with other calculators that only model the progressive scale. It does not explicitly name alternative tools or list exclusions, so it is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
income_tax_netherlandsNetherlands Income Tax Calculator (2026)A2026 Dutch Box 1 salary tax after the general tax credit and employment tax credit — the two amounts generic calculators miss. Dutch headline rates are not the final bill. For employees below AOW age, 2026 Box 1 rates include national insurance, then the algemene heffingskorting and arbeidskorting reduce the tax substantially before phasing out as income rises. This salary-only calculator shows the tax before credits, each credit, the final amount, and take-home pay.
| Name | Required | Description | Default |
|---|---|---|---|
| annualIncome | No | Annual gross employment income (EUR) Salary and other employment income used for the arbeidskorting. This model is for someone below AOW age throughout 2026. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, which the description aligns with. Beyond that, it adds valuable context: inclusion of national insurance, the phasing out of credits, and the specific output breakdown (tax before credits, each credit, final amount, take-home pay). It also discloses limitations (only salary, below AOW age).
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 four sentences long, front-loaded with the primary purpose. Each sentence adds distinct information: the core calculation, the reason this tool differs from generic calculators, the specific tax rules, and the expected outputs. It is somewhat detailed but justified for a tax calculator with nuanced logic.
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 single optional parameter, no output schema, and read-only annotation, the description provides sufficient context to understand the tool's scope, inputs, and outputs. It explains the tax year (2026), the tax system (Box 1), eligibility, and the returned values, which is complete enough for an agent to select and invoke it correctly.
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?
The schema already provides 100% coverage with a detailed description of annualIncome (gross employment income, used for arbeidskorting, for those below AOW age). The tool description reinforces the 'salary-only' aspect but does not add significant new parameter semantics beyond the schema, so the baseline of 3 is appropriate.
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 this is a 2026 Dutch Box 1 salary tax calculator that includes the general tax credit and employment tax credit, and outputs tax before credits, each credit, final amount, and take-home pay. It distinguishes itself from generic calculators and sibling tools like netherlands_30_percent_ruling by focusing on salary tax for employees below AOW age.
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 defines the target user (employees below AOW age) and scope (salary-only), and implicitly contrasts with generic calculators that miss the credits. However, it does not name specific alternative tools or provide 'when not to use' beyond the salary/AOW constraints, so it is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
income_tax_singaporeSingapore Income Tax Calculator (YA 2026)AYA 2026 Singapore tax for residents, non-resident employees, and non-resident directors — including personal reliefs. Singapore tax depends first on residency. Residents use progressive rates up to 24% after eligible personal reliefs; non-resident employees pay the higher of 15% of employment income or the resident-rate calculation, while non-resident directors and most other non-resident income are taxed at 24%. This calculator runs the correct branch instead of silently assuming everyone is resident.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Tax status and income type Residents generally include citizens or PRs who reside in Singapore and foreigners meeting an IRAS residence test. The non-resident employee option assumes the employment income is taxable rather than covered by the short-term exemption. | resident |
| reliefs | No | Eligible personal reliefs (SGD) Resident only. Enter the total you qualify for, including earned-income and eligible CPF reliefs. IRAS caps total personal reliefs at S$80,000 per YA. | |
| annualIncome | No | Annual taxable income before reliefs (SGD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses detailed computation rules: residents use progressive rates up to 24% after reliefs, non-resident employees pay the higher of 15% or resident-rate, and other non-residents pay 24%. It also explicitly states that the calculator branches on residency status, adding substantial behavioral context that annotations alone do not provide.
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 exactly three sentences, with no wasteful content. It front-loads the core scope, then efficiently provides the key behavioral rules, and closes with a value-add note about correct branching. Every sentence earns its place.
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's complexity (residency-dependent rates), the description covers the essential calculation rules for all status categories, and the schema covers parameter details. Even without an output schema, the purpose as a calculator makes the return value obvious. The description and structured data together provide a complete picture for an agent to select and invoke the tool correctly.
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?
The schema already covers all three parameters with 100% description coverage, so the baseline is 3. The description adds value by clarifying the nonResidentOther status—specifically mentioning that non-resident directors and most other non-resident income are taxed at 24%—and by explaining how reliefs fit into the resident calculation, adding meaning 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 the tool's specific purpose: 'YA 2026 Singapore tax for residents, non-resident employees, and non-resident directors — including personal reliefs.' This establishes a unique scope (Singapore YA 2026) and distinguishes it from sibling tools like income_tax_hong_kong or generic income_tax. The verb 'calculates' is implied and the resource is precisely defined.
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 provides clear context for when to use the tool: for Singapore income tax calculations with varying residency statuses. It notes that the calculator 'runs the correct branch instead of silently assuming everyone is resident,' implying it's the right choice for non-resident scenarios. However, it doesn't explicitly name alternative tools or state when not to use it, so it falls just 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.
india_gratuityIndia Gratuity Calculator (Labour Codes, from 21 Nov 2025)AStatutory gratuity under the new Labour Codes — the 50% wage floor and the 1-year fixed-term gate that the old answer misses. Computes statutory gratuity under India’s Code on Social Security 2020, in force since 21 Nov 2025 (general AI often still says the Labour Codes are pending). The formula looks unchanged — wages × 15/26 per year of service — but two decisive inputs are hidden: the §2(88) wage definition floors the gratuity base at 50% of total remuneration when basic + DA is kept low (most modern salary structures), and fixed-term employees now qualify after just 1 year instead of 5. Both can turn the “obvious” answer from wrong to right by lakhs.
| Name | Required | Description | Default |
|---|---|---|---|
| basicDA | No | Monthly basic + DA last drawn Basic pay + dearness allowance (+ retaining allowance, if any) in your last drawn month. Gratuity runs on last-drawn wages, not an average. | |
| exitReason | No | Why is employment ending? Death or disablement waives the qualifying-service requirement entirely; the formula is otherwise the same. | service |
| serviceYears | No | Completed years of service Whole completed years of continuous service. Put the leftover months in the next field. | |
| employmentType | No | What kind of employment? This gate is the headline change — fixed-term employees now qualify after just 1 year (pro-rata), and working journalists after 3. Under the old Act the answer for a 2-year fixed-term worker was simply ₹0. | permanent |
| totalRemuneration | No | Total monthly remuneration Everything monthly: basic, DA, HRA, allowances, employer PF contribution, statutory bonus — but not gratuity or ESI (per the MoLE FAQ). The 50% floor: if basic + DA is under half of this, the law adds the excess back. THIS is what most people don’t know. | |
| serviceExtraMonths | No | …plus months Months beyond the completed years. More than 6 months rounds UP to a full extra year (§53(2)); exactly 6 does not. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations (readOnlyHint=true). It details the wage floor calculation, the 1-year gate for fixed-term employees, the rounding rule for months, and the impact of modern salary structures. 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 relatively long but well-structured, starting with the key takeaway about the new law and then elaborating on hidden inputs. Every sentence contributes value, though it could be slightly more concise without losing clarity.
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?
No output schema is provided, and the description does not mention what the tool returns (e.g., total gratuity amount). While the name implies a calculation result, the lack of explicit output description leaves a gap in completeness for an otherwise detailed description.
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 each parameter having a description. The tool description further explains the hidden nuances (e.g., the 50% floor, the effect of employment type) that go beyond the schema, adding substantial value. Baseline 3, adjusted up for extra context.
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 tool computes statutory gratuity under India's Code on Social Security 2020, effective 21 Nov 2025. It uses specific verbs ('computes') and resources ('statutory gratuity'), and distinguishes itself from outdated answers by highlighting the new law and hidden inputs.
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 provides context for when to use the tool: for gratuity calculations under the new Labour Codes, especially emphasizing the 50% wage floor and fixed-term employee qualification. However, it does not explicitly state when not to use it or mention alternative tools (e.g., the old Act, other gratuity calculators).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
japan_childcare_leave_benefitJapan Childcare Leave Benefit Calculator (育児休業給付金 & 出生後休業支援給付金)AYour childcare-leave money under the April-2025 framework: 67% (then 50%) of daily wage, plus the new +13% top-up that lifts the first 28 days to 80% gross — with the exact caps valid 1 Aug 2026 – 31 Jul 2027. Computes Japanese childcare-leave benefits: the base 育児休業給付金 (67% of your daily wage for the first 180 benefit days, 50% after) and the 出生後休業支援給付金 introduced April 2025 — a +13% top-up on up to 28 days that lifts them to 80% gross, roughly 100% of normal net take-home once the tax and social-insurance exemptions are counted. General AI still answers 67% (the top-up postdates most training data) and garbles the condition’s asymmetry: the father’s +13% is satisfied automatically while the employed mother is on 産後休業 — it is the mother’s claim that needs the father to take ≥14 days (or a waiver). Uses the caps valid 1 Aug 2026 – 31 Jul 2027 (¥16,540 daily ceiling; ¥60,205 top-up cap per 28 days); every cap revises each 1 August.
| Name | Required | Description | Default |
|---|---|---|---|
| claimant | No | Who is claiming? The asymmetry general AI misses: a father’s +13% condition is satisfied AUTOMATICALLY while the employed mother is on maternity leave (産後休業 counts as waiver #6) — he only needs his own ≥14 days. The MOTHER’s claim is the one that needs the father to take ≥14 days of leave, unless a waiver applies (spouse not employed / self-employed / single parent). | father |
| leaveDays | No | Leave days to model (days) Total benefit days you plan to take. The 67% rate runs for the first 180 benefit days (the counter includes 産後パパ育休 days), then steps down to 50%. | |
| monthlyWage | No | Average monthly wage before leave (¥/mo) Average of the 6 months of wages before the leave starts — this sets your 賃金日額 (daily wage) = wage × 6 ÷ 180 = wage ÷ 30. Use gross pay including fixed allowances, before tax and social insurance. | |
| bothCondition | No | Is the +13% condition met? The 出生後休業支援給付金 needs your own leave of ≥14 days within the statutory window AND the spouse condition per the claimant note above (a father’s is auto-met while the employed mother is on 産後休業; a mother’s needs the father’s ≥14 days or a waiver). When met, the first 28 days pay 80% gross. | yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is already covered. The description adds valuable behavioral context beyond annotations: that the 'father's +13% is satisfied automatically while the employed mother is on 産後休業' and that caps revise each 1 August — disclosing time-dependency of results. It does not explicitly state the return format (since no output schema exists), but the calculation logic substitution is transparent.
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 information-dense and front-loaded with the core calculation, but it runs long — roughly six sentences spanning several clauses about caps, the top-up, and the asymmetry trap. While every sentence earns its place (no filler), the density makes it a heavy read. The structure is effective but could be tightened by splitting the statutory/calculation facts from the 'general AI gets this wrong' guidance.
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 complex four-parameter calculation tool with 100% schema coverage, no output schema, and an obscure legal framework, the description is exceptionally complete. It covers the rate structure, the new 2025 top-up, exact cap figures with validity dates, the tax/social-insurance exemption nuance, the asymmetry trap, and the annual cap revision warning. The writeup leaves no meaningful gap a user would need clarified about the model's inputs or mechanics.
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 the baseline is 3. The description and the scheme both carry detailed param semantics — particularly for 'claimant' and 'bothCondition', where the description explains the legal asymmetry (father auto-met, mother needs father's ≥14 days) beyond the enum values. The description also clarifies what daily wage = wage ÷ 30 for monthlyWage. It adds substantive meaning beyond the schema for the tricky condition parameter.
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 opens with a clear, specific statement of what the tool computes: the 育児休業給付金 (67%/50% base) and the new 出生後休業支援給付金 (+13% top-up to 80% gross). It names the exact statutory framework (April-2025) and caps validity window (1 Aug 2026 – 31 Jul 2027), establishing a specific verb+resource+scope. Among 70+ sibling tools, it is unambiguous — no other tool addresses Japanese childcare leave benefits.
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 warns that 'general AI still answers 67%' and explains that the top-up postdates most training data, telling the agent when this specialized tool is needed over general model knowledge. It also flags the asymmetry condition that general AI 'garbles' — a clear when-to-use signal that this tool handles a trap, distinguishing it from what the model might default to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
korea_parental_leave_benefitKorea Parental Leave Benefit Calculator (육아휴직급여, 2025 reform + 6+6)AYour monthly 육아휴직급여 under the 2025 reform — 100%/100%/80% with caps ₩2.5M/₩2.0M/₩1.6M, the 6+6 ladder to ₩4.5M, and the 25% withholding that no longer exists. Computes South Korean parental-leave benefit (육아휴직급여) under the rules in force since 1 January 2025: months 1–3 at 100% of ordinary wage capped ₩2,500,000, months 4–6 at 100% capped ₩2,000,000, months 7+ at 80% capped ₩1,600,000 — paid in full every month, because the 25% withheld-until-return (사후지급금) is abolished. When BOTH parents take leave for a child under 18 months, months 1–6 switch to the 6+6 scheme’s escalating 100% caps of ₩2.5M/₩2.5M/₩3.0M/₩3.5M/₩4.0M/₩4.5M per parent (the ladder ends at ₩4.5M — a ₩5.0M figure circulates and is wrong). Single parents get months 1–3 at 100% capped ₩3,000,000. General AI still describes the pre-2025 system (80% flat, ₩1.5M cap, 25% withheld) — all three facts are dead.
| Name | Required | Description | Default |
|---|---|---|---|
| months | No | Months of leave to model (mo) Standard entitlement is 12 months per parent. It extends to 18 months when both parents each take at least 3 months, for single parents, or for a child with a severe disability. | |
| scheme | No | Which scheme applies? The decisive input nobody volunteers: whether BOTH parents take leave (simultaneously or one after the other) for a child under 18 months. If yes, months 1–6 flip to the 6+6 scheme’s escalating 100% caps — up to ₩4.5M/month per parent instead of ₩2.5M/₩2.0M. | general |
| monthlyWage | No | Ordinary monthly wage (통상임금) (₩/mo) Your 통상임금 — the ordinary wage the benefit is computed on (base pay plus fixed regular allowances), not total compensation with variable bonuses and overtime. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description details the calculation logic, caps, abolished withholding, and special rules for single parents and dual leave. No contradictory or missing behavioral traits.
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 detailed but each sentence adds necessary context for a complex benefit. It is front-loaded with the key formula and well-structured. Could be slightly more concise but not wasteful.
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's three parameters and no output schema, the description covers all schemes, edge cases (single parent, dual leave), and warns of common misconceptions. The only minor gap is the exact return format (single value or per month).
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% and each parameter has a description. The tool description adds significant value by clarifying the meaning of ordinary wage (통상임금) and explaining the scheme parameter's real-world significance, going beyond the 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?
The description explicitly states it computes South Korean parental-leave benefit under 2025 rules, including specific caps and schemes. It distinguishes from sibling tools by naming the specific country and reform, and warns against outdated general AI descriptions.
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 provides clear context for when to use each scheme (general, 6+6, singleParent) and highlights the decisive input for the scheme parameter. It does not explicitly compare to alternative tools but the sibling set makes the domain clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
loan_paymentLoan PaymentAMonthly payment, total interest, and what paying extra saves. Standard amortized loan math: monthly payment, total cost, interest as a share of principal — plus a concrete extra-payment scenario showing time and interest saved.
| Name | Required | Description | Default |
|---|---|---|---|
| rate | No | Annual interest rate (%) | |
| years | No | Term (yr) | |
| amount | No | Loan amount |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false. The description adds value by detailing the computations: monthly payment, total cost, interest share, and extra-payment scenario. 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 efficiently convey the core outputs and computation scope. No redundant or filler content.
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 no output schema, the description explains return values (monthly payment, total interest, etc.) and the extra-payment scenario. Could be slightly more specific about scenario details, but adequate.
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?
All three parameters are fully described in the schema (100% coverage). The description does not add parameter-specific meaning beyond contextualizing the calculation, so baseline 3 is appropriate.
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 tool calculates monthly payment, total interest, and extra payment savings. However, it does not explicitly differentiate from sibling tools like mortgage or car_loan, which reduces clarity.
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?
No guidance on when to use this tool versus alternatives (e.g., for extra payment analysis vs. standard amortization). No exclusion criteria or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_sizeMarket Size (TAM · SAM · SOM)ABottom-up market sizing with a built-in plausibility check. Builds TAM, SAM, and SOM bottom-up from customer count and revenue per account, then sanity-checks whether the implied customer acquisition is actually plausible — the check most pitch decks skip.
| Name | Required | Description | Default |
|---|---|---|---|
| arpa | No | Annual revenue per customer | |
| samPct | No | Serviceable share (%) Share you can actually reach: your segment, geography, language, channel. | |
| somPct | No | Obtainable share of SAM (%) Realistic share you win in ~3–5 years given competition. | |
| accounts | No | Potential customers in market Total count of businesses/people who could conceivably buy this category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description's extra detail about the plausibility check adds value without contradiction. It does not mention auth needs or side effects, but the read-only nature is clear.
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 two sentences with no wasted words. It front-loads the core purpose and adds a unique selling point (plausibility check) efficiently.
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?
The description covers the key functionality and the unique plausibility check. However, without an output schema, it does not describe the return format or structure, which is a minor gap for a calculation tool.
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 all parameters. The description adds a high-level summary ('customer count and revenue per account') but does not provide additional details beyond the schema, meeting the baseline.
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 tool does bottom-up market sizing (TAM, SAM, SOM) with a built-in plausibility check. It uses specific verbs like 'Builds' and 'sanity-checks', and is clearly distinct from sibling financial calculators.
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 implies use when performing market sizing, but does not explicitly state when not to use it or suggest alternatives. However, given the sibling tool list, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mexico_vacaciones_aguinaldoMexico Vacation Days, Prima Vacacional & Aguinaldo (Vacaciones Dignas)AYour legal vacation days under the 2023 Vacaciones Dignas reform, plus the prima vacacional and year-end aguinaldo in pesos. Computes your statutory vacation days under Mexico’s Vacaciones Dignas reform (LFT Art. 76, in force 1 Jan 2023), the 25% prima vacacional (Art. 80), and the 15-day aguinaldo due by 20 December (Art. 87), pro-rated for partial years. The internet — and AI trained on it — is saturated with the pre-2023 table that gave just 6 days in year one; the reform doubled that to 12 and re-banded the rest, and the +2-days-per-five-years banding after year 5 is precisely where models and stale HR pages still get it wrong. All amounts use your base salary: the SDI (integrated wage) is for IMSS only, and using it here double-counts the benefits being calculated.
| Name | Required | Description | Default |
|---|---|---|---|
| serviceYears | No | Completed years of service Count FULL years only — vacation entitlement vests on completing each year of service (2 years 8 months = 2). Enter 0 if you have not yet completed your first year. | |
| monthlySalary | No | Monthly base salary (MX$) Your base salary (cuota diaria = monthly ÷ 30) — NOT the SDI. The integrated wage (salario diario integrado) is for IMSS contributions only; using it here double-counts the very benefits being calculated. | |
| daysWorkedThisYear | No | Days worked this calendar year For the aguinaldo pro-rata: worked less than the full year (started mid-year, leaving early) and the 15 days scale by days worked ÷ 365. Leave 365 for a full year. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, consistent with a calculator. The description adds transparency about pro-rata calculations, the reform effective date, and the danger of using outdated data. 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 moderately concise but includes necessary legal references and warnings. It could be slightly tighter (e.g., removing the final sentence about SDI double-counting) without losing critical information.
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?
The description explains inputs and purpose well but does not explicitly describe the output format (e.g., whether results are separate values or combined). Since no output schema exists, this gap reduces completeness for an agent.
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 meaningful context: for serviceYears it clarifies counting full years only; for monthlySalary it warns against using SDI; for daysWorkedThisYear it explains pro-rata logic. This adds value beyond the schema 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 the tool computes vacation days, prima vacacional, and aguinaldo under the 2023 Vacaciones Dignas reform. It specifies the relevant LFT articles and distinguishes from outdated pre-2023 tables, making the purpose very specific and unambiguous.
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 provides clear context for use: Mexican statutory benefits with reform details, and warns against using SDI base salary. However, it does not explicitly state when not to use this tool (e.g., for other countries) or mention alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mortgageMortgage CalculatorATrue monthly cost — principal & interest plus taxes, insurance, and PMI, not just the loan. Monthly mortgage payment from price, down payment, rate, and term — including the parts lender ads leave out: property tax, home insurance, and PMI when the down payment is under 20%. The headline number here is the full PITI cost of owning.
| Name | Required | Description | Default |
|---|---|---|---|
| rate | No | Interest rate (%) | |
| price | No | Home price | |
| years | No | Term (yr) | |
| market | No | Where are you buying? Private mortgage insurance is a US product. Most other markets price the same lender risk into the interest rate instead, so no separate PMI line is charged. | US |
| downPct | No | Down payment (%) | |
| insurance | No | Home insurance / year | |
| propertyTax | No | Property tax / year |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the safety profile is clear. The description adds valuable behavioral context: specifies that PMI is included only when the down payment is under 20%, and clarifies that the result is a 'headline number' for full PITI. This goes beyond the annotations and gives the agent a solid understanding of the tool's behavior.
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 three sentences and front-loaded with the core value proposition. It is somewhat wordy with phrases like 'lender ads leave out,' but every sentence contributes to understanding the tool's scope and output. It is not excessively long and remains readable.
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 7 parameters and no output schema, the description adequately explains the main functionality and the components included in the computation. It could be more explicit about the exact return format (e.g., monthly payment number vs. breakdown), but the phrase 'headline number' gives a sufficient sense. Overall, it is complete for a calculator tool with well-documented parameters.
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%, with all 7 parameters already documented. The description adds some context (e.g., PMI condition tied to down payment) but does not significantly expand on the schema's parameter documentation. Baseline score of 3 is appropriate when the schema carries the load.
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 tool computes the true monthly mortgage cost, including principal, interest, taxes, insurance, and PMI. It explicitly distinguishes itself from a simple loan payment by saying 'not just the loan' and emphasizing the full PITI cost, which differentiates it from sibling tools like loan_payment.
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 implies when to use this tool: when you want the full cost of owning rather than just the loan payment. It contrasts with lender ads that omit taxes, insurance, and PMI, giving clear context. However, it does not explicitly name alternative tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
netherlands_30_percent_rulingNetherlands 30% Ruling Calculator — 2027 changesAWhether you qualify for the Dutch 30% ruling, how much of your salary comes tax-free, and what changes when it drops to 27%. Whether the Dutch 30% ruling is worth 30% to you or 27% depends on one thing: the year it was first granted. Granted in 2023 or earlier and it stays at 30%, on the old salary threshold, for its whole term. Granted in 2024 and it falls to 27% in 2027 but keeps that old threshold. Granted from 2025 and it is 27% on the higher threshold from the start. General-purpose AI collapses all of this into “it’s 30%” or “it’s being scrapped”, and for most people both are wrong. The questions that actually decide it are narrow — when your ruling started, whether you lived more than 150km from the Dutch border before you moved, and how many months you had already spent in the country — and this asks them, then works out what comes to you tax-free.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Computation year The rate (30% → 27%) and the salary norms change at the 2026/2027 boundary — differently per cohort. | 2026 |
| cohort | No | When was (will) your 30% ruling first granted? The decisive input. The 2027 transition is THREE cohorts, not two: 2023-and-earlier keep 30% AND the old salary norm for their full term; 2024 starters drop to 27% in 2027 but KEEP the old norm; 2025-and-later starters get 27% AND the higher norm from 2027. | new |
| salary | No | Annual gross salary (total compensation) (€) Your total agreed gross pay, before the tax-free allowance is carved out of it. The salary norm tests what remains TAXABLE after the allowance — the tool handles that split. | |
| distanceOk | No | Lived >150km from the Dutch border before starting? A hard eligibility gate: you must have lived more than 150km from the Dutch border for more than 16 of the 24 months before your Dutch employment began. This excludes Belgium, Luxembourg, and border regions of Germany. | yes |
| priorNlMonths | No | Months lived or worked in NL in the past 25 years (mo) Earlier stays in the Netherlands within the last 25 years are deducted from the 60-month maximum duration. | |
| under30Masters | No | Under 30 with a (Dutch-equivalent) master’s degree? A lower salary norm applies (€36,497 vs €48,013 in 2026) — but only until the month you turn 30. | no |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's job is to add context. It does so by explaining the cohort-dependent logic, the decisive questions (start date, distance, prior months), and the output ('what comes to you tax-free'). This adds value beyond the read-only hint without contradicting it.
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, lengthy paragraph with useful information, but it includes a meta-commentary about general-purpose AI that is not strictly necessary for tool invocation. It is front-loaded with the core purpose and structured logically, but could be more concise without losing value.
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 complex calculator with 6 parameters and no output schema, the description does a good job of explaining the tool's scope, the 2027 changes, and the decisive inputs. It implies the output (qualification and tax-free amount) even if it doesn't detail the exact return structure. The read-only annotation and thorough schema help complete the picture.
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% with very detailed parameter descriptions. The tool description adds a narrative that highlights the key inputs (cohort, distance, prior months) but does not provide additional syntax or format details beyond what the schema already offers. This aligns with the baseline of 3 for full schema coverage.
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 explicitly states the tool's purpose: determining qualification for the Dutch 30% ruling, the tax-free portion of salary, and the impact of the 2027 rate drop. It distinguishes itself from sibling tools by focusing on the specific 30% ruling and its cohort-based 2027 changes, using specific verbs like 'qualify' and 'works out'.
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 provides clear context for when to use the tool, emphasizing the nuanced cohort rules and warning that general-purpose AI often gets it wrong. However, it lacks explicit exclusions or alternative tool references, relying on the reader to infer this is the dedicated tool for this calculation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
npv_irrNPV & IRRAIs this investment worth it — discounted, not vibes. Net present value, internal rate of return, payback period, and profitability index for a series of cashflows — the standard capital-budgeting toolkit, with the IRR pitfalls flagged instead of hidden.
| Name | Required | Description | Default |
|---|---|---|---|
| rate | No | Discount rate (%) Your hurdle rate / cost of capital. | |
| cashflows | No | Cashflows by year Year 0 first (usually negative), then one value per year. Comma-separated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation by stating IRR pitfalls are flagged, which is a specific output behavior. 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 two sentences, front-loading the core question and efficiently listing outputs with no wasted 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?
The description lists outputs but lacks details on return format or structure, which is significant given no output schema. It provides enough to understand what metrics are returned but not how they are presented.
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%, and the description does not add new information about parameters beyond what the schema provides, resulting in a baseline score.
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 computes NPV, IRR, payback period, and profitability index for cashflows, distinguishing it from simpler tools like 'roi' by mentioning a comprehensive toolkit and flags for IRR pitfalls.
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?
While it frames itself as the standard capital-budgeting toolkit, it does not explicitly guide the agent on when to use this tool over siblings like 'roi' or 'break_even'. The guidance is implied but not directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ny_statutory_residence_checkerNew York Statutory Residence Checker (183-Day + Abode Test)AWhether New York can tax you as a resident under the two-prong statutory test — the abode gate people miss, plus the 183-day count where any part of a day counts. For taxpayers NOT domiciled in New York: applies the deterministic statutory-residence test of NY Tax Law §605(b)(1)(B) — a permanent place of abode maintained for substantially all of the year AND more than 183 days of presence — plus the separate New York City test. General AI compresses this to "183 days = resident" and misses both gates: without a permanent place of abode, 300 days in NY doesn't make you a statutory resident, and with one, day 184 does — where a 20-minute stop in the state counts as a full day. Domicile (whether New York is your true home) is a separate facts-and-circumstances battle this tool does not decide.
| Name | Required | Description | Default |
|---|---|---|---|
| abode | No | Do you maintain a dwelling in New York? The trap: people count days but don't know that a NYC crash pad, a company apartment principally available to you, or even a sublet counts as a "permanent place of abode". Vacation homes are generally not one (Obus, 2022); undergraduate apartments are disregarded by policy. | none |
| daysNY | No | Days with any presence in New York State Any part of a day = a full day. Only two exceptions: pure travel-through (boarding a flight or train out, driving through) and inpatient medical confinement. Outpatient visits and "just dinner in the city" days COUNT. | |
| daysNYC | No | Of those, days with any presence in the five boroughs For the separate New York City resident test. Leave 0 if NYC doesn't apply to you. | |
| abodeInNYC | No | Is the dwelling in New York City? Drives the separate city test. NYC levies its own resident income tax on top of the state's. | no |
| abodeMonths | No | Months of the year the dwelling was maintained "Substantially all of the year" means MORE than 10 months (Audit Division policy for tax years 2022+; it was 11 before). This matters mainly in years you acquire or dispose of the home — renting it out briefly mid-ownership does NOT break continuity. | |
| armedForces | No | Active-duty US armed forces? Active-duty members of the US armed forces are statutorily excluded from the day-count prong. | no |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite 'readOnlyHint: true' annotations, the description adds extensive behavioral details: any part of a day counts, exceptions (travel-through, inpatient), vacation homes generally not abode, undergraduate apartments disregarded, and the NYC test. No contradiction; adds value beyond 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 front-loaded with the key insight about the abode gate, but it is quite long (several paragraphs). While every sentence adds value, it could be slightly tighter. Still well-structured with clear paragraphs.
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 statutory residence (6 parameters, legal nuances, no output schema), the description covers all critical details: the two-prong test, day-counting exceptions, abode definition, NYC separate test, and armed forces exclusion. No gaps for a taxpayer determining residency.
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 detailed enum descriptions. The description adds substantial meaning: 'abode' explains trap (crash pad counts), 'daysNY' clarifies exceptions, 'daysNYC' mentions NYC tax, 'abodeMonths' defines 'substantially all' (>10 months). Adds real semantic value beyond enum labels.
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 checks New York statutory residence under the two-prong test (abode + 183 days) for non-domiciled taxpayers, and distinguishes it from domicile. It also notes common AI compression errors, making the purpose specific and distinct from sibling tools like 'us_substantial_presence_test'.
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 it applies to taxpayers NOT domiciled in New York, explains the two gates (abode and days), warns that '183 days = resident' is incomplete, and separates the NYC test. It implicitly tells when not to use (if domiciled) and provides alternatives in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
portugal_ifici_nhr_checkerPortugal IFICI ("NHR 2.0") Eligibility CheckerAWhether you qualify for Portugal’s IFICI — the activity-gated successor to the NHR regime that closed in 2024. Checks your eligibility for Portugal’s IFICI (Incentivo Fiscal à Investigação Científica e Inovação, widely called "NHR 2.0"): 20% flat tax on eligible-activity Portuguese income for 10 years, with most foreign income exempt. The old NHR closed to new entrants on 1 Jan 2024, yet general AI still tells people to "apply for NHR" and quotes its 10% foreign-pension rate — gone: IFICI taxes foreign pensions at full progressive rates. The real gate is an activity test across six routes with route-specific certifying entities (FCT, AT, ANI, Startup Portugal, AICEP) — this tool walks the gates in order and names the route, the certifier, and the registration deadline.
| Name | Required | Description | Default |
|---|---|---|---|
| activity | No | Which eligible activity fits you? THE gate. IFICI is not a general expat regime — your work must fit one of these routes, each certified by a different entity. Annex-I professions include directors, physical-science/engineering specialists, doctors, university professors, and ICT specialists. | qualifiedProfession |
| ptIncome | No | Expected annual PT income from the eligible activity (€) Employment or self-employment income from the eligible activity, per year — the income the 20% flat rate would apply to. | |
| formerRegime | No | Did you ever benefit from the old NHR or the Programa Regressar? Either one bars you from IFICI. If your old NHR 10-year term is still running you keep it under the old rules — you just cannot switch to IFICI. | none |
| qualification | No | Your qualification (Annex-I profession route only) Only matters for the Annex-I highly-qualified-profession route; ignored for every other route. That route requires a PhD, or a Bachelor-level degree plus at least 3 years of proven experience. | bachelorPlus3 |
| foreignPension | No | Will you draw a foreign pension? e.g. a company or state pension from your home country. The single biggest NHR-vs-IFICI difference: the old NHR taxed these at 10%; IFICI taxes them at full progressive rates. | no |
| priorPtResident | No | Were you a Portuguese tax resident in ANY of the 5 years before arrival? A hard gate: IFICI is only for people becoming PT tax resident who were NOT resident in any of the previous 5 years. "Yes" ends the analysis regardless of your activity. | no |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; description consistent as a checker that walks through gates without modifying data. No contradiction. Description adds behavioral context beyond annotations by explaining the gate-based logic and certifying entities.
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 thorough but slightly verbose; every sentence adds value, but could be tightened slightly. Front-loaded with the core question. Good structure with explanatory details and warnings. 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?
Given tool complexity (6 parameters, multiple routes, certifiers), the description fully explains the eligibility logic, parameter roles, and common pitfalls. No output schema but tool's purpose (elicitation of qualification) is clear. All aspects covered for agent to correctly select and invoke.
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 detailed parameter descriptions. Tool description adds extra meaning by explaining the 'gate' concept, interaction between parameters (e.g., qualification only matters for Annex-I route), and specific scenarios (foreign pension vs old NHR). Adds significant value 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 it checks eligibility for Portugal's IFICI regime, distinguishes from general 'NHR checkers' by specifying it's activity-gated. The verb 'checks your eligibility' and specific resource 'IFICI (NHR 2.0)' make purpose unambiguous.
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?
Description explicitly says when to use (to check IFICI eligibility), warns about common misconceptions (old NHR closed, foreign pension tax), and explains the activity test structure. It provides clear context for using this tool vs alternative regimes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
price_in_hoursPrice in Work HoursAWhat a price really costs you: hours of your own work, at your take-home pay. Converts any price — a purchase or a subscription — into the hours and workdays of your own labor it consumes, using take-home pay rather than gross (you buy things with net money). For recurring costs it adds the yearly bill, the share of your working year, and what the same money becomes if invested instead. Time is the one budget everyone understands.
| Name | Required | Description | Default |
|---|---|---|---|
| pay | No | Pay (gross) Hourly rate or annual salary, before tax — the next field nets it down. | |
| price | No | Price | |
| cadence | No | How often | once |
| payMode | No | You earn | hourly |
| takeHomePct | No | Take-home share (%) The share of gross you actually keep after tax and contributions. Typical full-time range: 65–85%. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, which matches. Description adds behavioral details: conversion method (take-home pay), handling of recurring costs (yearly bill, working year share, investment alternative). These go beyond 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?
Description is a single paragraph that is well-structured and front-loaded with the core idea. Every sentence adds value without being overly verbose.
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?
Despite no output schema, description explains what is returned (hours, workdays, and for recurring costs: yearly bill, working year share, investment alternative). All required input parameters are documented in schema, making the tool complete for its purpose.
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 description does not need to add parameter details. It provides overall context but no parameter-specific explanations. Baseline 3 is appropriate.
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 what the tool does: converts price into hours and workdays of labor using take-home pay. It is distinct from sibling tools, which are other financial calculators, and provides a unique value proposition.
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?
Description implies usage context (any price, especially subscriptions) but does not explicitly state when to use vs. alternatives or when not to use. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pricing_marginPricing & MarginAMargin vs markup, and what a discount really costs in volume. Computes gross margin and markup from cost and price — two numbers people constantly confuse — and shows the brutal volume math behind discounting at your margin.
| Name | Required | Description | Default |
|---|---|---|---|
| cost | No | Unit cost | |
| price | No | Selling price | |
| discount | No | Planned discount (%) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description adds context about computing margin, markup, and volume math. It does not contradict annotations and provides useful behavioral detail beyond the read-only hint.
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 two sentences, front-loaded with a catchy title-like phrase, then concise functional details. No wasted 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?
For a simple calculation tool with read-only hints and no output schema, the description covers the main outputs (margin, markup, discount volume impact). It could be slightly more explicit about the return format, but it is adequate given the tool's simplicity.
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 descriptions cover all three parameters (cost, price, discount) with basic names. The description adds meaning by explaining how cost and price are used for margin/markup and discount for volume math, thus adding value beyond the 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?
The description clearly states the tool computes gross margin and markup from cost and price, and additionally shows the volume impact of discounting. It distinguishes itself from sibling tools like break_even or unit_economics by focusing specifically on margin vs markup and discount math.
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 implies usage for margin/markup calculations and discount analysis, but does not explicitly exclude alternatives or provide when-not-to-use guidance. Given the context of many sibling financial tools, some exclusion would be helpful but the current clarity is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quit_runwayQuit Runway (Can I Afford to Leave?)AHow long your savings last after leaving a job — and whether new income overtakes costs before they run out. The personal version of a startup runway: savings, a quit-mode budget, the costs your employer was quietly covering (health insurance above all), and the income you’d be growing instead. Answers the two questions that matter: how many months you have, and whether the new income crosses your costs before month zero.
| Name | Required | Description | Default |
|---|---|---|---|
| savings | No | Savings you can spend Liquid only — not retirement accounts you’d pay penalties to touch. | |
| growthPct | No | That income’s growth / month (%) How fast the new thing is growing, from evidence so far. 0 = flat. | |
| essentials | No | Essential monthly spending The quit-mode budget, not your current lifestyle. | |
| extraCosts | No | New costs after quitting What the job was covering: health insurance (US COBRA/marketplace often $400–800/person), phone, equipment. | |
| sideIncome | No | Monthly income that continues Freelance, side project, partner contribution to your share — income that survives the quit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, no destructive behavior. The description adds value by explaining the simulation nature and the core logic (savings vs. expenses, income growth). It does not contradict 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 well-structured and front-loaded with the key purpose. It uses two concise paragraphs without redundancy. Slightly more brevity could enhance it, but it remains clear and 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?
The description answers the two main output questions (months until depletion and whether income crosses costs before depletion). With no output schema, this provides sufficient context for an agent to understand return values.
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% with detailed parameter descriptions. The main description does not add further parameter-specific meaning beyond what the schema provides, so baseline 3 is appropriate.
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 explicitly states the tool calculates how long savings last after quitting, answering two specific questions. The title reinforces this with a user-oriented framing. It distinguishes from the sibling 'runway' tool by focusing on personal finances rather than business runway.
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 clearly indicates when to use: when considering quitting a job to assess savings runway. It doesn't explicitly state when not to use or compare with alternatives like 'runway' or other financial tools, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
roiROI CalculatorAReturn on investment, simple and annualized — comparable numbers instead of raw bragging. Simple ROI from cost and final value, annualized when you give it a time period — because "we doubled our money" means something completely different over 2 years versus 12.
| Name | Required | Description | Default |
|---|---|---|---|
| cost | No | Total invested | |
| years | No | Holding period (yr) | |
| finalValue | No | Final value (or total returned) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining the conditional behavior: simple ROI when no years, annualized when years provided. Annotations only indicate readOnlyHint=true, so the description adds valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with the main purpose. Every sentence adds value and is 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?
The description is complete for a simple calculator: explains what it calculates and the two modes. However, without an output schema, it could mention the result format or units to be fully comprehensive.
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?
All three parameters have descriptions in the input schema, so the bar is at baseline 3. The description adds minimal extra context about the role of 'years' in determining simple vs annualized, but does not significantly enhance 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 it calculates simple and annualized ROI, and distinguishes between them based on time period. However, it does not explicitly differentiate from the similar sibling tool 'cagr', which also calculates annualized returns.
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 explains the benefit of comparable numbers and gives a relatable example of why time matters, implying when to use it. But it lacks explicit guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
runwayRunway & BurnAHow many months of cash remain, and when to start raising. Computes runway from cash and net burn, optionally with burn trending up or down monthly, and reads the result against fundraising realities: raises take 3–6 months, and 18–24 months post-raise is the norm.
| Name | Required | Description | Default |
|---|---|---|---|
| burn | No | Net monthly burn Expenses minus revenue. Use the average of the last 3 months. | |
| cash | No | Cash in bank | |
| burnChange | No | Burn change / month (%) Positive if burn is growing (hiring), negative if revenue is catching up. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately reflects the read-only nature (readOnlyHint: true) by stating it 'computes' and 'reads' results. It adds behavioral context like burn trending and fundraising realities. 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 two sentences, highly concise, and front-loaded with the primary purpose. Every word contributes meaning.
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 simple tool with no output schema, the description adequately explains the return concept (months of cash, when to raise). It could be improved by specifying output format, but it is sufficient given tool complexity.
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?
Parameter descriptions in the schema are detailed (100% coverage). The tool description adds minimal new semantic information beyond summarizing the parameters' role in the overall calculation. Baseline of 3 is appropriate.
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 tool computes runway from cash and burn, and reads results against fundraising timelines. It uses specific verbs ('computes', 'reads') and resources ('months of cash', 'raise time'), and distinguishes itself from siblings like 'quit_runway' by focusing on startup fundraising.
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 provides context on when to use it (runway calculation with fundraising benchmarks) but does not explicitly exclude alternatives or mention when not to use it. The fundraising timeline provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
saudi_end_of_serviceSaudi Arabia End-of-Service Award (EOSB) CalculatorAYour end-of-service award under Saudi Labor Law Arts. 84–87 — the resignation ladder and the wage base, done right for KSA (not the UAE). Computes the end-of-service award (EOSB, مكافأة نهاية الخدمة) under Saudi Labor Law: the Art. 84 base (half a month per year for the first five years, a full month per year after, on the LAST actual wage), then the branch the termination reason selects — full award for employer-side endings, the Art. 85 ladder (0 / 1/3 / 2/3 / full at exactly 2, 5, and 10 years) for resignation, and ZERO for an Art. 80 misconduct dismissal. General AI reliably gets this wrong by porting UAE rules into KSA: the UAE abolished resignation reductions and uses basic-only wage; Saudi kept the ladder and uses the actual wage including allowances.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | How is employment ending? The decisive input. The reason flips the answer between 0× and 1× of the same formula — the input models never ask for. Ordinary resignation is cut by the Art. 85 ladder; an Art. 80 dismissal pays nothing at all. | employerTermination |
| monthlyWage | No | Last monthly wage (actual wage, SAR) (SAR) Your LAST monthly actual wage: basic + housing + transport + fixed allowances. The Saudi base is the gross wage, NOT basic-only (that is the UAE rule). Contracts may exclude fluctuating commissions per Art. 86 — commission earners should use the last-12-months average of the commission part. | |
| serviceYears | No | Years of service Total continuous service in years — decimals are fine, pro-rata applies to fractions of a year in both tiers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint: true, confirming safe read operation. The description goes beyond by detailing the calculation logic, including the Art. 85 ladder for resignation, zero for Art. 80 dismissal, and the wage base using actual wage including allowances. It also mentions handling of fluctuating commissions per Art. 86. This provides comprehensive behavioral insight.
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 verbose with legal citations and redundancy ('done right for KSA (not the UAE)'). While structured and front-loaded, it could be more concise without losing critical information. Every sentence adds value, but length is above optimal.
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's complexity and no output schema, the description covers the formula, variants by reason, wage base definition, and common pitfalls. It is nearly complete; missing explicit mention of return value format but implied. Adequate for agent use.
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 significant meaning: 'reason' enum is explained with legal context, 'monthlyWage' clarifies it is gross wage not basic-only (UAE rule), and 'serviceYears' notes pro-rata treatment. This adds substantial value beyond the 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?
The description clearly states the tool computes the end-of-service award under Saudi Labor Law, specifying articles 84-87. It distinguishes from UAE rules, relevant given sibling tools like uae_gratuity. The verb 'computes' and resource 'end-of-service award' are specific and unambiguous.
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 explains when to use the tool (KSA calculations) and warns against porting UAE rules. It implies alternatives by referencing UAE but does not explicitly name sibling tools like uae_gratuity. The 'reason' parameter usage is clarified. Overall clear guidance on context but lacks explicit exclusion of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
savings_goalSavings GoalAThe monthly saving needed to hit a target by a deadline. Given a target amount, what you already have, a time horizon, and an expected return, computes the required monthly contribution — and shows what waiting a year would cost you.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | Target amount | |
| rate | No | Annual return (%) Use a conservative rate for short horizons. | |
| years | No | Years to goal (yr) | |
| current | No | Already saved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating no side effects. The description adds that the tool 'computes the required monthly contribution — and shows what waiting a year would cost you', which reveals key output features without contradictions.
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, informative sentence that efficiently conveys purpose and a notable output feature. It is concise without sacrificing clarity, though could be broken into two sentences for readability.
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 full schema coverage and no output schema, the description adequately explains the computation and highlights the 'cost of waiting' feature. It provides sufficient context for an agent to understand the tool's function, but lacks return format details.
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 the description adds minimal new semantics. The description paraphrases schema fields (target amount, already saved, time horizon, expected return) but does not provide additional constraints or 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 the tool's purpose: computing the required monthly saving to reach a financial goal given target, current savings, time horizon, and expected return. It specifically distinguishes from common sibling tools like 'loan_payment' or 'mortgage' which serve different calculations.
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 implies usage for financial goal planning but does not explicitly state when to use this tool versus alternatives such as 'fire_number' or 'compound_growth'. No direct comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
singapore_platform_worker_cpfSingapore Platform Worker CPF Calculator (Platform Workers Act)AYour monthly CPF deduction and operator top-up as a ride-hail or delivery platform worker — by birth cohort, vehicle, and the 2025–2029 rate ramp. Computes platform-worker CPF under Singapore’s Platform Workers Act (in force 1 Jan 2025) — a regime new enough that general AI either doesn’t know it or garbles it. Three inputs users never think to volunteer decide everything: your BIRTH DATE (born on/after 1 Jan 1995 → increased contributions are mandatory; born before → voluntary via an irrevocable opt-in, otherwise MediSave-only), your VEHICLE (the 60/35/20% fixed expense deduction moves the CPF base by 3× for the same gross), and the YEAR (rates ramp every January to full employee parity in 2029). It also gets right what models confidently invert: no monthly ceiling — unlike employees — but a $102,000/year net-earnings cap per platform operator.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Age Sets the rate band: 35 & below, >35–45, >45–50, >50–55, >55–60, >60–65, >65–70, >70. Each band has its own worker/operator split. | |
| year | No | Contribution year Rates ramp every January until full employee parity in 2029. 2027+ figures for ages 55–70 are subject to the senior-worker contribution schedule. | 2026 |
| optedIn | No | Born before 1995 — have you opted in? Only matters if you were born before 1 Jan 1995. The opt-in is irreversible — once made, you are treated exactly like the mandatory cohort (worker share + operator share), forever. | no |
| vehicle | No | How do you work? CPF applies to NET earnings = gross minus a fixed expense deduction (FEDA) set by your mode of work: 60% for cars/vans/lorries, 35% for motorcycles/PABs/PMDs, 20% otherwise. A car driver’s CPF base is only 40% of gross. | bicycle |
| birthYear | No | Birth year The hard line: born on or after 1 Jan 1995 → increased CPF contributions are MANDATORY. Born before → voluntary, by an IRREVOCABLE opt-in (otherwise MediSave-only). Two riders doing identical work, born days apart, live under different regimes. | |
| grossMonthly | No | Gross platform earnings per month (S$) Fares and fees as paid out by the platform, before the fixed expense deduction. Per operator. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint: true, and the description adds significant behavioral context: regime effective from 1 Jan 2025, no monthly ceiling but a $102k annual cap, irrevocable opt-in for pre-1995 cohort, rate ramp to 2029. 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 front-loaded with the main purpose and then provides detailed context. It is somewhat verbose but every sentence adds value by explaining nuances. The structure is logical: purpose, regime context, input explanations. Could be slightly more concise, but effective.
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 6 parameters and no output schema, the description fully covers the inputs, their implications, and the regime's unique rules. It explains how inputs interact (e.g., birthYear and optedIn, vehicle and FEDA, year and rate ramp). The agent has enough information to invoke the tool correctly.
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?
All 6 parameters have schema descriptions (100% coverage). The tool description adds extra meaning beyond schema, e.g., explaining the 'hard line' for birthYear, FEDA percentages for vehicle, and rate ramp for year. This enriches understanding beyond what the schema alone provides.
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 tool computes 'monthly CPF deduction and operator top-up' for Singapore platform workers under the Platform Workers Act. It specifies the exact use case (ride-hail or delivery platform worker) and distinguishes itself from sibling tools like singapore_property_stamp_duty or other nation-specific calculators.
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 implicitly guides when to use by explaining the three critical inputs (birth date, vehicle, year) and their effects. It does not explicitly list alternatives or when not to use, but the context from sibling-tools and the detailed regime explanation provides sufficient guidance 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.
singapore_property_stamp_dutySingapore Property Stamp Duty (BSD + ABSD + SSD)ABuyer’s, Additional Buyer’s, and Seller’s Stamp Duty at the current IRAS rates — including the 60% foreigner ABSD and the 2025 four-year SSD. Computes Singapore residential stamp duty at the rates actually in force: BSD on the marginal bands up to 6%, ABSD by your exact buyer profile and property count (foreigners pay a flat 60% since 27 Apr 2023 — double what most AI models still quote), and SSD by your acquisition-date cohort (purchases on/after 4 Jul 2025 are on a new 16/12/8/4 four-year schedule). The inputs that swing the answer are ones buyers rarely know matter: the citizenship tier (a US citizen gets Singapore Citizen treatment under the FTA; a US green-card holder does not), how many residential properties you already hold (any fractional interest counts in full), and for joint purchases, the co-buyer whose rate governs the entire price.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Buying or selling? | buy |
| price | No | Price / market value (the higher of the two) (S$) Stamp duty is charged on the higher of the price and the market value — for buying and selling alike. | |
| acqYear | No | Acquisition year Selling-mode only. The acquisition date is the day you accepted/exercised the Option to Purchase (or signed the Sale & Purchase Agreement) — not the grant of the option. It selects which SSD schedule applies. Acquisitions before 14 Jan 2011 are not modeled (any sale now is past every tier anyway). | |
| profile | No | Buyer profile The decisive input — it moves ABSD between 0% and 60% of the price. The FTA carve-out is exact: US CITIZENS qualify (green-card holders do NOT); for Iceland, Liechtenstein, Norway and Switzerland, both nationals and PRs qualify. Buying-mode only. | sc |
| acqMonth | No | Acquisition month Selling-mode only. 1–12. | |
| saleYear | No | Sale year Selling-mode only. The year you (will) contract to sell. | |
| saleMonth | No | Sale month Selling-mode only. 1–12. | |
| propertiesOwned | No | Residential properties already owned in Singapore Count before this purchase. Any fractional interest — even 1% on a parent’s flat — counts as one full property. Overseas property does not count. Buying-mode only. | |
| jointHighestRate | No | Joint purchase — co-buyer with a higher ABSD profile In a joint purchase the buyer with the HIGHEST applicable ABSD rate sets the rate for the entire price — not just their share. The co-buyer’s rate here is computed at the same properties-owned count as yours; if they own more, rerun with their count to check whose rate governs. Buying-mode only. | none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, but the description adds extensive behavioral context: it uses current IRAS rates, computes based on buyer profile and property count, handles joint purchases and FTA provisions, and applies correct SSD schedules by acquisition year. 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?
Despite being relatively long, every sentence adds crucial information. The first sentence states the core purpose, and subsequent details are relevant and well-structured. No redundant or tautological content.
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 (9 parameters, no output schema), the description covers all critical aspects: buy/sell modes, rate determination, special cases (FTA, joint purchase), and common errors. It provides enough context for an AI agent to understand and use the tool correctly.
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 is 3. The description adds significant value by explaining the impact of each parameter (e.g., profile moves ABSD 0-60%, propertiesOwned counts fractional interests in full, jointHighestRate governs entire price). This goes 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 the tool computes Buyer's, Additional Buyer's, and Seller's Stamp Duty for Singapore residential property at current IRAS rates. It specifies the exact rates and rules, distinguishing it from generic tax calculators and sibling tools like UK stamp duty.
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 implicitly guides usage by explaining critical inputs (profile, properties owned, joint purchase) and common mistakes (e.g., US citizen vs green card holder, correct SSD schedule). It does not explicitly state when not to use (e.g., non-residential), but the scope is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sipSIP CalculatorASystematic Investment Plan returns — with optional annual step-up, honestly assumed. Projects a monthly SIP (systematic investment plan) to its future corpus, splits invested amount from gains, and supports the annual step-up that matches how salaries actually grow.
| Name | Required | Description | Default |
|---|---|---|---|
| rate | No | Expected annual return (%) 12% is the customary Indian equity assumption; long-run index reality is closer to 10-12% nominal. | |
| years | No | Years (yr) | |
| stepUp | No | Annual step-up (%) Increase the monthly amount every year (e.g. 10% with salary raises). | |
| monthly | No | Monthly investment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description adds behavioral context like 'honestly assumed,' 'splits invested amount from gains,' and the step-up feature, enhancing transparency beyond 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 concise with two clear sentences, front-loaded with the core purpose, and every sentence adds value without 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?
The description sufficiently covers the tool's function and output (corpus, invested amount, gains) for a financial projection tool with well-documented parameters. No output schema is provided, but the description implies key return values.
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%, and the description adds valuable context for 'rate' (customary assumption) and 'stepUp' (example with salary raises), going beyond the schema defaults and 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 the tool projects a monthly SIP to future corpus, splits invested amount from gains, and supports annual step-up. It is specific and distinguishes from general financial calculators, though not explicitly differentiating from siblings like CAGR or compound_growth.
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 implies usage for SIP return estimation with optional step-up, but does not explicitly state when to use this tool versus alternatives or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
split_billSplit BillAEven split with tip, rounded so nobody argues. Splits a bill evenly across people with an optional tip, and shows the clean rounded amount plus who covers the remainder.
| Name | Required | Description | Default |
|---|---|---|---|
| tip | No | Tip (%) | |
| total | No | Bill total | |
| people | No | People |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the primary behavioral note is safety. Description adds useful behavioral context: rounding mechanics and remainder coverage, which goes beyond 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?
Two concise sentences, no wasted words. Information is front-loaded and each sentence adds value.
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 simple three-parameter calculation tool with no output schema, the description sufficiently explains purpose, inputs, and expected outputs (rounded amount and remainder). 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?
All three parameters have descriptions in the schema (100% coverage), so baseline is 3. Description adds extra meaning about rounding and remainder handling, improving clarity.
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 splits a bill evenly with an optional tip, produces rounded amounts, and identifies who covers the remainder. The tool is distinct from sibling financial calculators, establishing a specific purpose.
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?
Description implies use for equitable bill splitting without arguments, but does not explicitly state when to use or not use, nor compare to alternatives among siblings. However, context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
steady_paycheckSteady Paycheck (Variable Income)ATurn an up-and-down income into a safe monthly salary and a right-sized buffer. For freelancers, tipped workers, sellers, and seasonal earners: paste your last months of income and get the salary you can safely pay yourself, how big a buffer your actual swings require, and which months were spikes to bank rather than spend. The pay-yourself-a-salary method every advisor teaches by hand, as a calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| buffer | No | Cash buffer today What’s in the account that smooths the gaps. Leave 0 if none yet. | |
| incomes | No | Monthly income, most recent months Comma-separated, 3–24 months, any order. More months = a truer picture. | |
| essentials | No | Essential monthly costs Rent, food, utilities, insurance, minimum debt payments — the must-pays. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is read-only and deterministic. The description adds the behavioral context that it is a calculator using the 'pay-yourself-a-salary method', and explains what outputs are produced (salary, buffer, spike months). No contradictions.
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 two front-loaded sentences that efficiently convey the tool's purpose and usage. While it uses some evocative language, every part contributes meaning and there is 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?
Despite lacking an output schema, the description fully explains the return values: safe salary, required buffer, and spike months. Parameters are well-documented in both schema and description. The tool is complete for an AI agent's invocation.
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?
All three parameters have schema descriptions (100% coverage), but the tool description adds context by explaining the purpose of each parameter in the overall calculation (e.g., 'buffer: Cash buffer today', 'Leave 0 if none yet'). This slightly exceeds baseline.
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 tool transforms variable income into a safe monthly salary and buffer, targeting freelancers and similar earners. It specifies the verb 'turn' and the resource 'variable income', and distinguishes it from sibling financial calculators by focusing on income smoothing.
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 advises when to use ('for freelancers, tipped workers, sellers, and seasonal earners') and what data to provide ('paste your last months of income'). However, it does not explicitly state when not to use or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
thailand_social_securityThailand Social Security Contribution (2026 ceiling unfreeze)AYour monthly SSO contribution under the 2026 ceiling rise — the ฿15,000 cap stood for 30 years, so the old ฿750 answer is everywhere and wrong. Computes your Thai Social Security Office (SSO) contribution for Section 33 (employees), Section 39 (voluntary ex-employees), or Section 40 (informal workers). The Section 33 wage ceiling was frozen at ฿15,000/month from 1995 until the Royal Gazette announcement of 12 Dec 2025 raised it to ฿17,500 from 1 Jan 2026 — so the maximum employee contribution jumps from ฿750 to ฿875, with further phases to ฿20,000 (2029) and ฿23,000 (2032). Thirty years of the old number mean general AI and much of the Thai web still answer ฿750; this tool uses the phased schedule, and knows §39 stays on its frozen ฿4,800 base.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Contribution year The ceiling rises in three phases: ฿17,500 (2026), ฿20,000 (2029), ฿23,000 (2032). Pick 2025 to see the old frozen ceiling. | 2026 |
| section | No | Which SSO section are you under? The section decides everything: §33 is percentage-of-wage with a ceiling, §39 is a flat ฿432, §40 is a chosen flat option. | 33 |
| s40option | No | Section 40 option Only used for Section 40. Higher options buy more benefit branches. | 1 |
| monthlyWage | No | Monthly wage (฿) Gross monthly wage — used for Section 33 only. Contributions apply between the ฿1,650 floor and the year’s ceiling. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=true, and the description adds extensive behavioral context: historical freezing, phased ceiling increases, and that general AI answers are outdated. No contradictions.
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 somewhat verbose with historical context, but it is well-structured, front-loads the key change (2026 ceiling unfreeze), and every sentence adds relevant information. A slightly more concise version could exist.
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 no output schema, the description thoroughly explains what the tool computes, covering all sections, wage floors/caps, and the phased schedule. It is comprehensive for the tool's complexity.
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 all 4 parameters. The tool description adds significant meaning beyond schema, such as explaining the ceiling phases for year, the flat contribution for Section 39, and the wage floor. This helps the agent understand parameter usage.
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 uses specific verbs ('Computes') and resources ('Thai Social Security Office (SSO) contribution') and clearly distinguishes from sibling tools by focusing on Thailand-specific contribution calculation with the 2026 ceiling unfreeze.
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 explains when to use the tool: for computing SSO contributions under the new ceiling, especially when old answers are wrong. It also outlines the three sections. It does not explicitly state when not to use, but the context is clear among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
true_hourly_wageTrue Hourly Wage (Gig & Side Hustle)AWhat a gig actually pays per hour — after vehicle costs, waiting time, and self-employment tax. Turns gross gig or side-hustle earnings into the real hourly wage: counting every hour worked (including waiting and driving between jobs), the full per-mile cost of the vehicle (not just gas), and the tax that no employer is withholding. Then compares the result to minimum wage — and is honest when the answer is "stay home."
| Name | Required | Description | Default |
|---|---|---|---|
| gross | No | Gross earnings / week What the app(s) paid you, before anything. | |
| hours | No | Total hours / week Include waiting, driving between jobs, and returning empty — research finds unpaid "deadhead" time is about a third of gig working time. | |
| miles | No | Miles driven / week All of them, including empty miles. 0 if the hustle has no vehicle. | |
| taxPct | No | Tax on profit (%) US self-employment tax alone is ~14% of profit; add your income-tax bracket for the fully-taxed number. Set 0 to see pre-tax. | |
| minWage | No | Local minimum wage The benchmark an employer would legally have to beat. US federal is $7.25; many states/cities are $15+. | |
| costPerMile | No | Vehicle cost / mile Gas alone is ~$0.12–0.18/mi. The IRS all-in rate (fuel + maintenance + depreciation + insurance) is ~$0.70/mi. Most drivers’ true cost is $0.25–0.45. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by detailing what costs are included (vehicle cost, waiting time, self-employment tax) and stating it compares to minimum wage and is 'honest when the answer is stay home.' Annotations indicate read-only, which is consistent.
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 concise and front-loaded with the main purpose, followed by clear enumerations of included factors. Every sentence adds value without 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?
Given high schema coverage and no output schema, the description adequately explains the input factors and implies the output (comparison to minimum wage). It is complete for a calculator tool, though it could explicitly mention the output type.
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 the baseline is 3. The tool description reiterates concepts but does not add new parameter-specific meaning beyond what the schema provides.
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 tool's function: calculating the true hourly wage of a gig after accounting for vehicle costs, waiting time, and self-employment tax. It uses specific verbs and resources, and distinguishes itself from sibling financial calculators by focusing on gig/side-hustle earnings.
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 implies usage when assessing gig earnings, but does not explicitly state when to use this tool versus alternatives or provide 'when not to use' guidance. It lacks reference to sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uae_gratuityUAE End-of-Service Gratuity CalculatorAYour end-of-service gratuity under Decree-Law 33/2021 Art. 51 — basic wage, no resignation penalty — plus the savings-scheme comparison. Computes the end-of-service gratuity (مكافأة نهاية الخدمة) under UAE Decree-Law 33/2021: 21 days of basic wage per year for the first five years of service, 30 days per year after, on the LAST basic wage only, capped at two years' wage — and, in compare mode, the monthly contribution the voluntary savings scheme (Cabinet Resolution 96/2023) would pay instead. General AI reliably gets the UAE wrong in two ways: it cites the ABOLISHED 1980-law rules (limited/unlimited contracts, the 1/3–2/3 resignation penalty, forfeiture on dismissal — all gone since February 2022), and it ports Saudi rules across the border (KSA uses the actual wage including allowances, keeps a resignation ladder, and zeroes the award on an Art. 80 dismissal; the UAE does none of those). Mainland UAE only — DIFC (DEWS) and ADGM have their own regimes.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | What to compute The savings scheme is an employer opt-in that replaces gratuity accrual with monthly contributions to a licensed, ring-fenced fund. Compare mode shows the monthly contribution at your current service band and how the two regimes differ. | gratuity |
| basicMonthly | No | Last monthly BASIC wage (AED) (AED) UAE gratuity uses the BASIC wage only — housing, transport, and other allowances are excluded. This is the OPPOSITE of Saudi Arabia, where the base is the actual wage including allowances. Check your contract's basic/allowance split; the gratuity rides on the basic line alone. | |
| serviceYears | No | Years of service Total continuous service in years — decimals are fine, fractions of a year earn pro-rata. Days of unpaid absence are excluded from the service count. Under one full year of service, no gratuity is due. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm readOnlyHint=true (no side effects). The description adds rich behavioral context: computation uses only basic wage, caps at two years, excludes allowances, and contrasts with Saudi rules. It also explains the voluntary savings scheme. 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 well-structured, starting with a clear summary, then computation details, common pitfalls, and jurisdictional notes. However, it is somewhat verbose and could be more concise while retaining essential information.
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 no output schema, the description explains outputs: gratuity value and compare mode monthly contribution. It covers formula, caps, jurisdiction restrictions, and common errors. For a calculator tool with 3 simple parameters, the description is sufficiently complete to enable correct invocation.
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, but the tool description adds substantial meaning beyond the schema. It explains the legal basis (Art. 51), the cap on gratuity, and provides warnings about basic wage versus Saudi rules. This extra context significantly aids 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 it computes UAE end-of-service gratuity under Decree-Law 33/2021, with a savings-scheme comparison. It specifies the legal basis, distinguishes from common errors (old law, Saudi rules), and contrasts with sibling tools like saudi_end_of_service and india_gratuity, making the purpose unambiguous.
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 mainland UAE only (not DIFC/ADGM) and warns against using old 1980-law rules or Saudi rules. It also describes when to use compare mode. However, it does not explicitly list alternative tools for other jurisdictions, though sibling tool names imply such tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uk_capital_gains_taxUK Capital Gains Tax Calculator (2025-26 & 2026-27)ACapital Gains Tax on shares, crypto, property, or a business sale — current £3,000 allowance, the 18%/24% rate split driven by your income, and the BADR 14% → 18% ramp. Computes UK Capital Gains Tax on a disposal using the current rules: the £3,000 annual exempt amount, the 18%/24% rates that have applied to ALL assets since 30 October 2024, the income-stacking rule that decides how much of the gain falls at 18% vs 24%, and Business Asset Disposal Relief with its stepping rate (14% in 2025-26, 18% from 6 April 2026) and £1 million lifetime limit. General AI reliably gets this wrong three ways at once — quoting the abolished £12,300 allowance, the dead 10%/20% share rates, and a BADR rate from the wrong year — and answers without asking for your taxable income, the input that actually sets the rate.
| Name | Required | Description | Default |
|---|---|---|---|
| gain | No | Total gain on the disposal (£) Proceeds minus what you paid minus allowable costs (buying/selling fees, improvement costs). The gain, not the sale price. | |
| assetType | No | What are you selling? BADR (Business Asset Disposal Relief) needs, broadly: 2 years of ownership, and for company shares at least 5% of shares and votes while being an officer or employee — check the full conditions. Selling the home you’ve always lived in? Usually NO CGT at all (Private Residence Relief) — this tool is for property that was never, or not always, your main home. | other |
| disposalDate | No | When are you disposing (tax year)? The BADR rate steps 14% → 18% at this boundary (6 April 2026) — the disposal date IS a rate input now, not admin detail. Main 18%/24% rates and the £3,000 allowance are the same in both years. | 2026-27 |
| taxableIncome | No | Your taxable income this year (£) Income AFTER the personal allowance — roughly your salary minus £12,570. This is the hidden input: the gain stacks on top of it, and it decides how much falls in the basic band at 18% vs above it at 24%. | |
| badrLifetimeUsed | No | BADR lifetime relief already claimed (£) Only matters for BADR disposals. Gains you have already claimed BADR on, ever — the relief has a £1 million lifetime limit. | |
| otherGainsUsedAea | No | Already used the £3,000 allowance this year? The annual exempt amount is per tax year across all your disposals, not per disposal. | no |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=true annotation, the description discloses key behaviors: use of £3,000 allowance, 18%/24% rate split with income-stacking, BADR stepping rates, and lifetime limit. It also notes that users must input taxable income as it determines the rate. 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 long (over 150 words) but well-structured with key facts front-loaded and warnings embedded. It could be slightly more concise, but every sentence adds value given the complexity of CGT rules. The structure is logical.
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 (6 parameters, no output schema), the description thoroughly explains inputs, common pitfalls, and computation logic. It covers all parameters and provides enough detail for an agent to select and invoke the tool correctly. No output schema is needed as the purpose is straightforward.
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 parameter. The description adds extra semantic context, especially for taxableIncome (explaining its role as the hidden input for rate determination) and assetType (clarifying BADR conditions and main home exemption). This adds meaning beyond the 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?
The description explicitly states it computes UK Capital Gains Tax on a disposal using current rules, and lists asset types (shares, crypto, property, business sale). It distinguishes itself from sibling tools by being a specific tax calculator, and the title includes tax years. This is a specific verb+resource with clear scope.
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 explains when to use (for disposals of various assets) and warns about common mistakes (abolished allowance, dead rates). It implies when not to use for main home (Private Residence Relief), but does not explicitly mention alternative tools in sibling list for other tax scenarios. Still, context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uk_car_tax_vedUK Road Tax Calculator (car tax / VED) — 2026-27 ratesAWhat you’ll pay to tax your car this year — the first-year bill on a new one, the £200 everyone pays after that, and the £440 surcharge on pricier cars. Car tax arrives as two very different bills. The first year is a one-off charge set by the car’s CO2, running from a few hundred pounds to over £5,000 — which is why it usually disappears into the on-the-road price and is forgotten. Every year after that is a flat £200, and electric cars have paid it since 1 April 2025, the single fact a general-purpose AI is most likely to get wrong. Then there is the surcharge: any car listed above £40,000 pays an extra £440 a year from its second year to its sixth. For EVs that threshold rose to £50,000 on 1 April 2026 and was backdated to anything registered from April 2025, so even an answer that was correct last year has gone stale. Cars from 2001 to 2017 run on an older CO2 table, which is here as well.
| Name | Required | Description | Default |
|---|---|---|---|
| co2 | No | CO2 emissions (g/km) From the V5C logbook or the manufacturer. Sets the first-year rate for cars registered from April 2025 and the band for 2001–2017 cars. Ignored for EVs, and for the standard-year tax on post-2017 cars. | |
| fuel | No | Fuel type Zero emission = pure electric (or hydrogen fuel-cell). Hybrids count as petrol/diesel — their £10 hybrid discount ended in April 2025. Non-RDE2 diesels pay one first-year band higher (see methodology; this tool assumes RDE2). | petrolDiesel |
| regDate | No | When was the car first registered? The decisive input — three different tax regimes by first-registration date (the date the car was first registered anywhere, not when you bought it). Cars first registered before 1 March 2001 are taxed by engine size instead and are out of scope here. | new |
| listPrice | No | Manufacturer list price when new (£) The published list price on the day of first registration, including factory options and VAT — not what was actually paid. This decides the expensive-car supplement, and it sticks with the car for life. | |
| yearOfOwnership | No | Which year of the car’s life? Which year’s tax to show. The CO2-based first-year rate only exists for cars registered from April 2025 — for older cohorts "first year" is shown as a normal year. Years 2–6 are when the expensive-car supplement can apply. | standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the readOnlyHint: it returns monetary amounts split into first-year and standard-year, and explains the surcharge logic for expensive cars. It highlights edge cases like the April 2026 EV threshold change and backdating to April 2025, warning that answers can become stale. It also notes the tool ignores CO2 for EVs and standard-year rates, and assumes RDE2 for diesels, providing transparency about calculation assumptions.
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 front-loaded with the essential 'what you'll pay' summary and flows logically from first-year to standard-year to surcharge, then to older cars. It is longer than average, but each sentence carries unique information about rates, thresholds, or exceptions. Some redundancy exists (repeating dates like April 2025/2026), but the narrative structure helps readability. A minor trim could tighten it without losing value.
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 calculator with 5 parameters, 100% schema coverage, and no output schema, the description is extremely thorough. It covers first-year, standard-year, surcharge, EV rules, older cars, and out-of-scope pre-2001 cars. It also explains parameter interactions (e.g., co2 ignored for EVs, listPrice threshold changes). The description fully prepares an agent to select this tool and interpret inputs correctly across a wide range of scenarios.
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?
The description extensively adds meaning beyond the schema: it explains how 'co2' drives first-year rates for 2025+ cars and bands for 2001-2017 cars, how 'regDate' distinguishes three tax regimes, and how 'listPrice' triggers the expensive-car supplement. It also explains the significance of 'yearOfOwnership' (first vs standard vs after 6) and clarifies that EVs ignore co2. This compensates for the schema's defaults, giving agents the why behind each parameter.
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 tool calculates UK car tax (VED) with 2026-27 rates, including first-year CO2-based rates, the standard £200 rate, and the expensive-car surcharge. It specifically mentions handling for different registration periods (2001-2017, post-2017) and EVs, distinguishing it from sibling tax tools by naming unique rates and rules. The verb 'what you'll pay' and resource 'road tax' are specific, with scope explicitly defined.
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 explains when to use this tool: to find the annual and first-year tax for cars, with detailed rules for different registration dates and fuel types. It also states exclusions: cars registered before 1 March 2001 are out of scope because they're taxed by engine size. It clarifies that EVs are included and have been taxed since April 2025, and that the tool assumes RDE2-compliant diesels, guiding users on applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uk_child_benefit_chargeUK High Income Child Benefit Charge (HICBC) OptimizerAHow much of your child benefit the £60k–£80k charge claws back — and the exact pension contribution that makes it disappear. Computes the High Income Child Benefit Charge on the higher earner’s adjusted net income (ANI): 1% of the household’s child benefit per £200 of ANI above £60,000, reaching 100% at £80,000. Then it computes the lever most people miss — relief-at-source pension contributions are grossed up ×1.25 before they reduce ANI, so a precise net contribution can zero the charge while collecting higher-rate relief on top. General AI still quotes the old £50,000 threshold, cites the household-income reform that was announced and then dropped, and tells you Self Assessment is required when PAYE collection has been live since September 2025.
| Name | Required | Description | Default |
|---|---|---|---|
| giftAid | No | Gift Aid donations this year (net) (£) Charity donations under Gift Aid (what you actually gave). Like pensions, they are grossed up ×1.25 and reduce adjusted net income. | |
| children | No | Children you claim child benefit for Eldest child £27.05/week, each additional child £17.90/week (2026-27). | |
| higherIncome | No | Higher earner’s taxable income (£) The HIGHER earner’s adjusted-net-income components before this tool’s deductions: salary + bonus + benefits in kind (company car, medical) + rental and investment income. The charge always tests the higher partner individually — never the household total. | |
| pensionContributions | No | Pension contributions this year (relief at source, net) (£) What you actually paid into a personal/workplace relief-at-source pension (the net amount). The provider adds 25% basic-rate relief, and the GROSSED-UP figure (×1.25) reduces your adjusted net income — this is the lever that shrinks or zeroes the charge. Salary-sacrifice and net-pay contributions are already out of your taxable income, so leave those out. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors beyond readOnlyHint: formula details, gross-up factor, individual earner focus, and exclusions (salary-sacrifice). Adds significant context beyond 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?
Front-loaded with key results, then provides background and warnings. Slightly verbose but each sentence adds value. 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?
No output schema, but description explains both outputs (charge amount and optimal pension contribution) and the underlying formula. Covers important contextual warnings (outdated advice).
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?
Adds meaning beyond schema by explaining the 'lever most people miss' and clarifying which contributions count. Schema coverage is 100%, but description provides extra nuance.
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 computes the HICBC and the exact pension contribution to eliminate it. It distinguishes itself from sibling financial calculators by addressing a specific UK tax charge.
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?
Provides clear use case and warns about common misconceptions (old threshold, dropped reform, PAYE vs Self Assessment). Does not explicitly list when not to use, but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uk_first_year_self_assessmentUK Self-Assessment First-Year Bill Calculator (payments on account)AYour real first-January Self Assessment bill — the year’s tax PLUS 50% of next year’s, due the same day — with the exact dated payment schedule. Computes a UK sole trader’s 2025-26 Self Assessment bill (income tax stacked on top of any PAYE income, plus Class 4 National Insurance) and then the part general AI reliably misses: payments on account. First-time filers owe 150% of their bill on 31 January 2027 — the full year’s tax plus the first half of next year’s, in one payment, for income earned up to ~22 months earlier. The tool applies the exact boundary tests (POAs are waived when the bill is under £1,000 or when more than 80% of your tax was collected at source through PAYE), the post-April-2025 late-payment interest formula (Bank rate + 4%, currently 7.75% — models still quote the old + 2.5%), and flags whether Making Tax Digital’s quarterly reporting catches you from April 2026.
| Name | Required | Description | Default |
|---|---|---|---|
| profit | No | Self-employment profit for 2025-26 (£) Tax year 6 Apr 2025 – 5 Apr 2026: revenue minus allowable expenses (your taxable profit, not turnover). | |
| firstYear | No | Is this your FIRST Self Assessment year? First-timers get the 150% shock: the whole year’s bill plus the first payment on account land on the same day. Returning filers have already part-paid via last year’s payments on account. | yes |
| priorBill | No | Last year’s total Self Assessment bill (£) Only used when this is NOT your first year: it set the two payments on account (50% each) you have already made toward this year. | |
| payeIncome | No | Employment (PAYE) income in the same year (£) Salary taxed through payroll. It uses up your personal allowance and basic-rate band BEFORE your profit — and because its tax is collected at source, it feeds the 80% test that can spare you payments on account entirely. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=true, openWorldHint=false), but the description adds substantial behavioral context: it details the 150% payment shock, boundary tests for waiving POAs (under £1,000 or >80% PAYE), the late-payment interest formula, and MTD flag. This goes far beyond annotations and fully discloses the tool's logic and edge cases.
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 front-loaded with the core purpose in the first sentence, but it is relatively long and includes some extraneous phrasing (e.g., 'the part general AI reliably misses'). While every sentence adds value, the overall length could be trimmed slightly without losing information. Still, it remains focused and 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?
Despite no output schema, the description fully explains what the tool returns (the exact dated payment schedule) and covers all key aspects: calculation logic, POA rules, interest formula, and MTD flag. With four parameters and a specialized use case, the description is comprehensive and leaves no important 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 significant meaning beyond the schema. For example, it explains why 'profit' is taxable profit (not turnover), how 'payeIncome' feeds the 80% test to waive POAs, and the role of 'firstYear' and 'priorBill' in the payment schedule. This enriches the schema definitions with practical context.
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 identifies the tool as computing a UK sole trader's first-year Self Assessment bill with payments on account, specifying the exact tax year and distinguishing it from generic tax calculators. The verb 'Computes' and specific resource 'UK sole trader’s 2025-26 Self Assessment bill' make the purpose explicit and unique among siblings.
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?
Description implies usage for first-time UK self-assessment filers by focusing on first-year scenarios and mentioning 'First-time filers'. While it provides context for when to use, it lacks explicit when-not-to-use guidance or alternatives. The clarity of the scenario compensates for the absence of negative examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uk_notice_payUK Notice Pay CalculatorAHow many weeks’ notice you’re owed, what it pays, and how much of it is taxed. Your employer owes you notice when they end your job: one week if you have been there under two years, then one week for every full year, up to twelve. This works out your weeks and what they pay — and then the part people get wrong. Notice pay is not covered by the £30,000 tax-free allowance that shelters redundancy pay; if it is paid in lieu it is taxed as normal earnings. And if your employer has gone bust and the state pays instead, the amount is capped at £751 a week and reduced by benefits you claimed — or could have claimed, even if you never applied.
| Name | Required | Description | Default |
|---|---|---|---|
| years | No | Complete years worked there Full years of continuous employment. Part years do not add a week — at 4 years 11 months you get 4 weeks, not 5. | |
| nation | No | Where you work Notice periods are the same everywhere in the UK. Only the insolvency weekly cap differs: £751 in Great Britain, £783 in Northern Ireland. | gb |
| taxRate | No | Your income tax rate Used to estimate the tax on your notice pay. National Insurance comes off on top of this and is not included in the estimate. | 20 |
| benefits | No | Benefits you got (or could have got) during notice (£ total) Insolvency claims only. Universal Credit or Jobseeker’s Allowance for the notice period is deducted — and it is deducted even if you never applied, unless you were refused and send the rejection letter. | |
| situation | No | How is your notice being handled? The decisive input: it changes both the amount and the tax. Paid in lieu is taxed as earnings with no £30,000 shelter. The insolvency route is capped weekly and reduced by benefits. | pilon |
| weeklyPay | No | Your weekly pay before tax (£) Gross, before tax. Monthly salary ÷ 4.333 if that is easier. | |
| contractWeeks | No | Notice in your contract (weeks, if longer) Leave 0 to use the statutory minimum. Many contracts say one or three months — that is 4.3 or 13 weeks, and the longer of the two always wins. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses statutory notice calculation (one week per year up to 12), tax treatment (no £30,000 shelter, taxed as normal earnings), insolvency cap (£751/week in Great Britain), and benefit deduction even if unclaimed. This adds significant context beyond what annotations provide.
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, well-front-loaded paragraph. It starts with a summary question, then efficiently walks through the statutory rule, tax nuance, and insolvency specifics. Every sentence contributes new information; the length is justified by 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?
Covers key scenarios: statutory notice, paid-in-lieu tax, and insolvency (cap and benefit deduction). No output schema exists, but the description states it works out weeks, pay, and tax, which implies expected outputs. Combined with the detailed input schema, the description is complete for an agent to select and use the tool.
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%, with each parameter already well-documented (e.g., 'years' explains part years, 'nation' explains cap difference, 'benefits' explains insolvency deduction). The description adds general context but does not provide additional parameter-level semantics beyond what the schema already contains.
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 opens with a clear statement of what the tool does: 'How many weeks’ notice you’re owed, what it pays, and how much of it is taxed.' It explicitly contrasts notice pay with redundancy pay, noting the £30,000 tax-free allowance distinction, which differentiates it from sibling tools like uk_statutory_redundancy_pay.
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 explains when the tool is relevant: when an employer ends a job and owes notice, including paid-in-lieu and insolvency scenarios. It distinguishes notice pay from redundancy pay conceptually, but does not explicitly name an alternative tool or state 'use this tool when...' / 'not when...'. Clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uk_redundancy_packageUK Redundancy Package Calculator — what you actually take homeARedundancy pay, notice and untaken holiday together — and which parts of it the £30,000 exemption does not cover. Being made redundant pays you three different things, taxed three different ways, and the letter usually quotes only the first. Statutory redundancy pay is tax-free, and shares a £30,000 exemption with any ex-gratia top-up. Notice pay is not covered by it — since the PENP rules a payment in lieu is taxed as earnings whatever it is called. Accrued untaken holiday is not covered either. So "redundancy is tax-free up to £30,000" is true of one component and false of the other two, and someone with twelve weeks of notice and a fortnight of holiday can be several thousand pounds out. This adds all of it up and splits the tax the way HMRC does, including the National Insurance boundary, which sits in a different place again. Northern Ireland is included, with its own higher limits.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Your age when the job ends | |
| nation | No | Where do you work? Northern Ireland sets its own, higher statutory limits: £783 a week and £23,490 maximum. | gb |
| niRate | No | Your National Insurance rate NI is due on notice and holiday pay, never on the termination payment — a different boundary from income tax. | 8 |
| taxRate | No | Your marginal income tax rate A large payout can push you into a higher band for the year; this applies one rate to the taxable part. | 40 |
| exGratia | No | Employer top-up above the statutory minimum (£) An enhanced or ex-gratia payment. Shares the £30,000 exemption with your statutory redundancy pay. | |
| weeklyPay | No | Gross weekly pay (£) | |
| holidayDays | No | Untaken holiday days owed | |
| serviceYears | No | Complete years of service Only full years count for redundancy pay. Under 2 years there is no statutory redundancy — but notice and holiday are still owed. | |
| noticeTreatment | No | How is your notice being handled? Both are taxed as earnings. Since the 2018 PENP rules, calling a payment "compensation" no longer makes notice tax-free. | pilon |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true and openWorldHint=false; the description adds substantial behavioral detail: statutory redundancy pay shares the £30,000 exemption, notice pay is taxable under PENP rules, untaken holiday is not exempt, and the NI boundary differs. It also notes Northern Ireland's higher statutory limits. 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?
At roughly 170 words, the description is longer than average but front-loads the core purpose and uses each sentence to explain a meaningful tax nuance or regional difference. It is appropriately detailed for the complexity of the calculation and contains no filler.
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?
The description thoroughly covers the tax logic, exemptions, PENP rules, NI boundary, and Northern Ireland inclusion. However, with no output schema, it never states what the tool returns (e.g., a breakdown of tax-free amount, taxable earnings, NI, and net take-home). This is a notable gap for a 9-parameter calculator.
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?
The input schema already provides 100% description coverage with detailed explanations for all 9 parameters, so the tool description is not required to repeat them. The description adds valuable conceptual background about tax treatment and exemptions but does not elaborate on specific parameter syntax or values beyond what the schema already provides.
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 calculates the full redundancy package—pay, notice, and untaken holiday—and splits tax according to HMRC rules, including the NI boundary and Northern Ireland variants. It distinguishes itself from sibling tools like uk_statutory_redundancy_pay and uk_notice_pay by covering the combined package rather than a single component.
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 gives strong contextual guidance, explaining that the common belief about the £30,000 exemption is misleading and that notice and holiday are taxed as earnings. It implies when this tool is needed (when all three components must be calculated together) but does not explicitly name alternative tools or 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.
uk_stamp_duty_sdltUK Stamp Duty Calculator (SDLT) — England & Northern IrelandAWhat stamp duty you’ll pay on a house in England or Northern Ireland — including first-time buyer relief and the extra on a second home. Stamp duty is not one number attached to a price. Four things can apply at once: the standard bands, first-time buyer relief that takes you to nothing below £300,000, a 5% surcharge that lands on the whole purchase price rather than just the top slice if this is a second home or a buy-to-let, and another 2% if you are buying from abroad. They stack. Two of those changed recently — the bands went back up on 1 April 2025 and the second-home surcharge rose from 3% to 5% in October 2024 — so a general-purpose AI will often hand you a number that was right eighteen months ago and is now thousands of pounds out. Scotland and Wales charge different taxes altogether, LBTT and LTT, and are not covered here.
| Name | Required | Description | Default |
|---|---|---|---|
| price | No | Purchase price (£) The chargeable consideration — normally the agreed purchase price of the property. | |
| buyerType | No | Which buyer are you? The decisive input — it selects the whole rate table. "First-time buyer" means ALL purchasers are first-time buyers: never owned (or part-owned) a dwelling ANYWHERE in the world, including inherited property. "Additional dwelling" means you will own 2+ dwellings at completion and are not replacing a main residence you sold. The two are mutually exclusive by definition — a first-time buyer owns nothing, an additional-dwelling buyer already owns. | moving |
| nonResident | No | Any buyer non-UK-resident? Non-resident for SDLT = present in the UK fewer than 183 days in the 12 months before completion. Adds 2% to every band. On a joint purchase, ANY non-resident buyer makes the whole transaction non-resident. | no |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, and the description adds valuable behavior: the four rules stack, the 5% surcharge applies to the whole purchase price, and the rates changed recently (April 2025 and October 2024). This gives an AI agent crucial context about calculation complexity and temporal sensitivity, going well beyond the readOnlyHint.
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?
Four sentences, front-loaded with the core purpose, then expanding into complexity, recency, and scope. Every sentence contains distinct information with no filler, though it is slightly long for a tool description. The structure is logical and easy to parse.
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?
Even without an output schema, the description explains all major input factors (standard bands, first-time buyer relief, second-home surcharge, non-resident surcharge) and their stacking, covers geographic exclusions, and mentions recent rate changes. This is quite complete for a calculator, though it does not specify the exact return format.
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%, with each parameter (price, buyerType, nonResident) already having detailed, self-explanatory descriptions. The tool description adds overall context about how these factors interact but does not provide additional per-parameter meaning beyond what the schema already offers, so the baseline of 3 is appropriate.
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 calculates stamp duty for England and Northern Ireland, with the specific verb 'pay' and resource 'house'. It also distinguishes from other tools by explicitly noting that Scotland (LBTT) and Wales (LTT) are not covered, and the full list of factors (first-time buyer relief, surcharge, non-resident) makes its purpose unmistakable.
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?
It provides explicit when-not guidance: 'Scotland and Wales charge different taxes altogether, LBTT and LTT, and are not covered here.' It also warns that a general-purpose AI may give outdated figures due to recent rate changes, implying that this tool should be used for current SDLT calculations. It does not name a specific sibling alternative, but the scope exclusion is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uk_statutory_redundancy_payUK Redundancy Pay Calculator — statutory entitlement 2026AHow much redundancy pay you’re owed — from your age, your years of service and your weekly pay, on the 2026 limits. Redundancy pay in the UK has a formula, and it is stranger than most people expect. Your years of service are weighted by how old you were during each of them — a year past 41 is worth a week and a half’s pay, a year in your twenties or thirties is worth one, a year before 22 is worth half. Only your last twenty count. And the weekly pay that feeds the formula is capped at £751 however much you actually earn, with £22,530 the ceiling on the whole payment. That cap moves every April, which is why a general-purpose AI will usually quote you last year’s. The age-weighting runs backwards from your leaving date and drops any year straddling a birthday into the lower band — a small fiddly rule, easy to state and easy to get wrong. Northern Ireland sets its own higher limits; those are here too.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Your age at the dismissal (relevant) date The multiplier depends on your age DURING each backward-counted year of service, not just today’s age — this is the table walk general AI botches. Use your age on the date your employment ends. | |
| nation | No | Where do you work? Northern Ireland sets its own limits — currently HIGHER than Great Britain’s: £783 weekly, £23,490 maximum. | gb |
| weeklyPay | No | Gross weekly pay (£) Before tax. If your pay varies, use the average over the 12 weeks before your notice day. Capped at £751 — high earners all get the same statutory figure. | |
| serviceYears | No | Complete years of continuous service Only FULL years count — 9 years 11 months is 9. Under 2 years there is no statutory entitlement; over 20 only the most recent 20 count. | |
| dismissalDate | No | When does (did) your employment end? Picks the statutory limits: £751 weekly / £22,530 max from 6 April 2026, £719 / £21,570 before. The limits re-uprate every April. | on-after-6-apr-2026 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively discloses the calculation behavior beyond the readOnlyHint annotation: it explains the age-weighted formula, the weekly pay cap of £751, the £22,530 maximum, the backwards-counting rule for birthdays, and the Northern Ireland limits. This gives the agent a deep behavioral model of what the tool does with inputs.
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, dense paragraph where every sentence adds value. It front-loads the purpose and then packs the formula, caps, and edge cases without repetition or fluff. It is long but efficient, making it a model of structured conciseness.
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?
Even without an output schema, the description makes it clear that the tool returns the monetary amount of redundancy pay owed. It covers the key variables (age, service, weekly pay, nation, dismissal date), the 2026 limits, the April uprating, and the NI differences, so the agent has all context needed to invoke the tool correctly.
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?
The input schema already provides 100% coverage with detailed descriptions for each parameter, so the baseline is 3. The description adds meaningful context that ties parameters together (e.g., 'Only your last twenty count' clarifies serviceYears; 'a year past 41 is worth a week and a half’s pay' clarifies age weighting), pushing it to a 4.
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 opens with a specific verb+resource: 'How much redundancy pay you’re owed' and then details the inputs (age, years of service, weekly pay) and the 2026 limits. This makes the tool's purpose unmistakable and distinguishes it from other financial calculators in the sibling list.
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 provides clear context for when to use the tool (calculating statutory UK redundancy pay, including Northern Ireland variations) and even warns that 'a general-purpose AI will usually quote you last year’s' caps, implying this tool is the accurate alternative. However, it does not explicitly name alternative sibling tools 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.
uk_statutory_residence_testUK Statutory Residence Test DeciderAWhether you are UK tax resident this year — the full statutory test, not the 183-day myth. Runs the full UK Statutory Residence Test (FA 2013 Sch 45): automatic overseas tests, automatic UK tests, then the sufficient-ties tables. The 183-day figure everyone (and general AI) anchors on is only the ceiling — a leaver with 3 UK ties is resident at just 46 days, and at 121 days a single tie is enough. The input that decides which table applies — were you UK-resident in any of the 3 prior tax years — is the one users never volunteer, so this tool leads with it. Includes the deeming rule for non-midnight days, which AI answers routinely miss.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days present in the UK at midnight this tax year Count days you were in the UK at the end of the day (midnight). Enter the count with exceptional-circumstances days (capped at 60) already removed, and exclude pure transit days (arrived one day, left the next, did nothing unrelated to travel). | |
| tieWork | No | Work tie 40 or more days this year (in any pattern) on which you did more than 3 hours of work in the UK. | no |
| tie90Day | No | 90-day tie You spent more than 90 days in the UK in either (or both) of the 2 previous tax years. | no |
| tieFamily | No | Family tie A UK-resident spouse/civil partner (or partner you live with) or minor child. A child you saw in the UK on fewer than 61 days is disregarded; a child who is UK-resident only because of full-time education here is also disregarded if they spend fewer than 21 days in the UK outside term time. | no |
| tieCountry | No | Country tie (leavers only) The UK is the country where you spent the most midnights this year — a tie for first place that includes the UK counts as met. IGNORED for arrivers: if you answered "No" to prior-years residence above, this input has no effect on the result. | no |
| priorResidence | No | Were you UK tax resident in any of the 3 prior tax years? The decisive input, and the one everyone omits when they ask "am I resident?". It decides WHICH ties table applies to you and whether two extra rules — the country tie and the deeming rule — exist for you at all. A leaver can be resident at 46 days; an arriver never before 46. | leaver |
| qualifyingDays | No | Days present but NOT at midnight (optional) Days you were in the UK at some point but had left before midnight, so they are not in the count above. Only matters for leavers with 3+ ties — the deeming rule adds every such day past the first 30 to the ties-table day count. Most people can leave this at 0. | |
| automaticUkHome | No | Do you meet the UK home test? Yes if you had a UK home you were present in on ≥30 days this year, and there was a window of 91 consecutive days (at least 30 of them falling in this tax year) during which you had no overseas home — or were present in every overseas home you had on fewer than 30 days in the year. | no |
| automaticUkWork | No | Did you work full-time in the UK? Yes if over a 365-day period (falling at least partly in this year) more than 75% of your 3-hour-plus workdays were UK workdays, with at least one such UK workday in this tax year and no significant break from UK work. | no |
| tieAccommodation | No | Accommodation tie A place to live in the UK available to you for a continuous period of 91+ days, in which you spent at least 1 night this year. If it is the home of a close relative, it only counts if you spent 16+ nights there. | no |
| automaticOverseasWork | No | Did you work full-time overseas this year? The statutory test in brief: averaged ≥35 hours/week of overseas work over the year (HMRC applies a precise 5-step hours calculation), no significant break (31+ days without an overseas workday), and fewer than 31 UK workdays of more than 3 hours. Answer yes only if you would clear the full test. | no |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining the test's decision flow, deeming rules for non-midnight days, and the importance of priorResidence. It does not contradict the readOnlyHint (true) or openWorldHint (false) annotations. The tool's behavior is transparently documented, including edge cases and common AI errors.
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 lengthy and contains explanatory asides (e.g., 'the 183-day figure everyone...'). While informative, some redundancy exists (e.g., 183-day myth mentioned twice). Front-loading with purpose is good, but the verbosity could be trimmed slightly without losing clarity.
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?
The description thoroughly explains the test and inputs but does not specify the output format. Since no output schema is provided, the description should clarify what the tool returns (e.g., 'resident'/'non-resident' with details). This gap reduces completeness for an agent needing to parse the result.
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?
All 11 parameters have detailed schema descriptions (100% coverage). The tool description adds value by explaining how parameters interact, e.g., priorResidence determines which ties table applies and enables the country tie. This cross-parameter context enriches understanding beyond individual 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 the tool determines UK tax residency using the full statutory test. It explicitly distinguishes from the 183-day myth and explains the test's structure (automatic tests then sufficient ties). The verb 'decides' and resource 'UK tax residence' are specific, and the explanation of inputs like priorResidence differentiates this from simpler rules.
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 explains when to use this tool (full statutory test) and warns against relying on the 183-day myth. It highlights the critical input (priorResidence) and how it affects the logic. However, it does not explicitly mention sibling tools (e.g., ny_statutory_residence_checker) or provide exclusions for simple day-count queries, but the context implies this is for complex cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uk_universal_credit_taperUK Universal Credit Taper — Does Working More Pay?AWhat an extra shift or pay rise really leaves you on Universal Credit — the 55% taper, the work allowance you may not have, and the pension trick. Computes your Universal Credit payment at your current net earnings and at your earnings plus the raise or extra shift you are weighing — showing exactly how much of the extra you keep after the 55% taper. The taper applies to NET earnings (after tax, NI, and 100% of pension contributions), the work allowance only exists for households with children or limited capability for work, and whether your UC includes a housing element switches that allowance between £427 and £710 a month. General AI gets all three wrong: it tapers gross pay, hands everyone an allowance, and quotes outdated rates.
| Name | Required | Description | Default |
|---|---|---|---|
| household | No | Your household Sets the standard allowance — the base of your maximum UC award. Couples claim jointly and their earnings are combined. | single25 |
| hasChildren | No | Children on the claim? The work-allowance gate. Only households responsible for a child OR with limited capability for work (LCW/LCWRA after a Work Capability Assessment) get a work allowance. Answer "yes" if either applies. Everyone else is tapered from the first pound of net earnings. | yes |
| extraEarnings | No | Extra net earnings you are considering (£) The raise, extra shift, or overtime you are weighing — as extra NET (take-home) pay per month. The tool shows how much of it survives the taper. | |
| otherElements | No | Other UC elements on your statement (£) Child, housing, disability, and carer elements from your UC statement — add them so the taper math starts from your real maximum award. Left at 0, the tool uses only the standard allowance and will understate your actual payment (though the keep-rate on extra earnings is unaffected while UC stays above £0). | |
| housingElement | No | Does your UC include a housing element? The hidden switch. If your UC award includes help with housing costs, your work allowance is £427/month; with no housing element it is £710. Check your UC statement, not your tenancy — it is about what is IN the award. | yes |
| netMonthlyEarnings | No | Your net monthly earnings (take-home) (£) Take-home pay per assessment month — after income tax, National Insurance, AND 100% of your pension contributions. UC tapers NET earnings, not gross: this is the number on your bank statement, and pension contributions reduce it pound-for-pound. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively reveals behavioral details beyond the readOnlyHint annotation: it explains the taper logic, work allowance prerequisites, housing element switching, and that pension contributions reduce net earnings. No contraction 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 dense with information but front-loaded with purpose. Each sentence adds value, though it is longer than necessary. Structure is logical: purpose, key rules, common errors.
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 UK Universal Credit, the description covers essential aspects: taper rate, work allowance conditions, housing element distinction, and net earnings definition. It does not describe output format but the tool's computation is straightforward.
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 detailed parameter descriptions. The tool description adds extra meaning by explaining the overarching logic (e.g., why pension contributions count) and common pitfalls, providing value beyond schema alone.
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 tool's purpose: computing Universal Credit payment at current and increased earnings to show taper impact. It includes specific details like the 55% taper, work allowance conditions, and common mistakes, making the purpose distinct from sibling tools.
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 provides usage context: when considering an extra shift or pay rise and wanting to see UC impact. It lacks explicit guidance on when not to use or alternatives among siblings, but the context is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unit_economicsUnit EconomicsALTV, LTV:CAC, and CAC payback — with the benchmarks that make them mean something. Computes customer lifetime value from ARPU, gross margin, and churn; compares it to acquisition cost; and reads the result against the standard SaaS/subscription benchmarks (3:1 LTV:CAC, sub-12-month payback).
| Name | Required | Description | Default |
|---|---|---|---|
| cac | No | Customer acquisition cost Fully-loaded sales + marketing cost per new customer. | |
| arpu | No | Revenue per customer / month Average monthly revenue per active customer (ARPU). | |
| churn | No | Monthly customer churn (%) Share of customers lost per month. | |
| grossMargin | No | Gross margin (%) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, and the description adds context by explaining the computation and benchmark comparison. It does not contradict annotations and provides additional behavioral insight.
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 key outputs and benchmarks, followed by computation explanation. No fluff or 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?
Lacks details on output format (e.g., numeric values, comparison text), but covers key deliverables and all parameters. Adequate for a read-only calculator with full schema.
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?
Input schema has 100% coverage with descriptions. The tool description adds value by explaining how parameters relate (e.g., LTV from ARPU, gross margin, churn; CAC for ratio), though the schema already covers basics.
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 tool computes LTV, LTV:CAC ratio, and CAC payback, using ARPU, gross margin, churn, and CAC. It distinguishes itself from siblings as the only unit economics tool among many financial calculators.
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 implies use for SaaS/subscription businesses by mentioning standard benchmarks, but it does not explicitly state when to use this tool over siblings like roi or break_even, nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unit_priceUnit PriceAWhich package is actually cheaper per unit. Compares two package options by price per unit and quantifies the savings — the supermarket-shelf math, done honestly.
| Name | Required | Description | Default |
|---|---|---|---|
| qtyA | No | Option A quantity Any unit — grams, sheets, count — as long as both options use the same one. | |
| qtyB | No | Option B quantity | |
| priceA | No | Option A price | |
| priceB | No | Option B price |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the description adds only modest context: it quantifies savings and claims honesty. It does not disclose specifics like rounding or precision, nor does it contradict 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, front-loaded sentence that communicates the core purpose without any wasted words. It is highly concise and to the point.
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 simple tool with well-documented parameters and no output schema, the description is sufficient to convey the purpose. However, it does not hint at the return format (e.g., which package is cheaper, the difference), which could be improved.
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?
The input schema provides full parameter descriptions (100% coverage), so the tool-level description adds no additional meaning beyond summarizing the comparison. Baseline 3 is appropriate.
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 tool's purpose: comparing two package options by price per unit and quantifying savings. It uses specific verbs ('compares', 'quantifies') and a clear resource ('package options'), distinguishing it from sibling financial calculators.
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 implies usage context ('supermarket-shelf math') but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. No exclusions or alternatives are listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us_aca_subsidy_cliffACA Subsidy Cliff Checker (2026)AWhere your 2026 marketplace subsidy sits against the restored 400%-of-poverty cliff — and the clawback risk if income crosses it. For 2026 the enhanced ACA premium tax credits have expired, and the pre-2021 structure is back: below 400% of the federal poverty line your premium is capped at a sliding share of income; one dollar above 400% and the subsidy drops to zero. This tool places your household on that curve — your FPL percentage, your expected contribution, your estimated monthly subsidy, and exactly where the cliff falls in dollars. It also flags the 2026 change most people miss: the cap on repaying advance credits was repealed, so if your year-end income lands over 400% you repay every advance dollar with no limit. The decisive input is your FULL-YEAR 2026 MAGI, reconciled at filing — not the estimate you gave at enrollment.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Which state Alaska and Hawaii have higher federal poverty guidelines, which shifts every threshold up. | contiguous |
| income | No | Expected 2026 household income (MAGI) Your best estimate of full-year 2026 household modified AGI — the number the credit is reconciled against at filing, not just what you report at enrollment. A bonus, capital gain, or extra freelance income counts. | |
| benchmark | No | Benchmark Silver premium (monthly, for your household) The second-lowest-cost Silver plan (SLCSP) for your household — the plan the subsidy is pegged to. Find yours on healthcare.gov’s plan preview or the KFF subsidy calculator; it varies a lot by age and county. The default is a rough mid-range family figure — replace it for an accurate dollar subsidy. | |
| expansion | No | Did your state expand Medicaid? Decides the bottom end. In expansion states, adults under 138% of poverty get Medicaid instead of a marketplace subsidy. In the 10 non-expansion states, adults below 100% FPL fall into the coverage gap — too rich for Medicaid, too poor for a subsidy. *WI covers adults to 100% FPL by waiver. | yes |
| household | No | People in your tax household You, your spouse if filing jointly, and everyone you claim as a dependent — this sets the poverty line the percentage is measured against. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=false. The description does not contradict these; it adds significant behavioral context: the decisive input is full-year MAGI reconciled at filing (not enrollment estimate), and the cap on repaying advance credits was repealed, so crossing the cliff means repaying all advances with no limit.
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 that front-loads the purpose and then dives into details. It is informative but somewhat lengthy (over 200 words). Each sentence adds value, but some redundancy could be trimmed. Still, it remains clear and well-organized.
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 (5 parameters, no output schema), the description is thorough: it explains the 2026 policy change, the cliff behavior, clawback risk, and each input's role. It covers what the tool returns (subsidy, cliff amount, etc.) adequately for an agent to invoke it correctly.
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%. The description adds substantial meaning beyond the schema: e.g., for 'income' it clarifies MAGI definition and that bonuses/capital gains count; for 'benchmark' it explains SLCSP and where to find it; for 'expansion' it explains Medicaid expansion implications. This adds high value for the agent.
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 tool's purpose: to show where a household's 2026 marketplace subsidy falls relative to the restored 400% FPL cliff, including the clawback risk. It specifies the key outputs (FPL%, contribution, subsidy, cliff dollar amount) and distinguishes itself from other sibling tools which are mostly non-ACA financial calculators.
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 explains when to use this tool (for 2026 ACA subsidy cliff assessment) and provides critical context about expired enhanced credits and pre-2021 structure. It does not explicitly state when not to use or directly compare to siblings, but the context and sibling list make it clear this is specialized for the ACA cliff.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us_estate_tax_exemptionUS Federal Estate-Tax Exposure (2026 — the sunset that didn’t happen)AWhether your estate owes federal estate tax under the permanent $15M exclusion — and what the “2026 sunset” answer would have wrongly told you. Computes federal estate-tax exposure under the 2026 rules: a flat $15,000,000 basic exclusion per person, made PERMANENT by OBBBA §70106 — the long-scheduled TCJA sunset to ~$7M never happened, but AI trained before mid-2025 still tells you it did. Accounts for lifetime taxable gifts already made (they consume the unified exclusion) and a deceased spouse’s unused exclusion (DSUE) via portability. Shows the prior-law contrast so you can see exactly how much the “sunset” answer would have overstated your tax, and flags the separate state-level estate taxes (12 states + DC, thresholds from $1M) that the federal all-clear does not cover.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Does your state levy its own estate tax? WA, OR, MN, IL, MD, MA, RI, CT, VT, NY, ME, HI + DC levy their own estate tax with thresholds far below $15M (Oregon starts at $1M). This tool flags it but computes federal only. | no-estate-tax |
| dsueAmount | No | DSUE amount from deceased spouse ($) The unused exclusion ported from your deceased spouse (from their Form 706). Only applies with the “surviving spouse with elected DSUE” status above. | |
| estateValue | No | Gross estate value ($) Everything you own at death — real estate, investments, retirement accounts, business interests, life-insurance proceeds you own. Use today’s value as an estimate. | |
| maritalStatus | No | Marital / portability situation DSUE (deceased spousal unused exclusion) only counts if a Form 706 was filed for the deceased spouse to elect portability — it is not automatic. | single |
| lifetimeGiftsUsed | No | Lifetime taxable gifts already made ($) Cumulative gifts above the annual exclusion ($19,000/recipient in 2026) reported on gift-tax returns. These consume your unified exclusion before death. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavioral traits: read-only calculation, uses $15M exclusion permanently, accounts for gifts and DSUE, shows contrast with prior law, and flags state taxes. Annotations confirm readOnlyHint=true, and no contradictions exist. All relevant behaviors are explained.
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 front-loaded with the main purpose, but includes a lengthy note about AI training. While informative, it could be slightly more concise. Every sentence adds value, but the structure is slightly verbose.
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 no output schema, the description describes the output: federal tax exposure, prior-law contrast, and state tax flag. It covers all 5 parameters and their interactions. Lacks explicit return format, but is sufficient for a calculator tool.
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 tool description adds context on how parameters interact (e.g., lifetime gifts consume unified exclusion) and the significance of the 'sunset' for the exclusion amount. This enhances understanding beyond the 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?
The description clearly states the tool computes federal estate tax exposure under permanent $15M exclusion, accounts for lifetime gifts and DSUE, shows prior-law contrast, and flags state estate taxes. Verb+resource is specific, and sibling tools are other financial calculators, none duplicating this function.
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 explains when to use the tool (to check estate tax under permanent rules) and warns about the outdated 'sunset' misconception. It also notes that state estate taxes are not covered. However, it does not explicitly compare to alternatives within the sibling list, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us_freelance_vs_employeeFreelance vs Employee: the True-Equivalence RateAThe 1099 rate that truly replaces a W-2 salary — solved from taxes, benefits, and billable reality, not a folk multiplier. Rules of thumb ("charge 1.5× your salary hourly") hide what actually changes when you go independent: you pay both halves of Social Security and Medicare, buy the whole health premium instead of the employee share, self-fund the 401(k) match, and bill far fewer hours than you work. One thing runs the other way — the §199A QBI deduction (made permanent in 2025) shelters about 20% of profit from income tax, and models routinely forget it. This tool solves for the 1099 gross at which your net-of-everything genuinely matches the W-2 job, then divides by the hours that realistically bill. All 2026 parameters verified on IRS primary sources; benefit defaults from the KFF 2025 employer survey.
| Name | Required | Description | Default |
|---|---|---|---|
| filing | No | Filing status | single |
| salary | No | The W-2 salary to match Annual gross salary of the job you have or are comparing against. | |
| matchPct | No | Employer 401(k) match (%) Percent of salary your employer contributes. Default: the 2025 Vanguard average (4.7%). The freelancer self-funds this to stay even (deductible via a solo 401(k)). | |
| weeksWorked | No | Working weeks per year After vacation, holidays, and sick time — which no longer come paid. A W-2 job with ~23 paid days off works ≈47 weeks but is paid for 52. | |
| hoursPerWeek | No | Hours worked per week (freelance) | |
| utilizationPct | No | Billable share of worked hours (%) The hidden lever. Sales, admin, invoicing, and bench time don’t bill — professional-services benchmark is ~66%; solo practices vary widely. | |
| employeeHealthCost | No | Your share of health premium as an employee (annual) What comes out of your paycheck for coverage. Default: KFF 2025 average worker contribution for single coverage. | |
| freelanceHealthCost | No | Full health premium as a freelancer (annual) What you would pay for comparable coverage on your own (marketplace or otherwise). Default: KFF 2025 average single premium. Family coverage runs ~$27,000. Deductible against income tax (not SE tax). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is a pure calculation. The description adds behavioral context: it solves for net equality, details tax components (Social Security, Medicare, QBI deduction), benefit defaults, and warns about common omissions. This adds value beyond annotations without 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?
The description is a single, well-structured paragraph that front-loads the main purpose. Every sentence adds value: explaining the tool, why it's needed, key variables, and data sources. It is concise for the complexity without being verbose.
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 8 parameters and no output schema, the description explains the model well, including hidden levers. It hints at the output (1099 gross rate divided by billable hours). However, it could more explicitly describe the output format or breakdown, but the overall completeness is high.
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?
The input schema has 100% coverage with each parameter described. The tool description adds some context (e.g., default matchPct from Vanguard, utilizationPct benchmark) but does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate for high schema coverage.
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 tool computes the 1099 equivalent rate that truly matches a W-2 salary, differentiating it from simple multipliers. The title reinforces this purpose. It is specific about the resource (freelance vs employee compensation) and the verb (solves/compares), distinguishing it from sibling tools that cover other financial calculations.
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 implicitly guides when to use the tool: when comparing freelance vs employee compensation to find the true equivalence, contrasting it with 'rules of thumb'. It does not explicitly state when not to use, but the sibling list includes many other specific tools, so the context is clear. It also mentions data sources for 2026 parameters, adding confidence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us_raise_benefits_cliffIs This Raise Actually a Raise? (2026 benefits cliff)AWhat a raise really adds after EITC, CTC, SNAP, Medicaid, and ACA subsidies move against it — the effective marginal rate no single program shows. For working households on any support program, a raise triggers five simultaneous countercurrents: federal tax and FICA go up, EITC phases out (up to 21¢ per dollar), SNAP tapers (30¢ per net dollar), Medicaid ends abruptly at 138% of the poverty line, and — new for 2026 — the ACA subsidy cliff at 400% FPL is back after the enhanced credits expired 31 Dec 2025. Stacked, effective marginal rates in the $25k–$45k band routinely exceed 60–80%. This tool computes your household’s net resources before and after a raise using the verified 2026 parameter tables, and names each cliff the raise crosses. The decisive inputs are ones most people don’t know matter: whether your state expanded Medicaid, and whether it raised the SNAP gross-income limit.
| Name | Required | Description | Default |
|---|---|---|---|
| bbce | No | SNAP gross-income limit in your state Most states raised the SNAP entry limit to 200% FPL via Broad-Based Categorical Eligibility — whether yours did decides where the SNAP door slams. Check your state SNAP page if unsure. | bbce200 |
| kids | No | Qualifying children (under 17) Sets CTC ($2,200 each), the EITC schedule, and household size for SNAP/Medicaid. | |
| rent | No | Monthly rent / shelter cost Rent plus basic utilities — drives SNAP’s excess-shelter deduction, which changes the benefit materially. | |
| raise | No | The raise (annual amount) Annual value of the raise, extra hours, or second job you are weighing. | |
| filing | No | Filing status Married filing jointly assumes a 2-adult household; single and head-of-household assume 1 adult. | hoh |
| income | No | Current annual earned income (household) Gross W-2 wages for the household before tax. This model treats all income as earned. | |
| premium | No | Marketplace benchmark premium (monthly, optional) The second-lowest-cost Silver plan for your household on healthcare.gov. Enter it to model ACA subsidies and the restored 400% FPL cliff; leave 0 to skip health-coverage math. | |
| expansion | No | Did your state expand Medicaid? The decisive input. In expansion states adults keep Medicaid up to 138% of the poverty line — and lose it in one step above. In the 10 non-expansion states, adults below 100% FPL may get no help at all (the coverage gap). *WI covers adults to 100% FPL by waiver. | yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, which aligns with the tool being a calculator. The description adds behavioral context: it models five simultaneous countercurrents, uses 2026 parameter tables, and names each cliff. This goes beyond what annotations provide.
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, well-structured paragraph. It is front-loaded with the purpose, then explains the mechanism, and ends with key inputs. No unnecessary words; every sentence adds value for a complex tool.
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 (8 parameters, all optional, no output schema), the description provides a thorough overview of purpose, behavioral model, and critical inputs. It does not describe the output format or provide examples, but the rich parameter descriptions compensate.
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 the baseline is 3. The tool description adds overarching model context but does not repeat or significantly enhance the meaning of individual parameters beyond the schema. It mentions 'decisive inputs' but that's already in 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 computes net resources before and after a raise considering benefit cliffs (EITC, CTC, SNAP, Medicaid, ACA). The verb 'computes' is specific to the resource, and it distinguishes itself from siblings by naming the unique programs and the 'benefits cliff' concept.
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 it's for 'working households on any support program' and mentions decisive inputs. It does not explicitly contrast with similar tools (e.g., tax calculators) but the context makes it clear when to use it. Lacking a direct 'when not to use' statement keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us_self_employment_quarterly_taxesSelf-Employment Tax & Quarterly Estimated Payments (2026 1040-ES)AHow much you’ll owe on 2026 freelance income — SE tax, income tax, QBI — and the exact quarterly payment the safe-harbor rules actually require. The first-year freelancer’s tax planner. Computes your 2026 self-employment tax (both halves of Social Security and Medicare — including how W-2 wages eat the $184,500 wage base first), federal income tax with the QBI deduction, and then the number that matters: the quarterly estimated payment §6654 actually requires. That number usually does NOT depend on what you earn this year — the safe harbor is 100% of last year’s tax (110% if prior AGI topped $150k), and if you owed $0 last year, no estimated payments are required at all. General AI reliably misses these mechanics and quotes stale parameters; this uses the 2026 Form 1040-ES figures directly.
| Name | Required | Description | Default |
|---|---|---|---|
| filing | No | Filing status | single |
| w2Wages | No | W-2 wages this year (if side-gigging) Your day-job wages matter twice: they eat the Social Security wage cap first (shrinking your SE tax), and their withholding counts toward the safe harbor. | |
| seProfit | No | Expected 2026 self-employment profit Profit, not revenue — revenue minus business expenses. Entering gross revenue here is the most common way freelancers over-pay. | |
| priorYearTax | No | Total tax on your 2025 return The "total tax" line (line 22-ish) on your 2025 Form 1040. This is the safe-harbor anchor: pay 100% of it (110% if prior AGI > $150k) and you cannot be penalized regardless of what you earn this year — THE thing first-year freelancers don’t know. If you owed $0 in 2025, enter 0. | |
| w2Withholding | No | Federal income tax withheld at the W-2 job (annual) From your pay stubs — federal income tax only. Withholding is treated as paid evenly across the year, which matters for the safe harbor. | |
| priorAgiOver150k | No | Was your 2025 AGI over $150,000? Over $150,000 ($75,000 married filing separately), the prior-year safe harbor rises from 100% to 110% of last year’s tax. | no |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature (consistent with readOnlyHint=true), explains underlying mechanics (wage base interaction, safe harbor), and uses current year parameters. 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?
Front-loaded with key output, each sentence adds value. Slightly verbose but all information is relevant and earns its place.
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 purpose, key constraints, and exceptions (safe harbor). No output schema, but return values implied. Sufficient for agent decision-making.
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?
With 100% schema coverage, the description adds significant extra context for each parameter (e.g., 'profit not revenue', 'safe harbor anchor', 'withholding treated as paid evenly'). Enriches understanding 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?
The description clearly states the tool computes 2026 self-employment tax, income tax, QBI deduction, and required quarterly estimated payments using specific IRS parameters. It distinguishes itself from general AI and sibling tools with detailed mechanics.
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?
Provides explicit guidance on safe-harbor rules, warns common mistakes (gross revenue vs. profit), and explains when estimated payments may not be needed. Does not explicitly mention alternatives among siblings, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us_student_loan_rap_vs_ibrStudent Loan: RAP vs IBR (2026 forced choice)AYour monthly payment and forgiveness timeline under RAP vs IBR — the choice SAVE borrowers are being forced to make. SAVE is dead (vacated, then repealed by the July 2025 law) and the Repayment Assistance Plan (RAP) went live 1 July 2026; PAYE, ICR, and SAVE all end 1 July 2028, when anyone who hasn’t picked is auto-enrolled in RAP. This tool computes your monthly payment under RAP (a %-of-AGI cliff schedule) and IBR (15% or 10% of discretionary income depending on when your first loan was disbursed), the forgiveness horizon for each (30 vs 25/20 years — and 10 tax-free years on PSLF), and the traps: RAP’s payment cliffs at every $10k of AGI, Parent PLUS exclusion, and the new default Tiered Standard plan not counting toward PSLF. General AI still recommends the dead SAVE plan and calls IDR forgiveness tax-free — the ARPA tax exclusion expired 31 Dec 2025.
| Name | Required | Description | Default |
|---|---|---|---|
| agi | No | Adjusted gross income (AGI) From your latest federal return. Married filing jointly: combined AGI of both spouses. Married filing separately: yours only. | |
| pslf | No | Public Service Loan Forgiveness track? PSLF flips the strategy: forgiveness arrives at 120 qualifying payments and is federally TAX-FREE, so the lowest qualifying payment wins. Both RAP and IBR qualify; the new Tiered Standard plan does not. | no |
| rate | No | Average interest rate (%) Weighted average across your loans. | |
| state | No | Where do you live? Alaska and Hawaii have higher poverty guidelines, which lowers IBR payments. | contiguous |
| balance | No | Total loan balance Outstanding principal. Sets the standard-plan comparator, the IBR payment cap, and the interest math. | |
| loanType | No | Loan type Parent PLUS loans are excluded from RAP entirely, and reach IBR only through a consolidation carve-out — the answer changes completely. | regular |
| firstLoan | No | When was your FIRST federal loan disbursed? The decisive input. Your first-ever federal disbursement date sets WHICH IBR you get (15%/25yr vs 10%/20yr) — and loans originated from 1 Jul 2026 can’t use IBR at all. Taking any new loan on/after 1 Jul 2026 also ends IBR eligibility for your old loans. | mid |
| dependents | No | Dependents claimed on your return RAP subtracts $50/month per dependent (IRC §152 dependents claimed on your federal return). Not the same thing as family size. | |
| familySize | No | Family size You + spouse + dependents — sets the poverty-guideline deduction in IBR. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds extensive behavioral details: it computes payments, traps (payment cliffs, Parent PLUS exclusion, Tiered Standard not PSLF-eligible), and the consequences of new loans. 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 long (over 200 words) and dense with detail. While every sentence is informative, it could be more concise and structured (e.g., bullet points). It front-loads the purpose, but the length reduces readability.
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's complexity (9 parameters, no output schema), the description is very complete. It explains context, traps, and what the tool computes (payment, forgiveness horizon). Without an output schema, it adequately describes return values.
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% and each parameter has a description. The tool description adds extra context for some parameters (e.g., 'RAP's payment cliffs at every $10k of AGI' for agi). This goes beyond the schema but does not cover all parameters equally.
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 tool computes monthly payment and forgiveness timeline under RAP vs IBR for SAVE borrowers forced to choose. It uniquely identifies the specific resource and distinguishes from sibling financial calculators by focusing on this niche student loan decision.
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 provides clear context: the tool is for SAVE borrowers forced to choose between RAP and IBR. It mentions related plans (PAYE, ICR, SAVE) and that this is a forced choice, implying when to use. However, it does not explicitly state when not to use or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us_substantial_presence_testUS Substantial Presence Test — the real 183-day ruleAWhether your US days make you a tax resident — the weighted 3-year formula where 122 days a year is enough, and student-visa days may not count at all. Determines US tax residency under the Substantial Presence Test (IRC §7701(b)): 31+ days this year AND a weighted total ≥ 183, counting this year’s days in full, last year’s at one-third, and the year before at one-sixth. The popular "stay under 183 days" rule is wrong — a steady 122 days every year triggers residency. The inputs that actually decide the answer are the ones people don’t know matter: visa status (F/J/M/Q student and J/Q teacher days can be excluded entirely — or suddenly start counting), prior-year day counts, and whether the closer connection exception (Form 8840) is still open — it closes at 183 actual days, and a pending green-card application bars it.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | US immigration status this year The decisive input, and the one almost nobody knows matters. A green card makes you a resident regardless of days. F/J/M/Q student and J/Q teacher visas can make your days NOT count at all — or, past a limit, suddenly count. Most work and visitor statuses (H-1B, L-1, B1/B2, ESTA) have no special rule: pick the first option. | none |
| daysPrior1 | No | Days in the US in the 1st preceding year Last calendar year’s day count, same counting rules. It is weighted at one-third — prior years are why "under 183 this year" is not safe. | |
| daysPrior2 | No | Days in the US in the 2nd preceding year The calendar year before that, weighted at one-sixth. | |
| daysCurrent | No | Days in the US this calendar year Any part of a day counts as a full day — an evening arrival is a day. But first REMOVE days that never count: regular-commuter days from Canada/Mexico, under-24h transits between two foreign points, days as crew of a foreign vessel, and days you could not leave because of a medical condition that arose in the US. | |
| exemptYears | No | Exempt calendar years Only used for student/teacher status; two meanings. Student (F/J/M/Q): the calendar years you have EVER spent as an exempt student, teacher, or trainee — cumulative over your lifetime, any part of a year counts as a full year, and include this year if it applies. Teacher/trainee (J/Q): how many of the 6 PRECEDING calendar years you were exempt. | |
| closerConnection | No | Foreign tax home with a closer connection? If the test is met but you spent under 183 actual days, the closer connection exception can still keep you a nonresident: a tax home in a foreign country for the entire year plus a closer connection to it, claimed on a timely Form 8840. | unsure |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the calculation logic, including the weighted formula, visa exclusions, and the closer connection exception. It warns about common misunderstandings and explains how each parameter affects the result. Annotations indicate readOnlyHint=true, which aligns with this being a calculation tool.
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 lengthy but well-structured, starting with a clear summary and then drilling into details. Every sentence provides useful information, though some redundancy could be trimmed.
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 and lack of output schema, the description covers the test thoroughly, including edge cases and exceptions. It does not explicitly state the output format, but the determination is implied.
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?
The description adds significant value beyond the schema by explaining the practical impact of each parameter (e.g., why visa status is decisive, how to count days, the meaning of exempt years). Schema coverage is 100%, so baseline is 3; the extra context justifies a 4.
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 tool determines US tax residency under the Substantial Presence Test, explains the weighted 3-year formula, and dispels the common myth. The title and description distinguish it from similar tools like UK or NY statutory residence tests.
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 provides context on when the test applies (for US tax residency) and educates about key exceptions like student visas and the closer connection exception. It doesn't explicitly contrast with sibling tools, but the domain is clearly US-specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vatVAT CalculatorAAdd or remove VAT at any rate — including the divide-not-subtract trap. Adds VAT to a net price or extracts it from a gross price at any rate. The extraction direction is where invoices go wrong: removing 20% VAT means dividing by 1.2, not subtracting 20%.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Direction | add |
| rate | No | VAT rate (%) UK 20 · DE 19 · FR 20 · ES 21 · IT 22 · NL 21 · SE 25 · CH 8.1 · AE/SA 5/15 | |
| amount | No | Amount |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the two operational modes (adding VAT to net price or extracting from gross price) and the correct calculation method. It adds behavioral context beyond the readOnlyHint annotation by describing the non-destructive mathematical operations.
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 extremely concise with two sentences, front-loading the core purpose and common pitfall. Every word adds value, 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?
Given the tool's simplicity and full schema coverage, the description is complete. It clearly explains the calculation direction and warns about a common error. No output schema is needed as the result is a straightforward numeric value.
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?
While all parameters have schema descriptions (100% coverage), the description enriches the meaning by explaining the mode direction ('adds VAT to a net price or extracts it from a gross price') and providing country-specific rate examples. It also clarifies the common mistake for the removal operation.
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 tool's purpose: adding or removing VAT at any rate. It uses specific verbs ('Add or remove') and identifies the resource ('VAT'). It distinguishes itself from sibling financial calculators by focusing on VAT calculations.
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 provides clear context on when to use the tool (for VAT calculations) and offers practical guidance on the correct mathematical operation, specifically warning about the 'divide-not-subtract trap'. However, it does not explicitly exclude alternative tools or scenarios.
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.
No comments yet. Be the first to start the discussion!
