Skip to main content
Glama

opentax

by io.github.Invaro
OverviewDiscussionsAdmin

calculate_fiduciary_tax

Compute US federal income tax for an ESTATE or TRUST (Form 1041): the § 1(e) compressed brackets and § 642(b) exemption. Input is taxable income before the exemption, after the §§ 651/661 distribution deduction. Retained capital gains refuse loudly (§ 1(h) trust breakpoints not modeled). Grantor trusts belong on the grantor's individual return via calculate_tax.

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.
targetNorule to derive (default: us.federal.fiduciary.income_tax).
includeProofNoinclude the full proof artifact in the response as `proof` (PROOF-FORMAT v2: every applied rule, input, assumption and rounding, verifiable offline against corpusMerkleRoot; ~200 KB). Default false — the hashes alone are returned.
fiduciaryTypeNoForm 1041 filer type for the § 642(b) exemption: estate ($600), simple trust required to distribute all income currently ($300), or complex trust ($100). Grantor trusts do not file their own tax — use the grantor's individual return.
fiduciaryLongTermGainsNoNet long-term capital gain retained by the estate/trust. Any positive amount REFUSES — the § 1(h) preferential breakpoints for estates and trusts are not modeled. In dollars.
fiduciaryIncomeBeforeExemptionNoThe estate/trust's taxable income BEFORE the § 642(b) exemption but AFTER the §§ 651/661 income-distribution deduction (the DNI machinery is attested by this input). In dollars.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / includeProof
      Added value: +{
+  "description": "include the full proof artifact in the response as `proof` (PROOF-FORMAT v2: every applied rule, input, assumption and rounding, verifiable offline against corpusMerkleRoot; ~200 KB). Default false — the hashes alone are returned.",
+  "type": "boolean"
+}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden. It discloses a key failure mode—'Retained capital gains refuse loudly (§ 1(h) trust breakpoints not modeled)'—and scopes exactly which rules are modeled vs. not. It could additionally state that the tool is a pure computation with no side effects or describe the default response shape, but the disclosed refusal and scope limitations give meaningful behavioral information.

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

Conciseness5/5

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

Three sentences, zero filler. The purpose is front-loaded, followed by the critical input precondition, then the refusal behavior and alternative routing. Every sentence earns its place and the length is appropriate for a tool with complex tax-law scope.

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 complex legal computation with six parameters and no output schema, the description covers the modeled rules, input semantics, exclusions, and alternative tool. The only gap is that it does not state the response format (e.g., that it returns the tax amount plus proof hashes), though the includeProof parameter describes the artifact behavior. This is a minor omission given the tool's clear purpose.

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 baseline is 3 even without parameter detail in the description. The description does reinforce the key semantic of fiduciaryIncomeBeforeExemption ('after the §§ 651/661 distribution deduction') and the refusal condition, but these largely echo the schema's own field descriptions. It adds no meaning that the schema does not already convey.

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 and resource: 'Compute US federal income tax for an ESTATE or TRUST (Form 1041)' and names the exact rules modeled (§ 1(e) brackets, § 642(b) exemption). It differentiates from the sibling calculate_tax by explicitly stating that grantor trusts should use calculate_tax instead, so an agent can disambiguate without opening schemas.

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

Usage Guidelines5/5

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

It specifies the exact input precondition: 'taxable income before the exemption, after the §§ 651/661 distribution deduction.' It gives an explicit when-not-to-use case with a named alternative ('Grantor trusts belong on the grantor's individual return via calculate_tax') and a hard exclusion for retained capital gains, which 'refuse loudly.' These are clear usage boundaries beyond what the schema provides.

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

All opentax toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources