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

With no annotations, the description carries the burden, and it does disclose one important behavior: dates are moved past weekends and DC legal holidays. It does not say how many dates are returned, the format, or whether this is a pure computation with no side effects.

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?

A single well-formed sentence with the resource front-loaded and no filler. Every clause contributes 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 one-parameter, zero-required lookup this is close to adequate, but with no output schema the description should hint at the return shape (e.g., four quarterly dates, date format). As written, the agent knows the topic but not what it receives back.

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 'year' parameter already documents its type, bounds, and 2026 default. The description's 'for a tax year' merely restates the parameter and adds no format or edge-case guidance (e.g., how out-of-range years are handled).

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 resource (IRS quarterly estimated tax due dates) scoped to a tax year, with a concrete behavioral qualifier about weekend/holiday shifting. It is clearly distinct from siblings like estimate or self_employment_tax, though it doesn't explicitly name them.

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 use case is strongly implied — an agent looking up filing deadlines — but there is no explicit when-to-use/when-not statement or reference to an alternative sibling tool. Nothing misleads, but nothing routes either.

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

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

No annotations exist, so the description carries the full burden. It does disclose scope and a useful caveat (planning estimate, not tax advice) and signals that safe-harbor rules and IRS due dates are included in the result, but it says nothing about determinism, assumptions baked in (single state flat rate, QBI default), or what the response looks like.

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 short sentences, zero filler, with the scope and the enumerated outputs front-loaded before the disclaimer. Slightly compressed to the point that the input contract is never addressed, but nothing is redundant.

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 an 11-parameter, zero-required calculator with no output schema and no annotations, the description is adequately complete on scope and caveats, and it lists the outputs produced. The remaining gap is guidance on which optional inputs are needed for which scenario (e.g., prior_year_* for safe harbor, w2_wages for MFJ), which an agent must infer.

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% across all 11 parameters, so the schema already documents each field, including the enum and QBI default. The description adds no parameter-level meaning beyond naming output concepts; in particular it never clarifies the net_profit vs. ytd_profit+months alternative, which is the one genuinely ambiguous input choice.

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 a tightly scoped resource: US federal 2026 freelancer/sole-proprietor taxes, enumerating the four outputs (SE tax, income tax, safe-harbor payment, due dates). It is clearly distinguishable from generic siblings, though it never says whether it duplicates or supersedes self_employment_tax/due_dates/tax_figures, which overlap directly with the listed outputs.

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 only usage frame is the audience phrase 'for a freelancer or sole proprietor' and the disclaimer 'Planning estimate, not tax advice.' There is no statement of when to call this versus self_employment_tax, due_dates, or tax_figures, and no mention of what inputs produce a valid result.

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

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

No annotations are provided, so the description carries the disclosure burden. It usefully states the simplified method rate and square-foot cap, the regular Form 8829 method, the business income limit, and carryovers, though it does not describe the comparison output or any result structure.

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 comparison and key limits. Every phrase contributes to purpose or invocation context, with no filler.

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 an 18-parameter calculator with no output schema, the description covers the essential methods, limits, and carryovers well enough for selection and invocation. It falls short of fully describing the return values or guiding which cost inputs matter for each method.

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 94%, so the schema already documents nearly all parameters. The description adds only a light mention of 'home_sqft and costs' and does not meaningfully clarify the 18 parameters, and it notably omits the required office_sqft parameter from its input hint.

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 the specific tax calculation and distinguishes the two supported methods: simplified ($5/sq ft, up to 300 sq ft) and regular Form 8829. It is clearly a home office deduction calculator, not a generic tax estimate tool.

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 gives a practical invocation hint ('Give home_sqft and costs to compare both'), but does not explain when to use this tool rather than siblings like estimate or tax_figures, nor when to choose simplified versus regular directly. Usage is implied rather than explicitly guided.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the date-based business rate schedule, but it does not state that this is a read-only calculation, how trips and split totals interact, or what the result looks like.

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?

The description is two tightly written sentences with no wasted text. It front-loads the deduction and rate logic, then immediately gives the input modes.

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 10-parameter calculation tool with no output schema and no annotations, the description is incomplete. It does not explain most split-total parameters, the non-business mileage categories, mutual exclusivity between trips and totals, or the tool's return behavior.

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 only 20%, so the description needs to compensate for many undocumented parameters. It mentions trips and business_jan_jun/business_jul_dec, but omits parking_tolls, the moving/charity/medical split totals, purpose enum behavior, and the date format requirements.

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 clearly identifies a standard mileage deduction calculated by trip date, with 2026 business rates and date-based pricing. It is specific about the resource and calculation, but it does not explicitly differentiate itself from sibling tools such as mileage_rates or estimate.

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 says to pass trips or 2026 split totals such as business_jan_jun and business_jul_dec, which gives input-selection guidance. However, it does not explain when to use this tool versus mileage_rates or estimate, nor when trips should be preferred over split totals.

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

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

With no annotations, the description carries the full burden. It discloses the return content (rates by period, with sources) and, by saying 'rates,' implies a read-only reference lookup rather than a computation. It does not state how far back periods go, whether rates are fetched or static, or freshness - gaps an agent might care about.

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?

