Skip to main content
Glama

compute_return

Compute the COMPLETE Form 1040 bottom-line set in one call — the 17 lines that determine the return (1a, 9, 10, 11, 12e, 15, 16, 17 AMT, 19, 22, 23, 24, 25d, 27a, 28, 32, 33, 34/37), each whole-dollar rounded by the engine. Takes the SAME input as calculate_tax (prefer the documents block: transcribe W-2/1099-R/SSA-1099 boxes and dependent birth dates — SSA-1099s are first-class, box 5 and box 6 are summed for you; the tool derives ages, classifications, Part IV withholding, and penalties deterministically). Never assemble return lines by hand — this tool is the return. TRANSCRIPTION CONVENTIONS: (1) a PRIOR-YEAR Form 1040 in the file supplies CONTINUING conditions the current-year interview omits — the 'Someone can claim: You as a dependent' checkbox and the blindness boxes carry forward unless the current-year data contradicts them; (2) COMMUNITY PROPERTY: do NOT split income 50/50 between MFS spouses when they lived apart all year with no transfers (§ 66(a) allocates earned income to the earner) or when a written separation agreement ended the community — transcribe each document to its named earner; never invent a Form 8958 split the intake does not request; (3) bonus depreciation for assets placed in service 1/1-1/19/2025 is 40% (§ 168(k) pre-OBBBA phase-down; 100% only for property ACQUIRED after 1/19/2025).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asOfNoREQUIRED for computation: the law-in-force date — use the intended tax year's year-end (e.g. "2025-12-31" for TY2025). Omitting it is an error, never a default.
stateNostate taxable income for the state tax targets (us.ca/us.va/us.il/us.ny/us.oh/us.nc/us.ga/us.md/us.mo/us.wi/us.mn income_tax; parameters via lookup_tax_parameter)
filingNowho is filing: status, age/blindness, dependency, student status
incomeNowages, interest, capital gains, unemployment, foreign earned income
targetNorule to derive (default: net tax; balance due when payments_estimates.federalTaxWithheld is given). Determinations: us.federal.eligible.tips_deduction, us.federal.estimated.quarterly_payment, us.federal.estimated.safe_harbor_met
creditsNoCTC/ODC counts, dependent care, saver's, adoption, education
itemizedNoSchedule A: SALT, mortgage, medical, charitable
documentsNoRAW document transcription (preferred over hand-mapped facts): W-2 boxes, 1099-R boxes/codes, SSA-1099 boxes, dependents' birth dates. SSA-1099s are first-class: box 5 sums into socialSecurityBenefits and box 6 into withholding, so the § 86 taxable-benefits worksheet runs on the transcribed total instead of a hand-mapped guess. The tool derives wages/withholding (incl. Form 8959 Part IV), box-3/5 wage coordination, dependent classifications, age facts, and early-distribution penalties deterministically — and errors if the same value is also passed as a hand-mapped fact.
kiddie_taxNoForm 8615 inputs for a child subject to § 1(g)
retirementNosocial security, IRA/pension distributions, early-distribution penalty
adjustmentsNoIRA/HSA contributions, student-loan and car-loan interest
investor_amtNoAMT preferences (ISO spread) and § 1202 QSBS exclusion
tips_overtimeNo§ 224 tips and § 225 overtime deductions (OBBBA)
healthcare_ptcNo§ 36B premium tax credit / Form 1095-A reconciliation
rentals_passiveNoSchedule E rentals/royalties + § 469 passive-loss netting (Form 8582 via us.federal.passive_loss_allowed)
self_employmentNoSchedule C / K-1, QBI inputs, SE deductions, home office
household_employerNoSchedule H nanny/household-employee taxes
payments_estimatesNowithholding, prior-year safe harbor, annualized installments

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden and delivers: whole-dollar rounding, deterministic derivation of 'ages, classifications, Part IV withholding, and penalties', first-class SSA-1099 summation, and a detailed TRANSCRIPTION CONVENTIONS section covering prior-year carry-forward conditions, § 66(a) community-property allocation, and § 168(k) bonus depreciation. It does not describe the output structure beyond the line list, but the derivation and input-handling behaviors are well disclosed.

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

Conciseness3/5

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

