Federal tax estimate, deadlines, FBAR/8938/3520 checks, §7702 screen, inherited-stock step-up.
Scored across 6 tools
Each tool targets a clearly distinct task: threshold checking, cost comparison for missed filings, federal tax estimation, inheritance step-up, deadline listing, and §7702 insurance screening. The two foreign-compliance tools (check_foreign_reporting_requirements vs compare_offshore_compliance_options) are related but their descriptions make the boundary explicit (threshold screening vs remediation cost comparison).
All six tools follow a consistent snake_case verb_noun pattern (check_, compare_, estimate_, estimate_, list_, screen_) with clear action-oriented prefixes. No mixed conventions or vague verbs.
Six tools is well-scoped for a tax estimation server, each covering a distinct tax-planning concern without redundancy. No tool feels like filler or overlap.
The surface covers a broad set of tax planning scenarios (income tax, foreign reporting, offshore compliance, estate step-up, deadlines, insurance screening) with clear scope notes. Some adjacent topics like state tax, gift/estate tax returns, or capital-gains planning are absent, but these are plausibly out of scope for an estimator.
Checks a U.S. person's foreign-asset figures against the filing thresholds for FBAR (FinCEN Form 114), Form 8938 (FATCA) and Form 3520 (gifts or bequests from a foreign individual or estate). Only the forms whose figures are given are checked. Thresholds only: it does not decide which accounts or assets count; the descriptions of each input say what to include.
| Name | Required | Description | Default |
|---|---|---|---|
| lives_abroad | No | Form 8938: true if the taxpayer meets the bona fide residence or physical presence test abroad (higher thresholds). | |
| filing_status | Yes | Federal filing status. | |
| foreign_gifts_received | No | Form 3520: total gifts and bequests received in the year from nonresident alien individuals or foreign estates, USD. | |
| specified_foreign_assets_max | No | Form 8938: the highest value of specified foreign financial assets at any time in the year, USD. | |
| foreign_accounts_max_aggregate | No | FBAR: the highest combined value of all foreign financial accounts at any time in the year, USD. | |
| specified_foreign_assets_year_end | No | Form 8938: value of specified foreign financial assets on the last day of the year, USD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, read-only, idempotent operation, so the description correctly focuses on behavior beyond that: the check is partial (only forms with supplied figures), and it evaluates thresholds only rather than classifying assets. It does not describe the return format, but the safety profile is fully covered 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?
Three tight sentences with no waste: the purpose and form coverage come first, followed by the partial-check condition and the thresholds-only caveat. Every clause carries decision-relevant 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 six-parameter threshold checker with fully documented inputs and a read-only annotation profile, the description covers purpose, scope limits, and input-selection behavior. It omits what the result looks like (which thresholds were triggered), but with no output schema this is a minor gap rather than a blocking one.
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%, and each parameter already documents its form mapping, units (USD), and timing (year-end vs. any time in the year), so the schema carries the semantic load. The description only adds a pointer ('the descriptions of each input say what to include'), which is helpful framing but not new parameter meaning.
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 names a specific verb ('Checks') and a precise resource ('foreign-asset figures against the filing thresholds'), and enumerates the three distinct forms covered (FBAR/FinCEN 114, Form 8938, Form 3520). This clearly separates it from siblings like estimate_federal_tax or list_federal_tax_deadlines.
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 states an explicit usage condition ('Only the forms whose figures are given are checked') and a clear exclusion ('it does not decide which accounts or assets count'). It stops short of naming an alternative sibling for when this tool is the wrong choice, but the scope boundaries are well defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a U.S. taxpayer who missed FBAR or Form 8938 filings or left foreign income unreported, estimates and compares the cost of three catch-up paths: A) delinquent information return procedures (only when no income went unreported), B) amended returns with tax and interest plus a reasonable-cause statement (with the statutory penalty exposure if reasonable cause is rejected), and C) the Streamlined Domestic Offshore Procedures (tax, interest and the 5% penalty). Also adds the 1% Form 720 excise tax on premiums paid to foreign insurers. Tax years 2019–2025. Assumes non-willful conduct; it does not decide eligibility.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | One entry per affected tax year. | |
| filing_status | Yes | Filing status used on the original returns. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the modeling assumptions and boundaries: non-willful only, tax years 2019–2025, reasonable-cause rejection risk included, and an explicit disclaimer that eligibility is not determined. It stops short of noting precision/rounding caveats on the estimates.
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?
One dense but well-ordered paragraph: it front-loads the taxpayer scenario and the three options, then adds the excise add-on and year/assumption caveats. Every clause carries information, though the option list could be scanned more easily if broken out.
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 carries the burden of explaining what comes back, and it does so by naming the three cost comparisons and the add-on excise. Scope (years) and assumptions (non-willful) are stated, leaving only minor gaps like result formatting or whether both paths are always returned.
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 self-documenting, so the baseline is 3, but the description adds meaningful semantics by tying inputs to outputs – premiums drive the 1% Form 720 excise, unreported asset values drive the Streamlined 5% penalty, and path B includes statutory penalty exposure. This helps an agent understand why those fields matter.
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?
States a specific verb and resource ('estimates and compares the cost of three catch-up paths') and then enumerates exactly what each path computes (A delinquent procedures, B amended returns with reasonable cause, C Streamlined Domestic). This is clearly distinguishable from siblings like estimate_federal_tax or screen_foreign_life_insurance_7702.
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?
Gives real eligibility context: option A applies 'only when no income went unreported', the whole model 'assumes non-willful conduct', and it explicitly says it 'does not decide eligibility'. It doesn't name sibling tools or say when a different tool is the better first call, so it lands 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.
Estimates a year's U.S. federal income tax plus self-employment tax, the refund or balance due after withholding and estimated payments, marginal and effective rates, a bracket-by-bracket breakdown and, when prior-year figures are given, the safe-harbor quarterly estimated payment. Also answers 'how much more can I earn, withdraw from a 401(k) or convert to a Roth IRA before the next bracket': the room left in the current bracket, the room before qualified dividends / long-term gains lose the 0% rate, and the tax on a planned extra amount. Uses the standard deduction (with the age-65+ addition) unless larger itemized deductions are given; the 2025–2028 $6,000 senior deduction with phase-out; qualified dividends and long-term gains at 0%/15%/20%; child tax credit with phase-out; Social Security wage base and Additional Medicare tax. Federal only: no state tax, AMT, NIIT, QBI deduction, IRMAA or other credits.
| Name | Required | Description | Default |
|---|---|---|---|
| tax_year | Yes | Tax year: 2025 or 2026. | |
| w2_wages | No | W-2 wages (Social Security / Medicare wages), USD; reduces the self-employment Social Security tax room. 0 if none. | |
| total_income | Yes | Total income for the year before deductions, USD: wages, interest, dividends, other income and self-employment profit together. | |
| filing_status | Yes | Federal filing status. | |
| prior_year_agi | No | Last year's adjusted gross income, USD (decides 100% vs 110% safe harbor). | |
| federal_withholding | No | Federal income tax withheld for the year (W-2 box 2, 1099 withholding), USD. | |
| itemized_deductions | No | Total itemized deductions (Schedule A), USD. Used only when larger than the standard deduction. | |
| qualifying_children | No | Children under 17 who qualify for the child tax credit. | |
| planned_extra_income | No | What-if: extra ordinary income being considered for the year (401(k) or IRA withdrawal, Roth conversion, bonus), USD, NOT included in total_income. Returns the tax it adds and the marginal rate after. | |
| prior_year_total_tax | No | Last year's total federal tax, USD. Give it to get the quarterly safe-harbor payment. | |
| self_employment_profit | No | Net self-employment profit (Schedule C), USD. Already included in total_income; used for self-employment tax. | |
| estimated_payments_made | No | Federal estimated tax payments already made for this year, USD. | |
| taxpayers_age_65_or_older | No | Taxpayers on the return who are 65 or older by year end (0, 1 or 2): adds the age-65+ standard deduction and the $6,000 senior deduction (2025–2028). | |
| qualified_dividends_and_long_term_gains | No | Qualified dividends (1099-DIV box 1b) plus net long-term capital gains, USD. Part of total_income; taxed at 0%/15%/20% stacked on top of ordinary income. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral substance: which deduction is applied by default, the what-if extra-income path, and an explicit list of unsupported features (AMT, NIIT, IRMAA, credits) that sets accuracy expectations. It stops short of discussing estimation caveats or year-of-law 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?
Front-loaded with the core purpose, then the what-if capability and scope caveats. The first sentence is a long run-on enumerating outputs, but the density is justified by a 14-parameter, multi-output tax tool; there is little padding.
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 carries the return-value burden and does so explicitly: refund/balance due, marginal and effective rates, bracket-by-bracket breakdown, safe-harbor quarterly amount, and bracket/0%-rate room. Combined with the stated limitations, an agent has everything needed to invoke it correctly and interpret the absence of unsupported features.
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 every parameter already carries its own documentation, which sets the baseline at 3. The prose reinforces cross-parameter semantics (prior-year figures driving the safe harbor, self-employment profit already inside total_income, planned_extra_income excluded from total_income), but adds little beyond what the schema fields already state.
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?
States a specific verb ('Estimates') and resource (U.S. federal income tax plus self-employment tax) and enumerates the concrete outputs (refund/balance due, marginal and effective rates, bracket breakdown, safe-harbor payment). The scope is unmistakably distinct from the siblings (foreign reporting, offshore compliance, inheritance step-up, deadlines), so no sibling confusion.
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 usage context: it positions itself as both a return estimator and a bracket-room what-if calculator, and gives explicit scope exclusions ('Federal only: no state tax, AMT, NIIT, QBI, IRMAA...'). It does not, however, name a sibling or state when another tool should be preferred, so it falls short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For U.S.-listed stocks, ETFs, mutual funds or crypto held at someone's death (directly, in an estate or in a revocable living trust), estimates the value on the date of death from public market prices, the IRC §1014 step-up in cost basis and the capital-gains tax the heirs avoid (15%–23.8%), plus the dates that matter: the §2032 alternate valuation date, the Form 706 due date and the last day for a portability election (Rev. Proc. 2022-32). Valuation follows Treas. Reg. §20.2031-2(b) (mean of high and low, weekend and no-trade days weighted) and §20.2031-8(b) for funds. Up to 25 holdings. An estimate for planning, not a signed valuation a broker or the IRS will accept; the reply says where to get one.
| Name | Required | Description | Default |
|---|---|---|---|
| holdings | Yes | Holdings at the date of death. | |
| date_of_death | Yes | Date of death, YYYY-MM-DD (must be before today). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: the valuation methodology (Treas. Reg. §20.2031-2(b) mean of high/low, §20.2031-8(b) for funds), the 15%–23.8% capital-gains range, the 25-holding cap, and the accuracy disclaimer with a pointer to a signed valuation.
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?
Dense but front-loaded: the asset scope and the core estimate come first, followed by methodology, limits and disclaimer. Every clause carries information, though the run-on sentence structure could be split 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?
With no output schema, the description still explains what the reply contains (the §2032 alternate valuation date, Form 706 due date, portability election deadline) and what it does not (a signed valuation). Nothing an agent needs to call this correctly is missing.
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 shares, symbol, asset_type, original_cost and date_of_death. The description only restates the asset-type scope and the 25-holding limit, adding little syntax or format detail beyond the structured fields.
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?
States a specific verb and resource ('estimates the value on the date of death ... the IRC §1014 step-up in cost basis and the capital-gains tax the heirs avoid') with clear scope (U.S.-listed stocks, ETFs, mutual funds, crypto held at death). No sibling tool touches inheritance valuation, so the agent can route to it unambiguously.
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?
Specifies the qualifying assets and ownership contexts ('directly, in an estate or in a revocable living trust') and draws a boundary ('an estimate for planning, not a signed valuation a broker or the IRS will accept'). It doesn't name an alternative tool, but no sibling provides an overlapping capability, so there is little to exclude.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists upcoming U.S. federal tax deadlines with days remaining: quarterly estimated payments (1040-ES), individual return and extension dates, and optionally S-corporation, partnership and C-corporation return and estimated-tax dates. Dates are already moved off weekends and holidays.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of deadlines to return. | |
| from_date | No | List deadlines on or after this date (YYYY-MM-DD). Default: today (U.S. Central). | |
| include_business | No | Also list business return and C-corporation estimated tax dates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety bar is low. The description adds genuinely new behavioral context: dates are pre-adjusted off weekends and holidays, and each entry carries days remaining. It does not discuss limits/pagination behavior, but it exceeds annotation coverage.
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 core purpose, and every clause carries information (content, optional scope, date-shifting behavior). No filler or restatement of the title.
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 describe the return shape ('with days remaining') and date handling, which is the key thing an agent needs. Minor gaps remain around result ordering and limit interaction, though these are partly inferable.
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 description does add some meaning beyond the schema by enumerating which entity types count as 'business' dates (S-corp, partnership, C-corp), but limit and from_date semantics are left entirely to 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?
States a specific verb ('Lists') and resource ('upcoming U.S. federal tax deadlines') and enumerates the contents: quarterly estimated payments, individual return/extension dates, and optional business dates. This is clearly distinguishable from siblings like estimate_federal_tax (calculation) or check_foreign_reporting_requirements (foreign compliance screening).
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 establishes clear context for what the list covers and when the business-date content appears ('optionally S-corporation, partnership and C-corporation' tied to include_business), but never names an alternative tool or states when not to use this one. Useful scope-setting without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preliminary screen of whether a non-U.S. savings-type life insurance policy (for example a Hong Kong whole-life or savings plan) meets the U.S. definition of life insurance under IRC §7702, using the cash value accumulation test (CVAT) and the cash value corridor, from the policy's cash value table. A policy that fails is taxed each year on its inside growth (§7702(g)). Values in any one currency (ratios do not depend on currency). Does not check the guideline premium limit.
| Name | Required | Description | Default |
|---|---|---|---|
| sex | Yes | Insured's sex (mortality table). | |
| issue_age | Yes | Insured's age at issue, completed years. | |
| issue_year | Yes | Calendar year the policy was issued. | |
| policy_years | Yes | Rows from the policy's illustration / cash value table; a few years such as 1, 5, 10, 20 are enough. | |
| increasing_benefit_rule | No | For policies whose death benefit grows by a fixed rate: lets years without a death_benefit be computed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds substantial non-obvious context: the mathematical method (CVAT + corridor), the downstream tax consequence of failure under §7702(g), and the currency-independence of the ratios. It omits any statement of what the response actually contains.
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 dense sentences, each earning its place: purpose/method, tax consequence, currency caveat, scope limit. The core purpose is front-loaded before any qualifiers, so the agent grasps the tool in the first clause.
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 actuarial tool with a nested schema and no output schema, the definition is largely self-sufficient about method, scope, and limitations. The one real gap is that, absent an output schema, it never states what the screen returns (pass/fail per year, taxable amount), leaving the return shape to inference.
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 5 parameters, including a nested policy_years array and an increasing_benefit_rule object, so the schema carries the full parameter burden. The description only lightly gestures at inputs ("from the policy's cash value table," "any one currency") and says nothing about increasing_benefit_rule, so the baseline 3 applies.
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?
Names a specific verb (screen), a precise resource (non-U.S. savings-type life insurance policy), and the exact regulatory test applied (IRC §7702 CVAT plus cash value corridor). An agent can distinguish this from every sibling (reporting, compliance comparison, tax estimation, deadline listing) without opening a schema.
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?
Establishes the context clearly ("preliminary screen," computed from the policy's cash value table) and gives an explicit scope exclusion ("Does not check the guideline premium limit"), which tells the agent when this tool is insufficient. It does not, however, name an alternative tool for the excluded check or state positive conditions for choosing it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
estimate_federal_tax3 fields changedInput schema / properties / planned_extra_incomeAdded value: +{
+ "description": "What-if: extra ordinary income being considered for the year (401(k) or IRA withdrawal, Roth conversion, bonus), USD, NOT included in total_income. Returns the tax it adds and the marginal rate after.",
+ "maximum": 10000000000,
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / qualified_dividends_and_long_term_gainsAdded value: +{
+ "default": 0,
+ "description": "Qualified dividends (1099-DIV box 1b) plus net long-term capital gains, USD. Part of total_income; taxed at 0%/15%/20% stacked on top of ordinary income.",
+ "maximum": 10000000000,
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / taxpayers_age_65_or_olderAdded value: +{
+ "default": 0,
+ "description": "Taxpayers on the return who are 65 or older by year end (0, 1 or 2): adds the age-65+ standard deduction and the $6,000 senior deduction (2025–2028).",
+ "maximum": 2,
+ "minimum": 0,
+ "type": "integer"
+}estimate_inheritance_step_upcheck_foreign_reporting_requirementscompare_offshore_compliance_optionsestimate_federal_taxlist_federal_tax_deadlinesscreen_foreign_life_insurance_7702US federal + state quarterly estimated tax estimates, SE tax, and quarterly payment due dates.
Read-only US tax reference for notices, deadlines, filing screens, and clearly labeled estimates.
Retirement Monte Carlo, tax-aware withdrawal and Roth-conversion plans, and a 2026 return estimate.
US small-biz & foreign-LLC filing deadlines: FinCEN BOI, IRS 5472, franchise tax, 1099 (sourced).
Add one secure layer between your agents and this server.