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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the topic scope but nothing behavioral beyond it – no mention of MAGI phaseout sensitivity, the default tax year of 2026, or whether results are estimates versus definitive eligibility determinations. With annotations carrying the safety burden, a 3 is appropriate.

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 with no filler; the verb and the compared items appear immediately. Nothing could be removed without losing meaning.

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?

An output schema exists so return values need no explanation, and the parameter set is well documented. However, for a 9-parameter analysis tool the description does not say how inputs interact (e.g., that yearsAOTCClaimed caps AOTC eligibility or that isUndergrad gates the AOTC comparison), leaving an agent to infer the analytical logic.

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 89%, so nearly every parameter (agi, tuitionPaid, isUndergrad, yearsAOTCClaimed, contribution529, studentLoanInterest) is already documented in the schema. The description mentions the concepts behind those inputs but adds no syntax, format, or interaction detail, so the baseline 3 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 verb ('Compare') and a specific resource ('education tax benefits'), then enumerates the exact items compared: AOTC, Lifetime Learning Credit, student loan interest deduction, and 529 plans. This clearly separates it from generic siblings like list_tax_credits and check_credit_eligibility, though it never explicitly names those siblings as alternatives.

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: an agent can infer this is for weighing education-related tax options. There is no statement of when to prefer it over check_credit_eligibility or list_tax_credits, no prerequisites (e.g., that the student must have qualifying expenses), and no exclusions.

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?

Annotations already declare this read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds one behavioral fact (it performs an itemize-vs-standard comparison) but says nothing about assumptions that materially change results, such as SALT/property-tax caps or mortgage-debt limits, nor whether it is federal-only.

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, front-loaded with the purpose and followed by the comparison behavior. No filler or repetition, though the second sentence could carry more information for the same length.

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 an output schema and full annotations, the description need not explain return values, and 9 parameters are well documented in schema. However, for a specialized deduction-analysis tool, it omits the factors that govern the answer (SALT cap, mortgage interest limits, state tax treatment), leaving an agent unsure of the model's assumptions.

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 89%, with each parameter individually described, including the notable MAGI note on grossIncome. The description adds no meaning beyond the schema, so the baseline of 3 applies; the schema does nearly all the work.

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?

Names a specific verb and resource pair ('analyze the tax benefit of mortgage interest deduction and property taxes') and states the core computation (itemizing vs standard deduction). An agent can tell what it does, but the description never distinguishes it from the sibling 'standard_vs_itemized', which sounds like an overlapping computation.

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 statement that it compares itemizing with a mortgage against the standard deduction implies the use case, but there is no explicit when-to-use or when-not-to-use guidance and no routing to alternatives such as standard_vs_itemized or list_deductions. The choice between sibling tools is left to inference.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful framing that this is a comparison/verification operation against employer-withheld amounts, but says nothing about how optional inputs like stateCode or annualQualifiedTips affect the analysis, or about limitations such as which tax years are supported.

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 with the purpose front-loaded; nothing is padded. The second sentence partially restates the first's intent, but it does introduce the concrete input expectation, so the redundancy is mild.

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 17-parameter tool with an output schema present, the description is adequate but thin: it doesn't mention the tax-year sensitivity of certain fields (annualQualifiedTips, annualQualifiedOvertimeCompensation are TY2025+) or that state analysis is optional. The schema and annotations carry most of the weight, leaving the description serviceable but not self-sufficient.

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 high (82%), so the schema itself documents most of the 17 parameters, including the enum values for filingStatus and payFrequency. The description only gestures at "pay stub numbers" generically and adds no meaning about which fields are required versus optional or how the state fields pair with stateWithheld.

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 and resource ("Analyze a paycheck") plus the concrete goal ("verify withholding accuracy"), which separates it from siblings like calculate_federal_tax or calculate_w4_withholding that compute a theoretical liability rather than checking a real stub. It never names a sibling explicitly, so the differentiation is inferable rather than stated.

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?

"Input your pay stub numbers and see if your employer is withholding the right amount" implies the prerequisite (you must already have a pay stub with actual withholding figures) and gives a clear success condition. There is no explicit when-not guidance and no pointer to the adjacent tools an agent should choose instead when the user has no stub yet (e.g., prospective W-4 calculations).

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds one genuinely useful behavioral constraint beyond that: additional projection years require explicit annual federal and state data, which warns the agent that yearsToProject is not a free-form extrapolation. It does not explain how that interacts with incomeGrowthRate, which the schema presents as a growth projection input.

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, front-loaded with the purpose and followed by the projection caveat; no filler. It is arguably under-specified rather than padded, which costs a point only in that the second sentence is cryptic without schema context.

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, 5-required analysis tool sitting among ~40 tax siblings, the description leaves the core question unanswered: how does relocation analysis differ from compare_state_taxes or estimate_state_tax, and does it include federal liability? The output schema and read-only annotations relieve it of return-value and safety explanations, but not of positioning.

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 60%, so the schema already documents taxYear, fromState, toState, grossIncome, and yearsToProject. The description reinforces the year semantics ("exact-year state profiles") and the projection data requirement, but says nothing about the undocumented dependents, capitalGains, filingStatus, or selfEmploymentIncome parameters.

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?