A single front-loaded sentence identifying the resource, its granularity, and the provenance of the data. Nothing wasted.

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 no-parameter reference lookup with no output schema, the description says what the tool returns and where the data originates, which is close to sufficient. Missing only the coverage window (which years/periods) and how it relates to the 'mileage' sibling.

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?

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 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?

States a specific resource - IRS standard mileage rates - with the granularity (by period) and includes official sources, which tells the agent exactly what comes back. It does not, however, differentiate itself from the sibling 'mileage' tool, leaving the agent to guess which one to pick.

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?

There is no statement of when to use this versus the sibling 'mileage' tool, which is a real ambiguity given both concern mileage. The only implied usage is a passive rate lookup; no prerequisites, exclusions, or alternatives are named.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the calculation basis (IRS Pub. 560 rate worksheet), pins the 2026 limits that drive the result ($72,000 total, $24,500 deferral, $8,000 catch-up at 50+, $11,250 at 60-63), and flags the output as an estimate with a legal disclaimer. It does not describe what the response contains or how the SEP vs Solo 401(k) comparison is presented, which is the remaining gap.

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 plus a short disclaimer, with the plan comparison front-loaded and the numeric limits compactly parenthesized. The only waste is the garbled opening and the mildly cryptic 'rate worksheet' reference; nothing is padded.

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 self-contained calculation tool with a fully described schema, one required parameter, and no output schema, the description supplies everything needed to invoke it: the year, the plan types, the statutory limits, the estimate disclaimer, and the data source. Return-value detail is the only omission, and without an output schema that is a minor cost for a deterministic calculator.

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 all six parameters are already documented, and the baseline of 3 applies. The description adds indirect meaning by quoting the contribution and catch-up limits, which explains why age_group has under50/50plus/60to63 bands and why the totals cap out, but it never ties inputs to the computation (e.g., how net_profit vs w2_wages interact with the Social Security wage base).

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 resource and scope are specific: maximum 2026 SEP IRA vs Solo 401(k) contribution for a sole proprietor or single-member LLC, plus estimated income tax saved. The opening clause is grammatically broken ('Most a sole proprietor...' appears to be missing 'Maximum'), and the verb is implied rather than stated, but the calculation target and the two compared plan types are unmistakable and clearly distinct from siblings like tax_figures or self_employment_tax.

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 implied by the subject matter (self-employed retirement plan comparison) and the closing caveat 'Planning estimate, not tax or investment advice' sets a scope boundary. However, there is no explicit statement of when to call this versus siblings such as estimate or tax_figures, and no note that it is limited to sole proprietors/single-member LLCs (not S-corp or multi-employee contexts) beyond the loose opening phrasing.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It names the tax components but does not disclose whether the tool returns only a tax amount or a breakdown, what assumptions it makes about annualization, thresholds, or filing status, or whether it has any side effects.

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?

The description is a single front-loaded sentence with no filler. It is efficient, though the trailing phrase about the deductible half and Additional Medicare Tax is slightly compressed and could be clearer.

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 tax calculation with no output schema and no annotations, the description is too thin. It does not clarify the return shape, how ytd_profit and months are annualized, how filing status and W-2 wages affect the result, or what the Additional Medicare Tax computation entails.

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 all six parameters are already documented in the schema. The description does not add meaning beyond what the schema provides, but the baseline score of 3 applies when the schema fully covers parameter semantics.

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 clearly identifies the specific calculation: Social Security and Medicare self-employment tax on 2026 net self-employment profit, including the deductible half and Additional Medicare Tax. It is distinguishable from generic siblings like estimate and tax_figures, but it does not explicitly contrast itself with any sibling tool.

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 states what the tool computes but gives no guidance on when to use it versus alternatives such as estimate or tax_figures. There are no exclusions, prerequisites, or scenario cues for selecting this tool.

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

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

With no annotations, the description carries the burden, and it does imply this is a static read-only reference lookup by listing the figures and their official sources. It does not state that the call has no side effects, requires no inputs, or returns cached/static data, but the risk profile of a zero-parameter lookup is low.

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?

A single tight sentence that front-loads the most useful content (2026 brackets, standard deductions). It is a sentence fragment rather than a complete statement of action, which keeps it just short of full marks.

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?

There is no output schema, so the description must convey what comes back, and it lists the categories returned but not their shape, grouping (by filing status? by year?), or whether sources are separate fields. Adequate to justify a call, but thin for a tool whose entire value is its return payload.

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?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly implies a parameterless, unfiltered retrieval.

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 the concrete content the tool surfaces: 2026 brackets, standard deductions, SE tax figures, and official IRS/SSA sources. That clearly distinguishes it from the sibling calculators (estimate, self_employment_tax, mileage) as the reference-data lookup, though it is a noun phrase with no verb stating the retrieval action.

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?

There is no explicit when-to-use guidance and no mention of alternatives or prerequisites. An agent must infer that this tool supplies the constants the sibling calculators rely on, but nothing in the text says so.

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