Skip to main content
Glama

QuantCalc Retirement Engine

Standard deduction piece by piece, and whether itemizing beats it (2026 or 2027)

standard_deduction_vs_itemizing
Read-only

Returns the 2026 or 2027 standard deduction piece by piece — the basic amount, the additional amount for 65 or older and blind, a dependent's limit, the married-filing-separately rule — free; and, with a connected QuantCalc PRO licence or Tax Season Pass, the senior deduction after its phase-out, the itemized total (SALT cap, mortgage interest, charity and medical floors, the IRC 68 limit), the non-itemizer charitable deduction, the federal tax both ways and which is lower, from QuantCalc's federal tax API run twice. The amounts are the website's standard deduction pages' own figures (2027: the IRS's published amounts, Rev. Proc. 2026-35). Not tax advice.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "filing_status": "<filing_status>",
      "age": "<age>"
    },
    "name": "standard_deduction_vs_itemizing"
  }
}

Input Schema

NameRequiredDescriptionDefault
ageYesYour age on December 31 of the tax year (0-120): 65 or older adds the additional amount and the senior deduction.
blindNoYou are blind. Default false.
wagesNoYour wages (a dependent's earned income). Default 0.
tax_yearNo2026 (default) or 2027. 2027: the IRS's published 2027 standard deduction, additional amounts and dependent limit (Rev. Proc. 2026-35) and the tax on the published 2027 brackets. Stated in the result.
dependentNoNot on a joint return: someone else can claim you as a dependent (the basic amount is limited, IRC 63(c)(5)). Default false.
spouse_ageNoJoint return only: the spouse's age. Default: the same as age.
spouse_blindNoJoint return only: the spouse is blind. Default false.
spouse_wagesNoJoint return only: the spouse's wages. Default 0.
filing_statusYesFiling status: single, married filing jointly (mfj), married filing separately (mfs) or head of household (hoh).
charitable_cashNoCash gifts to charity. Default 0.
social_securityNoGross Social Security benefits. Default 0.
spouse_itemizesNomfs only: your spouse itemizes on a separate return, so you must too.
medical_expensesNoMedical and dental expenses. Default 0.
mortgage_interestNoHome mortgage interest. Default 0.
retirement_incomeNoTaxable pension, annuity and IRA income. Default 0.
real_estate_tax_paidNoProperty tax paid. Default 0.
state_local_income_tax_paidNoState and local income tax paid. Default 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / filing_status / description
      Previous value: -"2026 filing status: single, married filing jointly (mfj), married filing separately (mfs) or head of household (hoh)."New value: +"Filing status: single, married filing jointly (mfj), married filing separately (mfs) or head of household (hoh)."
    • changedInput schema / properties / tax_year / description
      Previous value: -"2026 (default) or 2027. 2027 uses the 2027 pages' figures (projected until the IRS publishes them) and the engine's 2027 federal return (the IRS's published 2027 brackets, Rev. Proc. 2026-35); stated in the result."New value: +"2026 (default) or 2027. 2027: the IRS's published 2027 standard deduction, additional amounts and dependent limit (Rev. Proc. 2026-35) and the tax on the published 2027 brackets. Stated in the result."
  2. Changed1 schema field changed
    • changedInput schema / properties / tax_year / description
      Previous value: -"2026 (default) or 2027. 2027 uses the 2027 pages' figures (projected until the IRS publishes them) and the engine's projected federal return; stated in the result."New value: +"2026 (default) or 2027. 2027 uses the 2027 pages' figures (projected until the IRS publishes them) and the engine's 2027 federal return (the IRS's published 2027 brackets, Rev. Proc. 2026-35); stated in the result."
  3. Added

TDQS

A3.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint; the description adds a licence/auth requirement that changes the returned payload, the data provenance (the site's own standard deduction pages; 2027 from IRS Rev. Proc. 2026-35), the computation method (QuantCalc's federal tax API run twice), and an explicit 'Not tax advice' caveat. That is substantive behavioral context not derivable from the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the deliverable and every clause carries information (figures, licensing, provenance, limits), so nothing is wasted. It is nonetheless a single run-on sentence stitched with em dashes and semicolons, which makes it harder to scan than a structured free/paid split would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 17-parameter tool with no output schema, the description does the heavy lifting by enumerating the returned figures (standard deduction components, itemized total components, tax both ways, the lower one) and the two tiers of results. What is left vague is the boundary between outputs, e.g. whether itemized inputs are required for the comparison or what happens to the itemized figures when no licence is connected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 17 parameters including the conditional ones (spouse_age defaults to age, mfs-only spouse_itemizes, tax_year 2026/2027). The description restates output components and rules (IRC 63(c)(5), IRC 68, SALT cap) rather than adding new meaning to specific parameters, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete resource (the 2026/2027 standard deduction broken into basic amount, age/blind additional amount, dependent limit, MFS rule) and a concrete secondary output (itemized total, federal tax computed both ways, and which is lower), so the verb-plus-resource is unambiguous. It does not explicitly name a sibling it is not, e.g. calculate_2026_income_tax, so it stops short of the top band.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It makes the free-versus-paid split explicit ('free; and, with a connected QuantCalc PRO licence or Tax Season Pass...'), which is real usage guidance about what you get when you call it. However, it never says when to pick this over calculate_2026_income_tax or estimate_2026_tax_return, and no exclusion conditions are stated beyond the licensing gate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.