"In-depth relocation tax analysis using exact-year state profiles" names the resource domain (relocation taxes) and implies a comparison between two states, but it is a noun phrase with no verb and no explicit statement of what is computed or returned. It does not distinguish itself from close siblings such as compare_state_taxes, estimate_state_tax, or plan_multi_year_taxes.

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 word "relocation" implies a move scenario, but the description never states when to call this instead of compare_state_taxes or compare_tax_years. No prerequisites, no exclusions, and no guidance on choosing between the many state-comparison siblings are given.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds that the tool performs heuristic red-flag detection and scoring, but omits anything an agent would want beyond that: whether a score is deterministic given the same inputs, whether it is advisory rather than authoritative, and whether partial profiles degrade accuracy.

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, zero filler, and the core purpose is front-loaded before the output summary. Nothing repeats the tool name or the annotations.

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 15 parameters, an output schema, and complete annotation coverage, the description supplies the essential 'what' and 'what you get back' without needing to restate field semantics. The remaining gap is guidance on how much profile data is sufficient, since only 2 of 15 parameters are required and the description never says optional inputs can be omitted.

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 93%, so nearly every one of the 15 parameters is already documented in structured data, and an output schema exists for results. The description adds no field-level meaning, thresholds, or units beyond implying that the inputs describe a 'tax return profile'; the baseline 3 applies when the schema does the heavy lifting.

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 a specific verb and resource ('Evaluate your IRS audit risk') and enumerates the three outputs: red-flag identification, risk scoring, and reduction tips. It is clearly distinguishable from tax-calculation siblings, though it never explicitly positions itself against adjacent advisory tools like run_tax_health_check or get_tax_planning_tips.

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?

'Based on your tax return profile' implies the agent should supply return details, and the 13 optional fields hint at a progressive-disclosure usage pattern, but the description never states this. There is no when-to-use/when-not-to-use guidance, no prerequisite statement, and no named alternative for related questions.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no note on whether eligibility rules are enforced, how phase-outs or the investment-income limit are handled, or what happens with unsupported tax years. The word 'exact' is the only behavioral signal, and it is unelaborated.

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 purpose is front-loaded in the first sentence, which is good. The second sentence is a marketing-style factoid about EITC size that does not help an agent select or invoke the tool, so it does not earn its place.

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?

The tool has rich annotations, an output schema, and 83% parameter coverage, so most of the calling burden is already handled elsewhere. The description only needs to establish purpose and selection guidance, and while selection guidance is missing, the remaining gaps are modest given how much structured context is supplied.

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 83%, so the schema already documents agi, earnedIncome, investmentIncome, taxYear and qualifyingChildren. The description contributes no parameter-level meaning at all — for instance, it never mentions that investmentIncome triggers a disqualification threshold or why filingStatus and qualifyingChildren interact. Baseline 3 applies because the schema carries the load.

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 opens with a specific verb and resource: 'Calculate the exact Earned Income Tax Credit (EITC) amount.' That is unambiguous and distinguishes it from siblings like calculate_federal_tax or list_tax_credits. It stops short of naming a sibling or stating scope boundaries (e.g., vs. check_credit_eligibility), which keeps it from a 5.

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 second sentence ('The EITC is one of the largest refundable credits for low-to-moderate income workers') is background information, not usage guidance. Nothing states when an agent should call this instead of check_credit_eligibility (eligibility screening) or estimate_premium_tax_credit, nor are prerequisites or exclusion cases given.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond that: the supported tax-year window and the explicit assurance that all calculations run locally with no data sent to a server. It does not cover precision/rounding, error behavior, or disclaimer framing, which keeps it short of a 5.

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?

