US federal + state quarterly estimated tax estimates, SE tax, and quarterly payment due dates.
Scored across 2 tools
The two tools target clearly different things: one performs a tax computation from inputs, the other returns a static schedule of due dates. There is no plausible way to confuse them, and each description states its output unambiguously.
Both names follow the same camelCase verb_noun pattern (estimateQuarterlyTax, getPaymentCalendar). One is an estimate/action verb and the other a get/fetch verb, but the convention is uniform and predictable.
Two tools is thin even for a narrow single-purpose calculator server. The surface covers the two obvious needs, but a third tool (e.g., listing supported states/filing statuses or annualized summary) would likely be expected.
The domain is quarterly estimated tax estimation, and the surface covers both the calculation and the deadline lookup, which are the two core workflows. Minor gaps remain: no tool to enumerate supported states, tax years, or filing statuses, and no way to get federal-only or state-only breakdowns.
Estimate US federal + state quarterly estimated tax payments for a self-employed person. Given annual Schedule C net profit, filing status, two-letter US state code, tax year, and whether the §199A QBI deduction applies, returns annual federal income+SE tax, rough state income tax, SE tax, combined total, the per-quarter installment amount (4 equal payments), and a deep link that opens the site calculator pre-filled with these inputs. Read-only calculation; no data is stored.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter US state code, e.g. "CA". | |
| taxYear | Yes | Tax year for the federal rules applied. | |
| netProfit | Yes | Annual self-employment net profit in USD. | |
| includeQBI | No | Whether the §199A qualified business income deduction applies (default true). | |
| filingStatus | Yes | Federal filing status: single, mfj (married filing jointly), hoh (head of household). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds a genuinely non-redundant behavioral fact: 'no data is stored,' which tells the agent the call is stateless and safe to repeat. It stops short of stating accuracy limits or rate limits, so it is not fully exhaustive.
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?
Purpose and inputs are front-loaded in the first sentence, with outputs and the read-only guarantee following. It is dense but every clause carries information; the run-on structure of the first sentence is the only mild weakness.
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 thoroughly: annual federal income+SE tax, rough state tax, SE tax, combined total, per-quarter installment, and the pre-filled deep link. Combined with the stated statelessness, an agent has everything needed to call and interpret 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?
Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning: netProfit is tied to 'annual Schedule C net profit' and includeQBI is tied to the '§199A QBI deduction,' semantics the schema's terse prose does not spell out. The remaining parameters (filingStatus, taxYear, state) are only restated.
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 (Estimate) and resource (US federal + state quarterly estimated tax payments for a self-employed person), then enumerates the exact inputs it consumes. An agent can immediately tell this is a calculator, clearly distinct from the sibling getPaymentCalendar even without an explicit contrast.
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 implies its domain (quarterly estimates for a self-employed filer) and lists the prerequisite inputs, but never states when to use it versus getPaymentCalendar or when it is inappropriate (e.g. W-2 employees, prior-year true-ups). Usage is inferred rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the 4 federal quarterly estimated tax payment due dates for a tax year (Apr/Jun/Sep 15 and Jan 15 of the following year, rolled forward past weekends and IRS holidays to the real deadline), plus a deep link to the site. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| taxYear | Yes | Tax year whose installment deadlines to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so 'Read-only' is largely redundant. The description does add genuinely new behavior: the weekend/IRS-holiday roll-forward adjustment and the inclusion of a deep link in the response, which an agent could not learn from annotations or 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?
One dense sentence with the scope and the holiday-roll-forward rule front-loaded, plus a two-word safety tag. Efficient and well-ordered, though the trailing 'Read-only.' duplicates the annotation and costs a little space.
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 usefully characterizes the return payload (four due dates plus a deep link) and explains the roll-forward rule. Only minor gaps remain, such as date formatting/timezone, which are unlikely to block 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% and the single taxYear parameter is documented with an enum and its own description, so the schema carries the full burden. The description adds no syntax or format detail beyond what the schema already says, making baseline 3 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?
States a precise verb ('Return') and resource ('the 4 federal quarterly estimated tax payment due dates for a tax year'), and even enumerates the four dates. It is clearly distinguishable from the sibling estimateQuarterlyTax (calendar lookup vs. tax estimation), so an agent can route without opening either 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?
Usage is only implied: the agent can infer this is the tool for 'when are my estimated payments due', but the description never states when to prefer it over estimateQuarterlyTax or any conditional/prerequisite. With one obvious sibling and no exclusion language, this is minimum-viable context.
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.
estimateQuarterlyTaxgetPaymentCalendar2026 quarterly tax estimates, SE tax, safe harbor and mileage for 1099 gig workers.
Read-only US tax reference for notices, deadlines, filing screens, and clearly labeled estimates.
Equity comp tax/trade optimizer: ISO/AMT exercise, NSO, RSU, QSBS, concentration, hedging. 50-state.
US company filing obligations, plus a 25-check bookkeeping diagnostic. Sourced, dated, no signup.
Add one secure layer between your agents and this server.