The description is dense and purpose-front-loaded, but runs roughly 700 words. The TRANSCRIPTION CONVENTIONS block, while useful, mixes genuinely behavioral guidance (community-property rules, prior-year carry-forward) with a substantive depreciation-rate rule (§ 168(k) 40% vs 100%) that reads more like tax-law reference than a transcription instruction. It earns its sentences for the most part, but the depreciation tangent and verbose prose keep it from being tightly concise.

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

Completeness4/5

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

Given the extreme complexity — 18 top-level parameters with deeply nested objects (state, filing, documents, self_employment, rentals_passive, etc.) and 100% schema coverage — the description appropriately focuses on the highest-value workflow guidance: computing all 17 return lines, preferring the documents transcription block, and the transcription conventions. No output schema exists, and the description names the output lines rather than describing their structure, a minor gap, but for a computation tool of this scale the coverage is strong.

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

Parameters4/5

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

Schema coverage is 100% with exhaustive per-parameter descriptions, so the baseline is 3, but the description adds genuine selection guidance: 'prefer the documents block' over hand-mapped facts, the requirement that asOf is 'REQUIRED for computation... Omitting it is an error, never a default', and the transcription conventions that tell the agent how to populate parameters (community-property no-split, SSA box summing, no invented Form 8958 splits). This adds workflow value beyond the schema's field-level documentation.

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

Purpose5/5

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

The description opens with a specific verb+resource: 'Compute the COMPLETE Form 1040 bottom-line set in one call' and enumerates the exact 17 lines (1a, 9, 10... 34/37), making the scope unambiguous. It distinguishes itself from calculate_tax by addressing input sharing ('Takes the SAME input as calculate_tax') and asserts its primacy ('Never assemble return lines by hand — this tool is the return'), clearly separating it from the federal compute siblings.

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

Usage Guidelines4/5

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

The description gives clear contextual guidance on input strategy ('prefer the documents block: transcribe W-2/1099-R/SSA-1099 boxes and dependent birth dates') and a firm directive against manual assembly. It references calculate_tax as sharing input, implying alternate compute paths, but does not explicitly state when to use this tool versus compute_state_return or calculate_business_tax, nor provide an explicit 'when not to use' exclusion list.

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.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: calculate_tax handles individuals, calculate_business_tax handles entities, calculate_fiduciary_tax handles estates/trusts, compute_return produces the complete federal return, compute_state_return handles state returns, and the remaining tools cover specific lookups (parameters, rules, facts, dependencies, cliffs, tipped occupations) or verification. Even with overlapping domains (explain_rule, lookup_tax_parameter, search_tax_rules, verify_fact, verify_tax_claim), their roles are sharply delineated.

Naming Consistency4/5

Tool names follow a clear pattern: compute_return, compute_state_return, calculate_tax, calculate_business_tax, calculate_fiduciary_tax, determine_dependent, explain_rule, find_tax_cliffs, is_tipped_occupation, list_input_facts, lookup_tax_parameter, search_tax_rules, verify_fact, verify_tax_claim. Most use verb_noun (calculate_tax, lookup_tax_parameter, search_tax_rules, verify_fact). Minor deviations: compare_filing_statuses and compute_return use adjective/noun phrases rather than verb_noun, but they're still readable and follow the 'compute/calculate' theme.

Tool Count5/5

15 tools is well-scoped for a comprehensive tax computation server. Each tool covers a distinct aspect of tax law (federal individual, business, fiduciary, state returns, dependency, rule lookup, parameter lookup, validation, cliff detection, fact verification, search). No tool feels redundant, and the count supports the ambitious scope without bloating.

Completeness5/5

The tool surface covers the full tax workflow: input discovery (list_input_facts), computation (calculate_tax, calculate_business_tax, calculate_fiduciary_tax, compute_return, compute_state_return), dependency determination (determine_dependent), rule/parameter lookup (explain_rule, lookup_tax_parameter, search_tax_rules), verification (verify_fact, verify_tax_claim), and specialized analysis (find_tax_cliffs, is_tipped_occupation, compare_filing_statuses). There's no obvious gap; the only potential missing feature is payroll tax computation, but that's outside the stated domain of income tax.

Resources