Four sentences, front-loaded with the core purpose, followed by supported years, output scope, and a privacy note. The mid-sentence feature list is dense but each item maps to real computational coverage, so little is wasted. A slight trim of the enumeration would make it tighter.

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 50-parameter tool with 98% schema coverage, an output schema, and full annotations, the description supplies the right framing: scope, tax-year support, computed outputs, and locality of computation. The main residual gap is that it gives no guidance on which of the 47 optional inputs are needed for which outputs, leaving the agent to derive that from schema descriptions.

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 98% across 50 parameters, so the schema itself carries virtually all parameter meaning, including required fields, the filingStatus enum, and the TY-gated inputs. The description mentions the tax domains (SE tax, NIIT, QBI, capital gains, CTC) at a high level but adds no syntax, defaults, or interdependency guidance beyond the schema. Baseline 3 applies given the schema does the heavy lifting.

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 opens with a specific verb+resource ('Calculate federal income tax for an individual taxpayer') and enumerates the computed outputs (bracket breakdown, SE tax, NIIT, QBI, capital gains, CTC), so the agent knows exactly what the tool returns. It does not name or rule out the many overlapping siblings such as calculate_total_tax, estimate_self_employment_tax, or calculate_eitc, so the agent gets no explicit differentiation.

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 by the capability list and the 'supports TY2024 through TY2026' range. There is no statement of when to prefer this over calculate_total_tax or the narrower estimators, and no mention of prerequisites or when the optional inputs must be supplied. An agent can infer suitability but must reason it out rather than being told.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds that the result shows qualification per deduction and total tax savings, which is useful beyond the annotations, but it says nothing about caps, phase-outs, or that agi/filingStatus drive eligibility—the main behavioral wrinkles for these deductions.

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 front-loaded sentences with no filler; the deduction list is the core payload and comes immediately. The 'OBBB (One Big Beautiful Bill)' expansion is slightly redundant with the tool name but aids disambiguation.

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 an output schema present, return values need no explanation, and the schema covers parameter semantics for 9 params. The description is complete enough to select and call the tool; the only gap is eligibility mechanics (caps, phase-outs, which inputs gate which deduction) for a moderately complex calculation.

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 89%, so nearly every parameter is already documented in the schema, including the age-dependency for the senior bonus and the US-assembled vehicle constraint. The description adds no parameter-level meaning beyond that, so baseline 3 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 verb (calculate) and a specific resource (the four named OBBB deductions for TY2025+), enumerating tips, overtime, senior bonus, and auto loan interest. An agent can tell this apart from list_deductions or standard_vs_itemized, though it never names those siblings explicitly.

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 'TY2025+' qualifier signals applicability, and the enumerated deduction types hint at when a caller would pick this over list_deductions. There is no explicit when-to-use, when-not-to-use, or sibling routing guidance.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is fully covered. The description adds that federal breakdown, state tax, and combined totals all come back in one call, which is a mild efficiency signal. It says nothing about assumptions (e.g. tax year coverage, state-specific rules) or accuracy caveats that would matter for a 35-parameter tax computation.

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 purpose, and the return-value sentence is compact. Nothing is padded, though the brevity borders on under-specification given the tool's complexity.

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 35 parameters, only 4 required, an output schema present, and rich annotations, the description covers only the high-level purpose. It omits the minimal required input set (taxYear, filingStatus, grossIncome, stateCode), any explanation of how optional inputs refine the calculation, and any caveat about state rule coverage. An agent can call it, but cannot scope its inputs wisely from this text alone.

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 description mentions no parameters at all, despite 35 parameters of which only 4 are required. Schema coverage is a moderate 63%, so the schema documents many fields but the description offers no guidance on which optional inputs materially change the result or which can be safely omitted. For a tool this parameter-heavy, that is a real gap.

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 gives a specific verb and resource ("Calculate combined federal + state tax") and states the output composition. "Combined" implicitly differentiates it from calculate_federal_tax or estimate_state_tax, though no sibling is named outright.

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 through the phrase "complete picture of total tax liability" - an agent can infer this is for joint federal+state estimates. There is no explicit when-to-use versus calculate_federal_tax, estimate_state_tax, or compare_state_taxes, and no note on prerequisites or when a single-jurisdiction tool is preferable.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds that output is a recommendation with step-by-step form guidance and per-paycheck estimates, which is useful context, but it says nothing about accuracy caveats, assumptions, or what the recommendation is based on.

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, front-loaded with the core action, with no filler. Slightly redundant between 'W-4 withholding settings' and 'W-4 form recommendations' but nothing wasteful.

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 a full output schema and complete parameter documentation, the description covers the basic contract. However, for a tool with nine inputs including multipleJobs and spouseWorks, it omits guidance on which inputs matter and why, and doesn't indicate limitations versus analyze_paycheck or calculate_federal_tax.

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 nine parameters, so the schema already documents taxYear, filingStatus, dependents, and the rest. The description contributes no additional parameter meaning, which is the expected baseline when the schema does the heavy lifting.

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 and resource: calculates recommended W-4 withholding settings and estimates per-paycheck federal tax. This implicitly distinguishes it from calculate_federal_tax and analyze_paycheck by its W-4/form-recommendation focus, but it never names a sibling, so differentiation is left to inference.

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 implies the use case (setting up or adjusting W-4 withholding) but gives no explicit when-to-use or when-not guidance and never points to alternatives such as calculate_federal_tax, analyze_paycheck, or simulate_tax_scenario.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond that — it doesn't say results are estimates rather than determinations, whether omitted optional inputs degrade accuracy, or how partial data is handled.

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 with no filler or restated name. Nothing in it is 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?

With an output schema present, the description needn't explain return values, and the schema documents nearly every field. For a 15-parameter tool the only real gap is not flagging which optional flags materially change results — a minor omission given the structured coverage.

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 87% with only two required fields, so the schema itself carries nearly all parameter meaning. The description adds no parameter-level context, such as that agi/filingStatus are mandatory while the boolean flags drive which credits are surfaced.

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 and resource ('Check which tax credits you may be eligible for') plus the basis for the check ('based on your situation'). It is clearly distinguishable from siblings like list_tax_credits or calculate_eitc in intent, though it never names those siblings explicitly.

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 guidance on when to prefer this over the many closely related siblings (list_tax_credits, calculate_eitc, estimate_premium_tax_credit, analyze_education_tax_benefits), no prerequisites, and no statement of what the agent must supply to get meaningful results. Usage is only implied by the phrase 'based on your situation'.

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?

Annotations already cover the safety profile (read-only, idempotent, non-destructive), so the added burden is low. The description still contributes a meaningful behavioral caveat: it does not authenticate to the user's IRS account and only surfaces official links and requirements, which prevents a false expectation of live data.

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, front-loaded with the core purpose and immediately followed by the key exclusion. Nothing is padded, though the second sentence could be tightened into the first for a perfect score.

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?

An output schema exists, so return-value explanation is not required, and the 'no IRS account access' caveat is present. However, the definition says nothing about how the filedElectronically parameter changes the guidance, which is the only real gap for such a simple tool.

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% for the single filedElectronically boolean, so the schema already carries the parameter meaning. The description does not mention the parameter or how the answer changes for e-filed versus paper returns, so it adds nothing beyond the schema – baseline 3.

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 refund status) and a specific action (provide instructions/links rather than live status). No sibling tool covers refunds, so it is distinguishable, but the description slightly conflicts with the tool name 'check_refund_status', which implies an actual status lookup.

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 makes the usage context implied ('how to check IRS refund status') and explicitly excludes the IRS-account-access interpretation. It never says when to call this versus adjacent tools such as get_tax_deadlines or get_irs_form_info, but there is no direct alternative in the sibling list.

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?

Annotations already declare this a safe read-only, idempotent, closed-world operation, so the safety profile is covered. The description adds the substantive behavioral fact that income is held equal across comparisons, but it never says how many or which statuses are evaluated, whether dependents/deductions are applied uniformly, or what assumptions (standard vs itemized) are baked in.

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 with the core operation front-loaded and no filler. The second sentence is somewhat redundant with the first but does add the purpose (choosing the best status), so it earns most of its place.

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?

An output schema exists, so return-value explanation is not required, and the four flat numeric parameters are fully documented by the schema. What remains missing is the scope of the comparison (which filing statuses) and how this differs from closely named siblings — the main sources of misfire for an agent.

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% — taxYear, grossIncome, dependents, and itemizedDeductions are each documented in the schema with ranges and meaning. The description's only parameter-adjacent content is "same income," which merely restates grossIncome's role rather than adding 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?

"Compare tax liability across different filing statuses for the same income" gives a specific verb (compare) and resource (filing status tax liability) with the key constraint that income is held constant. It does not, however, distinguish itself from the sibling 'compare_mfj_vs_mfs', which sounds like a narrower version of the same operation, leaving the agent to guess which 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?

"Helps determine the most advantageous filing status" implies the use case (choosing a status), but gives no explicit when-to-use/when-not guidance and never names an alternative. With siblings like compare_mfj_vs_mfs, calculate_federal_tax, and compare_state_taxes present, an agent has no routing signal from this description.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered by structured data. The description adds that the response includes the MFS restriction list, which is modestly useful behavioral context, but since an output schema exists that content is largely already discoverable. No notes on assumptions or limitations of the comparison.

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, front-loaded with the comparison being made, and the second sentence tells the agent what comes back. Nothing is wasted or 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?

With a rich schema and an output schema, the description covers enough to call the tool correctly. The main missing piece is sibling differentiation against 'compare_filing_statuses' and any hint about the scenario flags that materially change the result (EITC, education credits, IRA, student loan interest).

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 9 parameters, so the schema fully documents taxYear, incomes, dependents, and the boolean scenario flags. The description mentions none of them, so it adds no meaning beyond the schema — baseline 3 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?

The description names a specific comparison (Married Filing Jointly vs Married Filing Separately) and states what the result contains: the tax difference plus the list of MFS restrictions. That is a concrete verb-plus-resource statement. It stops short of 5 because the sibling 'compare_filing_statuses' covers overlapping ground and the description does nothing to distinguish the two.

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 — an agent can infer you call this when a married couple is weighing joint vs separate filing. There is no explicit when-to-use statement, no prerequisites (e.g., both spouses must have income figures), and no guidance on when 'compare_filing_statuses' would be the better choice.

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?

The annotations already establish that this is a safe, read-only, idempotent, non-destructive operation. The description adds the important gating condition about calculation profiles, but it does not explain failure behavior when a profile is missing or how partial matches are handled.

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 definition is a single front-loaded sentence with no filler. It is dense and efficient, though the compressed phrasing leaves some behavioral questions unanswered.

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?

Annotations cover safety and the output schema covers return structure, so the main description gap is usage guidance. The critical precondition is present, but the description does not explain fallback behavior or alternatives when not all requested states have profiles.

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 schema already documents all five parameters. The description reinforces the single-tax-year constraint and the requirement that requested states have profiles, but it adds no extra detail about defaults, the deprecated taxableIncome alias, or the 2-to-10 state limit.

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?

"Compare state income tax" gives a specific verb and resource, and "for one tax year only" narrows the scope. It does not explicitly distinguish itself from nearby siblings such as estimate_state_tax or compare_tax_years, but the purpose is still clear.

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 gives a real precondition: use it only when every requested state has an explicit calculation profile. However, it does not say what to do when that condition fails or which alternative tool to use instead.

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?

Annotations already declare this as a safe, read-only, idempotent, closed-world computation, so the safety profile is covered. The description usefully adds that the output explains bracket changes and inflation adjustments, which tells the agent what the comparison contains. However, it never says which tax years are compared or how they are chosen — a significant behavioral gap given no year parameter exists in the 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?

Two sentences, no filler, with the core purpose front-loaded in the first clause. The second sentence is informative rather than redundant. Slightly more length would be justified if it addressed the missing year-selection behavior.

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?

An output schema exists, so return values need not be explained, and the annotations cover the safety profile. The remaining gap is substantive: the description promises comparison 'across different tax years' while the input schema exposes no year parameters, so an agent cannot determine which years will be used or whether the set is fixed. That ambiguity should have been resolved in the description.

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 25%: just grossIncome is documented, leaving filingStatus, dependents, and selfEmploymentIncome undocumented in the schema. The description contributes nothing about any parameter — it does not explain that selfEmploymentIncome is treated separately from grossIncome, how dependents affect the comparison, or that filingStatus drives the bracket lookup. With low coverage, this is the dimension where the description most needed to compensate and does not.

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 states a specific verb and resource ('Compare tax liability across different tax years') and adds a scoping condition ('for the same income'), which distinguishes it from broad multi-year planning siblings like plan_multi_year_taxes. It stops short of naming the closest alternatives (what_changed_between_tax_years, compare_filing_statuses), so it is clear but not fully differentiated.

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: 'for the same income' signals a controlled comparison, but there is no explicit when-to-use statement, no when-not, and no pointer to the sibling that handles year-over-year rule changes (what_changed_between_tax_years) or multi-year planning (plan_multi_year_taxes). An agent must infer the routing decision.

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?

Annotations already establish that this is a safe, idempotent, closed-world read. The description goes beyond them by disclosing the computation regime: Rev. Proc. 2025-25 applicable percentages, the 400% poverty-line cutoff, and full repayment of excess advance payments, which materially affects how an agent should interpret and present results.

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 tightly packed sentences with zero filler, and the tool's identity is front-loaded before the methodological details. Every clause carries information an agent can act on.

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 an output schema present, return values need not be explained, and the description covers the method, the statutory limits, and the repayment treatment. It does not mention the 2026-only modeling constraint or the MFS/below-100% exceptions, though those are captured in the schema.

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 91%, so nearly every parameter is already documented in the schema, including the monthly array replacing annual totals. The description adds no format or edge-case detail beyond noting the annual Form 1095-A totals, so the baseline 3 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?

The description names a specific verb (Estimate), a specific credit and form (Premium Tax Credit, Form 8962), and the input source (annual Form 1095-A totals). It is specific enough to separate it from generic siblings like list_tax_credits or check_credit_eligibility, though it never names those alternatives explicitly.

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 reference to Form 1095-A totals tells an agent this is for people with Marketplace coverage, but there is no explicit statement of when to pick this over check_credit_eligibility or list_tax_credits, and no prerequisites or exclusions are given.

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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered and the bar is lower. The description adds the 1040-ES framing but does not state jurisdiction (federal-only vs. state), whether the result is an annual safe-harbor figure or a per-quarter breakdown, or any assumption about annualizing income. Credit for domain framing, but key calculation behavior is left undisclosed.

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 with the core action first and the audience qualification second; no filler or restatement of the tool name. It is tight, though one short clause on federal scope would have earned its place.

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?

An output schema exists and annotations cover the safety profile, so the description need not explain return values or side effects. The remaining meaningful gap is jurisdiction scope, which matters given siblings like estimate_state_tax and compare_state_taxes. Otherwise the definition is sufficient for 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 83%, so the schema already documents nearly all six parameters, including enums for filingStatus and minimums on amounts. The description contributes no additional meaning about how selfEmploymentIncome interacts with expectedAnnualIncome (e.g., whether SE income is included in or additive to annual income) and no unit or period guidance. Baseline 3 applies when the schema carries the load.

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 a specific verb and resource (calculate estimated quarterly tax payments) and anchors it to Form 1040-ES, plus identifies the target population (self-employed or others owing estimated payments). This separates it reasonably well from siblings like calculate_federal_tax or calculate_w4_withholding, though it never explicitly names those alternatives.

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 supplies a clear qualifying condition: taxpayers who must make estimated payments, particularly the self-employed. That gives an agent a usable trigger for selection. It stops short of explicit exclusions or naming which sibling to use instead (e.g., estimate_state_tax for state-level payments), so it is not a full when/when-not statement.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds the useful disclosure that the three QBI inputs default to 0 when not applicable, but it says nothing about the QBI threshold value used, rounding, or whether the quarterly payment figure assumes safe-harbor rules. Since an output schema exists, the lack of return-value detail is not a major 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?

Two sentences, no filler, with the output scope front-loaded before the conditional input instruction. The second sentence is dense but earns its place by covering three otherwise undocumented parameters.

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 tax computation with an output schema and full annotations, the description covers the headline calculation and the advanced QBI branch adequately. It falls short on what the QBI threshold actually is, how quarterly payments are derived, and semantics for roughly half the inputs, 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?

At 55% schema description coverage across 11 parameters, the description partially compensates by explaining the purpose of qualifiedBusinessIsSstb, qualifiedBusinessW2Wages, and qualifiedBusinessPropertyBasis and their 0-default convention. It adds nothing about dependents, healthInsurancePremiums, retirementContributions, otherW2Income, or filingStatus, leaving several undocumented parameters entirely to their bare schema types.

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 a specific resource and enumerates the computed outputs (Schedule C profit, SE tax, QBI deduction, quarterly payments), so an agent knows exactly what this tool produces. It does not, however, distinguish itself from siblings such as calculate_federal_tax, estimate_quarterly_tax, or calculate_total_tax, which overlap in scope.

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 second sentence gives an explicit conditional rule for when to supply the advanced QBI inputs (above the annual QBI threshold, use 0 where none apply), which is real input-time guidance. But there is no guidance on when to choose this tool over the many adjacent tax calculators, and no statement of prerequisites or exclusions.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds one genuinely new behavioral trait — that unsupported state-year combinations fail closed rather than approximating — which is useful. It does not say what such a failure looks like or what the output contains, but an output schema exists to cover that.

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 with the purpose front-loaded and no filler. The second sentence is compact but leans on terser jargon ("fail closed") that costs a moment of interpretation, keeping it just short of ideal.

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 annotations covering safety, a full-coverage schema, and an output schema, the description only needs to add routing and edge-case context. It supplies the fail-closed caveat but omits any differentiation from the numerous sibling tax-calculation tools, which is the main remaining gap for a 5-parameter estimator in a crowded toolset.

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 every parameter including the deprecated taxableIncome alias is documented in the schema itself. The description only echoes that the calculation is tied to a versioned tax-year profile and adds no format, default, or precedence guidance beyond the schema; baseline 3 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 verb and resource ("Estimate state income tax") plus a scoping notion (versioned tax-year calculation profile), so the agent knows this is a state-level estimation keyed to a year. It does not explicitly distinguish itself from near-siblings such as compare_state_taxes, get_state_tax_info, or compare_tax_years, leaving that inference to the agent.

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?

"Unsupported state-year paths fail closed" hints at a precondition (only certain state-year profiles are modeled) but never states when to choose this over calculate_federal_tax, compare_state_taxes, or get_state_tax_info. There are no explicit when-to-use or when-not-to-use instructions, only an implied failure condition.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is fully covered. The description adds two useful behavioral facts: credits are 'modeled' rather than authoritative, and only 'supported' states are handled — meaningful caveats for an estimation tool. It does not note that the remaining 48 parameters are all optional or that unspecified inputs default to zero/absent, which matters greatly for correctness.

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 with no filler or repetition; the core action and the component scope come first. It is arguably too terse for a 50-parameter tool, but nothing in it is 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?

An output schema exists, so return-value explanation is not required, and annotations cover safety. What remains missing for a 50-parameter, 2-required-field estimation tool is minimal-input guidance (taxYear + filingStatus suffice) and when to prefer it over calculate_total_tax or calculate_federal_tax.

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 78%, so the schema already documents most of the 50 parameters well, making 3 the baseline. The description contributes only category-level vocabulary ('deductions', 'credits', 'refund inputs') and adds no guidance on which inputs are required versus optional or how partial data is treated.

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?

Uses a specific verb (Generate) and a specific artifact (a detailed tax estimate) and enumerates what the report combines: federal tax, supported state tax, FICA, modeled credits, deductions, take-home pay, and refund inputs. That enumeration implies this is the aggregates-everything tool, differentiating it implicitly from narrow siblings like calculate_federal_tax, but it never names a sibling or states that it is the superset.

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 when-to-use or when-not-to-use guidance and no routing to alternatives, despite many overlapping siblings (calculate_total_tax, calculate_federal_tax, simulate_tax_scenario, estimate_state_tax). The only implied guidance is that this is the full combined estimate, which an agent must infer from the component list.

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?

Annotations already declare read-only, idempotent, closed-world, and non-destructive behavior. The description adds useful behavioral context: deterministic and privacy-first local computation, plus structured results, assumptions, source provenance, calculation trace, and explicit unsupported boundaries.

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?

It is a single front-loaded sentence with no wasted words. The list of output components is dense but informative, though it could be broken into a clearer structure.

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?

The output schema means return values need not be explained, and the description covers purpose and behavior. However, for a complex 9-parameter tool with nested objects and low schema coverage, the absence of input guidance and usage conditions leaves clear gaps.

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 22%, so the description should compensate for undocumented parameters. It mentions no parameter names, constraints, or input semantics whatsoever, leaving the agent reliant on the schema alone.

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 states a specific verb and resource: 'Generate a deterministic, privacy-first local tax plan' and lists the output components. It does not explicitly differentiate this from close siblings like generate_full_tax_report or calculate_total_tax, so sibling differentiation is missing.

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 guidance on when to use this tool versus alternatives. The many tax calculation and planning siblings make the absence of routing guidance significant.

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?

Annotations already declare this a safe, idempotent, closed-world read, so the safety profile is fully covered without the description. The description adds that the response is structured as per-section guidance including required data and common errors, which is genuinely useful planning context, but it does not go on to say anything about depth, length, or coverage limits per form.

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 tight sentences, zero filler, with the core deliverable front-loaded and the content breakdown following immediately. Every clause earns its place.

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, read-only tool with an output schema and full annotation coverage, the description supplies enough: what it returns, what the input denotes, and the kind of help provided. The only real gap is the lack of routing guidance relative to sibling form/tax-info tools.

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 formNumber parameter already carries examples ('1040', 'Schedule C', 'W-4'), so the schema does the heavy lifting. The description correctly frames the parameter's role as selecting the specific form the guide targets, which slightly reinforces but does not exceed the structured documentation.

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?

"Step-by-step guide for filling out a specific IRS form or schedule" gives a specific deliverable (a filing guide) tied to a specific resource (an IRS form), and the second sentence clarifies what the guide contains. It does not, however, distinguish this from the closely related sibling get_irs_form_info, leaving the agent to guess which one returns guidance versus metadata.

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?

Use is only implied: an agent can infer the tool is appropriate when a user needs help completing a form. There is no explicit when-to-use or when-not-to-use statement and no mention of the obvious alternative (get_irs_form_info) or of get_tax_document_checklist for gathering inputs.

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?

The annotations already establish a read-only, idempotent, non-destructive, closed-world operation. The description adds a useful scope limitation to "common" IRS forms, but it does not explain coverage limits, handling of unrecognized form numbers, or the source and currency of the information.

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 single sentence is compact and front-loads the action and resource. The phrase after the dash efficiently communicates the three information categories without repetition or 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 a simple one-parameter read-only lookup with an output schema, the description supplies enough information for basic selection and invocation. Its main remaining gap is boundary guidance relative to get_form_filing_guide and clarification of what "common" coverage includes.

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 schema fully documents the sole formNumber parameter and supplies examples such as "1040," "W-2," and "Schedule C." The description adds no parameter syntax, normalization, or supported-form details beyond that, so the high-coverage baseline of 3 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?

The description clearly pairs the verb "Get" with IRS tax forms and specifies that it explains what forms are, who needs them, and where to find them. It does not distinguish this general-information tool from the sibling get_form_filing_guide, so it falls short of full sibling differentiation.

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 listed information types imply that the tool is for general form orientation rather than tax calculation or filing. However, it provides no explicit when-not guidance or alternative, particularly for agents that should instead use get_form_filing_guide for filing instructions.

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?

Annotations already declare this a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is fully covered. The description contributes the enumeration of what the calendar includes, which is genuinely useful behavioral context. It does not say how the flags alter the result set or whether omitted flags default to false, so it stays at a solid 3.

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 action and followed by the payload contents; no filler. Slightly less efficient than ideal since the second sentence is a list of output items that overlaps with the presence of an output schema.

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?

The output schema means return values need no explanation, and all six parameters are documented in the schema. What is missing is how the personalization behaves (e.g., whether filedExtension pushes dates to October, whether omitted booleans are treated as false) and how this differs from get_tax_deadlines, which matters for a tool whose whole value is tailoring.

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% and every property carries a plain-language question ("Did you file an extension?", "Do you have rental property income?"), so the schema already does the heavy lifting. The description's "based on your situation" reinforces that the booleans personalize the output, which is the one extra idea worth conveying.

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?

"Generate a personalized tax calendar" is a specific verb+resource, and the second sentence enumerates the contents (filing, estimated payments, extensions, key actions). It falls short of 5 because a very close sibling, get_tax_deadlines, is never acknowledged or distinguished, leaving the agent to guess which one returns generic vs. personalized deadlines.

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 phrase "based on your situation" hints that the boolean flags drive personalization, but there is no explicit when-to-use guidance, no prerequisites, and no exclusion naming get_tax_deadlines or get_tax_planning_tips as alternatives. With two siblings in the same deadline space, an agent gets no routing help.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds the useful signal that this is a static fact sheet (limits, tax treatment, income limits, tips) rather than a calculator, but says nothing about caching, update cadence, or how the 'tips' content is structured. With annotations carrying the safety burden and an output schema covering returns, a 3 is appropriate.

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 that names the resource and then lists the four categories of returned information. No filler, no restatement of the tool name, and the em-dash list makes the value proposition scannable.

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-optional-parameter read tool with full schema coverage, complete annotations, and an output schema, the description covers what the tool returns at a category level. Nothing critical is missing, though a note on how 'tips' differ from get_retirement_strategy would close the remaining gap.

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% and the single optional parameter already documents examples ('roth_ira', '401k', 'hsa', 'sep_ira') and the empty-means-all behavior. The description reinforces the concept of account types but adds no new syntax or filtering semantics beyond the schema, so it sits at the expected baseline rather than excelling.

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 gives a specific verb ('Get details') plus resource ('retirement account types') and enumerates the content covered (contribution limits, tax treatment, income limits, tips). It is clearly distinguishable from siblings like get_retirement_strategy or plan_retirement_withdrawals by being a reference lookup rather than a planner, but it never explicitly states that distinction.

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 phrasing suggests a static reference lookup for account-type facts, and the schema's 'Leave empty for all' hints at bulk retrieval. There is no explicit when-to-use, no exclusion of planning-oriented siblings such as get_retirement_strategy, and no guidance on when a caller should instead use plan_retirement_withdrawals.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds scoping value by enumerating the strategy families in scope, but says nothing about depth of detail, freshness, or limits. With full annotation coverage the bar is lower, so a 3 is appropriate.

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 with the resource first and the strategy list second; no filler. The inline enumeration is slightly long but each item earns its place by telling the agent what topics are covered.

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?

This is a simple read-only lookup with one optional parameter, full schema coverage, full annotations, and an output schema, so return-value explanation is unnecessary. The description is complete enough to call correctly; only the sibling differentiation and empty-ID behavior are left implicit.

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% and the single strategyId parameter already documents valid examples and the 'leave empty for all' default. The description only mirrors the same strategy names at a coarser grain (it lumps Tax Loss/Gain Harvesting together), adding no syntax or filtering semantics beyond the schema, so the baseline 3 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?

The description names a specific verb ('Get detailed info') and a specific resource (tax-advantaged retirement strategies), then enumerates the covered strategies, so an agent knows exactly what content it returns. It does not distinguish itself from closely related siblings such as get_retirement_accounts or plan_retirement_withdrawals, which keeps it from a 5.

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 guidance is implicit in the example list: look up a named strategy. There is no statement of when to prefer this over get_retirement_accounts (account details) or plan_retirement_withdrawals (withdrawal modeling), and no mention of the documented 'leave empty for all' behavior in the description itself.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered elsewhere. The description adds modest value by naming the kind of content returned ('rates, brackets, and key details'), but it says nothing about coverage gaps (e.g., states with no income tax) or data vintage.

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 short sentence, front-loaded with the verb and resource, and no filler. It could not easily be trimmed further, though the trailing 'key details' is slightly vague.

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 an output schema present and full parameter documentation, return values and inputs are already specified. What remains missing is the sibling disambiguation in a crowded state-tax tool cluster, which is the main thing an agent needs to select this tool correctly.

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 stateCode parameter is documented with format and examples in the schema. The description's 'for any US state' only loosely reinforces the input domain, adding no format or edge-case detail beyond the schema, so baseline 3 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 verb and resource ('Get state income tax information') and enumerates the content returned (rates, brackets, key details). It is clear what the tool does, but it offers no differentiation from close siblings such as get_tax_brackets, estimate_state_tax, or compare_state_taxes.

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 guidance on when to use this instead of estimate_state_tax (which presumably computes a liability) or get_tax_brackets (which may overlap on bracket data). The agent must infer the boundary from the tool name alone, and no exclusions or prerequisites are given.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and determinism profile is fully covered. The description adds only that results are federal (not state) and include the standard deduction, with no mention of how out-of-range years are handled or caching behavior. Some added value beyond structured fields, but modest.

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 with the resource and both scoping parameters, and no filler. Nothing could be removed without losing meaning.

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 a rich output schema, full parameter documentation, and safety annotations, the description only needs to establish scope, which it does by specifying federal brackets plus the standard deduction. A small gap remains around behavior for unsupported tax years, but nothing essential to calling it correctly is missing.

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% — both taxYear (with the 2024/2025/2026 range) and filingStatus (with its four-value enum) are documented in the schema. The description merely restates the two dimensions without adding format, default, or constraint detail, so the baseline 3 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?

The description names a specific verb and resource ('Get federal income tax brackets and standard deduction') plus the two scoping dimensions (year, filing status). The word 'federal' implicitly separates it from state-oriented siblings like get_state_tax_info, but no sibling is named explicitly, so differentiation relies on inference.

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 phrase 'for a given tax year and filing status' signals a parameterized lookup rather than a calculation, which usefully contrasts with calculate_federal_tax. However, there is no explicit statement of when to use this versus those compute-oriented siblings, and no exclusions or prerequisites.

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?

The description clarifies that the data is for a 'given tax year,' adding useful scoping context. However, the provided annotations already handle the safety profile (readOnlyHint: true), and the description does not disclose any additional behavioral complexities or data limitations beyond the scope.

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 definition is a single, concise sentence that puts the primary function first. It avoids jargon and unnecessary phrasing while remaining direct.

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 simple lookup tool with minimal parameters, the description is sufficiently complete. The combination of the scope (deadlines), the resource (IRS), and the safety hints provided in annotations makes the definition a good starting point for an agent.

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?

Since the schema coverage is 100%, the baseline score is 3. The description merely confirms that the tool operates 'for a given tax year,' which is the exact role of the 'taxYear' parameter, thus adding no semantic value beyond the schema.

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 tool clearly states its purpose: retrieving IRS tax deadlines and due dates. While the purpose is clear, given the extremely long list of tax-related sibling tools, the description relies on the noun 'deadlines' to differentiate itself, which may not be fully sufficient.

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 definition provides virtually no usage guidance. It does not explain when to use this tool versus closely related tools like 'get_tax_brackets' or 'get_personalized_tax_calendar,' making tool selection difficult for an agent without trial and error.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only that the checklist is 'personalized' from the supplied flags; it does not say what happens with all-false input, whether flags alter the checklist length, or how taxYear influences results. Adequate but thin given the annotation coverage.

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 with no filler, and the core purpose is front-loaded in the first sentence. The second sentence adds the personalization driver without redundancy.

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 an output schema present, return values need no explanation, and annotations cover the safety profile. However, for a 21-parameter tool with a defaulted taxYear, the description should clarify default/omission semantics and roughly what the checklist contains — neither is addressed.

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% and all 21 booleans are self-documenting, so the schema carries the load. The description's phrase 'income sources, deductions, and life events' loosely categorizes the flags (e.g. hadBaby, soldHome as life events) but adds no per-parameter meaning such as whether omitting a flag means 'unknown' or 'false'. Baseline 3 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 verb ('Generate') and resource ('personalized checklist of tax documents') with the inputs that drive it (income sources, deductions, life events). It is clearly distinguishable from siblings like list_deductions or get_form_filing_guide, though it never names an alternative explicitly.

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 by the phrase 'you need to gather for filing' — an agent can infer this is a pre-filing preparation step. There is no statement of when to prefer this over list_deductions, get_form_filing_guide, or generate_full_tax_report, and no prerequisites or exclusions are given.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed world, so safety is covered. The description usefully signals that this is advisory (it 'suggests actions') rather than a pure calculator, but adds nothing about the cost of a broad call, any limits, or whether results are deterministic across repeated calls with the same year.

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 with the purpose front-loaded; no filler or marketing padding. The second sentence partly restates the first ('suggests actions to reduce tax liability' vs 'optimization strategies'), costing a little redundancy.

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 15-parameter advisory tool the description is thin on parameter guidance, and an agent gets no signal that supplying more optional fields improves personalization, or how partial inputs are handled. With an output schema already documenting returns and annotations covering safety, this is a moderate gap rather than a blocking one.

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 53%, and the description only loosely gestures at the parameter space with 'income, deductions, and situation'. It does not clarify that only taxYear, filingStatus and estimatedIncome are required, nor which optional booleans (hasHSA, isSelfEmployed, hasCapitalGains) materially change the advice.

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 and resource ('Get personalized year-end tax optimization strategies') and scopes it to inputs the agent can recognize (income, deductions, situation). It does not, however, distinguish itself from close siblings such as generate_tax_plan or plan_multi_year_taxes, which an agent could easily confuse with this one.

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?

Timing is implied by 'year-end' and 'before year-end', which hints at the appropriate window, but there is no explicit when-to-use versus when-not, no mention of prerequisites, and no routing to the obvious alternatives (generate_tax_plan, plan_multi_year_taxes, optimize_capital_gains).

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that results include eligibility rules and limits, which is useful content context, but says nothing about result volume, pagination, or how the fixed (closed-world) dataset is versioned.

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, front-loaded with the action and resource, with the scope clause second. No filler or redundant restatement of the name, though it could have used the second sentence to route to a sibling instead of just restating scope.

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?

A read-only, single-optional-param listing tool with an output schema is a low-complexity case, and the description covers purpose, scope, and returned content (eligibility rules and limits). The main missing piece is disambiguation from the many deduction-adjacent siblings, which is a modest but real gap.

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% and the single optional parameter has a fully documented enum with a stated default of 'all'. The description's mention of above-the-line vs itemized maps meaningfully onto the enum values, but the schema already carries the semantic load, so this is at baseline adequacy rather than above it.

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 gives a specific verb and resource ('List available tax deductions') and bounds the scope with 'Covers both above-the-line and itemized deductions.' It does not, however, differentiate itself from close siblings like standard_vs_itemized or calculate_obbb_deductions, which an agent could easily confuse with a deduction-listing 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?

Usage is only implied: the wording suggests a reference/browse operation to look up deduction rules and limits, and the category enum hints at filtering. There is no explicit when-to-use statement, no mention of when to prefer standard_vs_itemized or check_credit_eligibility instead, and no prerequisites 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered without description effort. The description adds only the completeness scope ('all US states'), which aligns with openWorldHint=false, but contributes no further behavioral context such as data recency or sensitivity to changing tax law.

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, 9-word sentence with every word earning its place and no filler or redundancy. The core scoping ('all US states with no state income tax') is front-loaded.

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 0-parameter lookup whose output schema exists and whose annotations cover safety, the definition is nearly complete: an agent knows exactly what to invoke and what it will get. The only minor gap is the absence of a temporal caveat that state income-tax status can change over time.

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 has zero parameters and its input schema is trivially 100% covered, so there is nothing for the description to explain. Per the zero-parameter baseline of 4, the description needs no parameter documentation and adds appropriate value by narrowing the query scope.

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 uses a specific verb ('List') with an unambiguous resource ('all US states with no state income tax'), making the tool's scope instantly clear. It is inherently distinct from siblings like get_state_tax_info (per-state detail), compare_state_taxes (comparison), and analyze_relocation_taxes (relocation scenarios), none of which provide this exact filtered list.

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