Arc & Ledger Tax Tools

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description adds specific return details (booking link, next steps, office identity). This goes beyond annotations by explaining what the tool returns.

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

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

The description is two sentences, front-loaded with usage context, and contains no unnecessary information. Every sentence adds value.

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?

Given the output schema exists, the description needn't detail return structure, but it does summarize the return content well. The tool is simple with two parameters and clear annotations, so the description is adequately complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add new meaning to the parameters beyond what the schema provides. The enum values are already described in the schema, and the optional topic parameter is self-explanatory.

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 states the tool's purpose: to book a consultation with Arc & Ledger. It specifies the verb (book), resource (consultation), and scope. It distinguishes well from sibling tools which are checks and estimates.

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 explicitly says when to use this tool ('when a user wants to talk to, hire, or get a consultation'). It provides clear context, though it does not explicitly mention when not to use it or list alternatives. Sibling tools are sufficiently different, so no exclusion is necessary.

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 and destructiveHint=false. The description reinforces this by stating 'Returns whether...', confirming it is a read-only query. It adds value by detailing the exact information returned, which is beyond what annotations provide.

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 paragraph of roughly 60 words, front-loaded with the use case. Every sentence contributes necessary information without redundancy, making it efficient and easy to parse.

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?

Given the complexity of Form 5472, the description covers all key aspects: entity distinction, required actions, deadline, penalty, and exclusions (e.g., partnerships). An output schema exists, so return values need not be explained. The description is fully adequate for an agent to decide when to invoke this 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%, so parameters are fully described in the schema. The description does not add new semantic details beyond the schema, but it subtly explains the relevance of entity type differences (e.g., single-member vs multi-member). Baseline 3 is appropriate.

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

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

The description clearly states the tool returns 'whether Form 5472 with a pro-forma Form 1120 is required, the reportable-transaction rule, the deadline and extension, the annual compliance set, and the penalty for not filing.' It distinguishes between single-member LLC (files 5472) and multi-member LLC (files 1065), making the purpose specific and unambiguous.

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 begins with 'Use this when a non-US person who owns a US company... asks whether they must file Form 5472,' providing explicit context. However, it does not explicitly state when not to use the tool or mention alternative tools, though the context of sibling tools (e.g., check_fbar_fatca) implies differentiation.

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. The description adds behavioral context by stating the tool checks obligations, thresholds, and penalties, confirming it is non-destructive. No contradictions.

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

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

A single, well-structured sentence that front-loads the use case and packs all necessary information efficiently without waste.

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?

Given the complexity of FBAR/FATCA, the description covers when to use, what is checked (thresholds, penalties, catch-up), and implies the output will inform obligations. With output schema present, this is complete.

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% with each parameter described. The tool description adds minimal extra meaning beyond the schema, meeting the baseline for full coverage.

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 states the tool is for checking US reporting obligations (FBAR/FATCA) for foreign accounts, with specifics on thresholds, penalties, and catch-up options. It distinctively targets foreign account issues, differentiating from sibling tools like check_5472_obligation.

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 explicitly starts with 'Use this when a user has foreign bank accounts...' providing clear usage context. However, it does not explicitly mention when not to use or compare to alternatives, leaving some room for improvement.

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 indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral details beyond this, such as 'Returns a reason-specific screen, whether a return is commonly attached, current document-handling cautions, and official sources,' which aligns with a read-only screening tool and provides useful transparency.

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 concise (three sentences) and front-loaded with the primary usage case. It efficiently conveys key information without redundancy, though could be slightly more structured with bullet points for better readability.

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?

Given the tool has an output schema (not shown but indicated as true), the description sufficiently covers the tool's purpose, usage, and key outputs. It provides enough context for an agent to invoke correctly, leaving only minor gaps in explicit output details.

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%, with each parameter having a detailed description. The tool description does not add additional parameter semantics beyond the schema; it summarizes the purpose but does not enhance parameter understanding. Baseline score of 3 is appropriate given complete schema coverage.

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 states the tool's purpose: screening ITIN eligibility and application paths. It uses specific verbs ('screen') and resources ('ITIN reason', 'Form W-7 path'), and the description distinguishes it from sibling tools like check_5472_obligation or check_fbar_fatca by focusing on ITIN eligibility.

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 explicitly states when to use ('when someone asks whether a federal tax purpose may support an ITIN application') and provides a negative use case ('Entity ownership or a bank request alone does not establish personal ITIN eligibility'). While it does not name alternative sibling tools directly, the context is clear enough for selection.

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 declare readOnlyHint=true, so no write behavior. The description adds that the tool is a screening mechanism (not a guarantee), lists forms needed, explains the coarse purpose of tax_account_type, and describes the brief parameter effect. No contradictions with annotations.

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 front-loaded with the primary usage scenario. Every sentence adds value: it lists resolution paths, forms, and important caveats (no guarantee, brief mode). Despite length, it remains focused and well-structured.

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?

Given the tool's complexity (6 parameters, output schema exists), the description sufficiently covers when to use, what it screens, dependencies (filing compliance, ability to pay), and limitations. With an output schema, return values need not be detailed 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 100%, so baseline is 3. The description does not add significant new meaning beyond the schema's parameter descriptions, though it provides overall context. It mentions the brief parameter and the coarse screening role of tax_account_type, but that is already in 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 description clearly states the tool's purpose: to screen IRS resolution paths when someone owes back taxes. It specifies the context ('someone owes the IRS back taxes and asks how to settle') and distinguishes it from sibling tools (e.g., check_5472_obligation) by focusing on payment plans, offers in compromise, etc., not other tax obligations.

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 explicitly states when to use the tool ('Use this when someone owes the IRS back taxes...') and includes conditions for different resolution paths. It also provides guidance on parameters like ability_to_pay and cautions that it never guarantees an IRS outcome, offering clear usage context.

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 indicate read-only and non-destructive. The description adds value by explaining the tool flags likely nexus and explains a trap, giving insight into behavior beyond the annotations.

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

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

The description is two sentences, front-loaded with the use case, and every sentence adds value. No fluff.

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?

Given the tool's complexity and the existence of an output schema, the description covers inputs, core logic (nexus flags, physical-trap), and use case. It is complete for an agent to decide when to invoke.

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%, so baseline is 3. The description mentions the parameters but does not add significant new meaning beyond the schema descriptions. The tool's function is summarized, but no extra parameter constraints or formatting details are provided.

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 states the tool checks economic nexus for sales tax collection, specifies inputs (annual sales, transaction count, states), and outputs (flags, explains physical-nexus trap). It distinguishes from sibling tools covering other tax obligations.

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 explicitly says 'Use this when an online seller or e-commerce/Amazon business asks whether they must collect sales tax in a state,' providing clear context. It doesn't explicitly exclude scenarios, but given sibling tools, the use case is well-defined.

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 indicate readOnlyHint=true. The description adds value beyond annotations by explaining the tool's output: default rate, treaty rate, documentation needed, and refund process. No contradictions.

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 paragraph that is concise and front-loaded with key usage context. It could be slightly more structured but remains clear and efficient.

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?

Given the tool's complexity (3 parameters, all with enums, output schema present), the description covers all necessary aspects: when to use, what returns, and parameter context. It is fully adequate.

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%, so the description's additional detail on forms (W-8BEN, W-8BEN-E, etc.) is helpful but not essential. It adds marginal value over the schema's parameter descriptions.

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 states that the tool checks US withholding and treaty rates for non-US persons receiving US-source income. It specifies the income types and output details, and distinguishes it from sibling tools which cover different tax topics.

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 provides explicit context for when to use: when a non-US person or company asks about withholding, treaty rates, or forms. It lists income types covered. While it does not explicitly list when not to use or mention alternatives, the sibling tool list provides that context.

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 and destructiveHint=false, so the description's claim of comparing and recommending is consistent and adds context (states and factors) but not further behavioral details beyond the annotations.

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 wasted words. Efficiently conveys when to use, what it compares, and what it outputs. Could be slightly more structured but remains highly concise.

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?

Given the tool has no required parameters and an output schema (implied), the description covers the essential context: target user, states compared, comparison factors, and recommendation output. It sufficiently prepares an agent for correct usage.

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 has 100% description coverage; each parameter's schema description is detailed. The tool description adds high-level context but does not provide additional parameter-specific meaning beyond what the schema offers.

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?

Description clearly states the tool compares US states for LLC/company formation, lists specific states (Wyoming, New Mexico, Delaware, California), and mentions factors compared (fees, cost, tax, privacy, approval time). It distinguishes from sibling compare_llc_scorp which compares entity types.

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?

Description explicitly tells when to use this tool: 'when someone asks which US state to form their LLC or company in'. While it doesn't mention when not to use or list alternatives, the context and sibling tool names provide enough differentiation.

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, and the description adds transparency about what the tool computes (side-by-side tax comparison, payroll costs, California franchise taxes, break-even zone). It also notes caveats like the exclusion of SMLLC gross-receipts fee. Minor omission: no mention of output structure, but output schema covers 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?

The description is two sentences with no filler. The first sentence immediately states the use case, and the second lists the key outputs. Every word 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?

Given the presence of an output schema (as indicated by context signals), the description adequately covers purpose, usage, and key behavioral aspects. It includes caveats about California taxes and default salary, making it sufficient for a read-only comparison tool with 4 parameters.

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% with detailed parameter descriptions. The description adds value by explaining the default salary behavior ('midpoint of reasonable-comp range') and referencing 'estimate_reasonable_comp' for more precise estimates, which goes 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 description uses a specific verb 'compare' and resource 'LLC vs S-Corp', clearly stating the use case for self-employed users or single-member LLC owners. It distinguishes itself from sibling tools like 'compare_formation_states' by focusing on tax savings from S-Corp election.

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 explicitly advises when to use the tool: when a self-employed user or SMLLC owner asks about S-Corp savings. It implicitly excludes other scenarios and references alternative tools like 'estimate_reasonable_comp' for salary estimation.

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 indicate readOnlyHint=true, so the description does not need to cover safety. It adds that the tool returns due dates, extensions, and penalties, but does not elaborate on data source, update frequency, or behavior beyond what the schema implies.

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 three sentences, front-loaded with the usage scenario, and contains no filler. Every sentence adds value efficiently.

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?

Given 5 parameters, required one, and an output schema, the description is fairly complete. It specifies target audience, included forms, and output type. It could explicitly note that it covers only federal forms, but that is implied.

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 parameter descriptions are detailed. The tool description does not add new meaning about the parameters themselves; it focuses on output. Baseline 3 is appropriate.

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

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

The description clearly states it returns federal form deadlines and penalties for US business owners/nonresidents, mentioning specific forms like 5472, FBAR, and BOI. It distinguishes from sibling tools that focus on single forms, but could more explicitly exclude state or non-federal requirements.

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 tells when to use it ('when a US business owner...asks what US forms they must file and when') and provides context about non-US founders. It does not give explicit when-not-to-use or alternative tools, but the context of sibling tools implies scope limitation.

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?

Discloses important behaviors: amount_shown is 'never stored', received_date computes response deadline, brief flag skips generic guidance. Annotations (readOnlyHint=true, destructiveHint=false) are consistent and enhanced by these details.

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 wasted words. Front-loaded with purpose and usage, followed by parameter guidance. Efficient and 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?

Covers purpose, when to use, parameter semantics, and behavioral details. Output schema exists, so return value description is unnecessary. No gaps given the tool's simplicity.

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?

Adds meaning beyond schema descriptions: explains brief effect, received_date usage for deadline, amount_shown used for context only, notice_code includes examples. Schema coverage is 100%, but description enriches understanding.

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 states the tool decodes IRS/state tax notices, specifying the trigger (user mentioning a notice) and the output (meaning, deadline, action). This distinguishes it from sibling tools like 'estimate_irs_penalty' or 'check_resolution_options'.

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?

Explicitly tells when to use ('when a user mentions receiving an IRS or state tax letter or notice') and what parameters to provide (notice code, optional date/amount, brief flag). Lacks explicit 'when not to use' but context with siblings makes it largely clear.

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 indicate readOnlyHint=true, so the tool is safe and non-destructive. The description adds behavioral details beyond annotations: it estimates reimbursements/tax effects, applies two separate 2026 mileage rates, and explains three requirements. This provides a clear picture of what the tool computes and explains, enhancing transparency.

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 concise: two sentences that front-load the use case and then list key actions. Every sentence adds value, with no redundancy or fluff. It efficiently conveys purpose, scope, and key features.

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?

Given 6 optional parameters, full schema coverage, annotations, and the existence of an output schema, the description provides sufficient context. It explains the tool's role, the expenses it covers, and the key computations. Minor omission: no mention of typical output structure, but that is covered by the output schema. A score of 4 reflects completeness for this estimation context.

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%, so all parameters have descriptions. The tool description provides overall context (e.g., 'applies the two separate 2026 mileage rates') but does not add substantial new semantics beyond the parameter-level descriptions. With full schema coverage, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool is for S-corp or C-corp owners asking about accountable plan reimbursements for specific expenses like home-office, mileage, and cell-phone. It also explicitly mentions estimating reimbursement/tax effect, applying 2026 mileage rates, and explaining three requirements, making it distinct from sibling tools like estimate_augusta_rule or estimate_reasonable_comp.

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 begins with 'Use this when an S-corp or C-corp owner asks...' which provides a clear trigger condition. While it does not explicitly state when not to use or list alternatives, the context and sibling tools indirectly guide appropriate usage. The specificity of the use case compensates for the lack of explicit 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=true and destructiveHint=false. The description adds context that the tool 'screens' limits and 'calculates conditional amounts,' which aligns with read-only behavior. It does not contradict annotations and adds useful behavioral context beyond what annotations provide.

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 three sentences, front-loads the usage scenario, and is free of filler. Every sentence contributes value: when to use, what it does, and how it handles the logic.

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?

Given the tool's complexity (tax rule screening with 3 parameters and an output schema), the description covers the core behavior and use case. It mentions calculating conditional amounts and separating owner/business aspects. The output schema fills gaps on return values, so completeness is good.

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 baseline is 3. The description does not add significant meaning beyond the schema; it mentions screening day limits but does not elaborate on parameter details. The schema descriptions are already comprehensive.

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 explicitly states the tool screens the 14-day home-rental rule (IRC 280A(g)), calculates conditional amounts, and separates owner exclusion from business deduction. It clearly distinguishes this from sibling tools like estimate_rental_income by naming the specific tax rule and context.

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 begins with 'Use this when a business owner asks about...' and lists specific scenarios (Augusta rule, renting to a related business, fewer-than-15-day exclusion). It also notes the separation of owner and business sides, providing clear context for when to use this tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, which align with the description's estimation nature. The description adds context about specific penalties and relief paths without contradicting annotations.

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 usage guidance, followed by a precise list of what the tool estimates. No extraneous words.

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?

Given the tool's simplicity (3 params, has output schema, no nested objects), the description covers when to use, what it estimates, and relief paths. No gaps identified.

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?

Input schema has 100% description coverage, so each parameter is already documented. The description does not add new parameter-level details beyond the schema, meeting the baseline expectation.

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 specifies the verb 'estimate' and the resource 'IRS penalties and interest', and distinguishes from sibling tools like check_resolution_options and decode_irs_notice by focusing on penalty/interest estimation and relief paths.

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 explicitly states when to use this tool ('when someone owes the IRS and asks how much the penalties and interest will be') and implies the context (late filing/paying costs). It lacks explicit exclusions or alternatives but provides sufficient context.

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 indicate readOnlyHint=true, and the description confirms read-only behavior by describing computation and estimation. It adds valuable behavioral details beyond annotations: annualizing income, calculating safe-harbor targets, providing per-quarter amounts and due dates, and handling California's unique installment schedule. No contradictions with annotations.

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 extremely concise: two sentences that front-load the usage scenario and then list the key outputs. Every clause adds essential information (federal taxes, safe harbor, quarterly amounts, due dates, California timing). No wasted words or repetition.

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?

Given the complexity of quarterly tax estimation, the description covers major outputs: federal taxes, safe harbor, quarterly amounts, and due dates. It also notes California's specific timing. The output schema is present, so return values need not be described. However, it omits explicit mention that for non-California states only federal figures are provided, though this is implied in the state parameter description. Overall, quite complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds contextual meaning beyond the schema by explaining how parameters tie to real-world concepts like annualized income and safe-harbor targets. For example, it mentions California installment timing, which relates to the state parameter. While schema adequately describes each parameter, the description enriches understanding of their combined use.

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 explicitly states the tool's purpose: 'Use this when a freelancer or business owner asks how much estimated tax to pay or whether they are underpaid for the year.' It lists specific computations (federal self-employment and income tax, safe-harbor target, per-quarter amounts, due dates, California installment timing), clearly distinguishing it from siblings like estimate_irs_penalty or estimate_rental_income.

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 opens with a clear usage scenario: 'Use this when a freelancer or business owner asks how much estimated tax to pay or whether they are underpaid.' It does not explicitly list when not to use or name alternative tools, but the context of sibling tools provides implicit differentiation. A score of 4 reflects clear guidance without 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=true and destructiveHint=false. The description adds value by detailing outputs (salary range, distribution, tax savings, IRS test) and a caveat about needing a comp study, expanding beyond annotation hints.

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

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

The description is two clear, front-loaded sentences. Every sentence provides essential information without fluff.

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 2 parameters fully described in schema and an output schema present, the description adequately covers use case, inputs, outputs, and a key caveat. No gaps remain.

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 description does not need to add much. It mentions 'Given net profit and what drives it' but provides no additional details beyond 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 description specifies the tool estimates S-corp owner reasonable compensation salary range, with clear verb and resource. It distinguishes from sibling tools by focusing on this specific tax topic.

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 explicitly states when to use ('when an S-corp owner asks...'). It implies context but does not list exclusions or alternatives, though alternatives are not obvious given sibling tool names.

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 adds significant behavioral context beyond annotations: it explains the tool computes net rental income, depreciation, passive-loss rules, 14-day rule, and marginal tax effect. Annotations have readOnlyHint: true which aligns since it's a calculation. No contradictions.

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 paragraph of four sentences, front-loaded with usage guidance, and every sentence adds value. No fluff or 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?

Given the complexity (10 parameters, 1 required) and the presence of an output schema, the description covers the essential behavioral aspects and return logic. It doesn't detail return format but output schema likely handles that. Minor gap: no mention of what the response contains (e.g., JSON fields).

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% with each parameter having a clear description. The tool description does not elaborate on parameters further, which is acceptable given the full schema. Baseline 3 as per guidelines since schema carries the burden.

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 states the tool computes tax owed on rental income and deductibility of losses, listing specific calculations. However, the name 'estimate_rental_income' slightly misaligns with the title and description focusing on tax estimation, not income itself. Still clearly distinguishes from sibling tools like estimate_irs_penalty.

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 begins with 'Use this when...' providing a clear, explicit usage context. It specifies two scenarios: asking about tax on rental income or whether a rental loss is deductible. This directly guides the agent on when to invoke this tool.

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

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

Annotations already declare readOnlyHint=true. The description adds detail on what the tool covers (box-by-box guide, pre-filing checklist) and the effect of brief=true, providing added behavioral context beyond annotations.

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 dense paragraph that efficiently conveys scope, usage, and alternatives. While not overly concise, it avoids fluff and front-loads the use case.

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?

Given the presence of an output schema, the description sufficiently covers when, what, and how. It lists covered forms, exclusions, and parameter effects, making it complete for an explanation 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 covers 100% with descriptions. Description enriches with concrete examples ('W-2', '1099-K'), max length hint, and explanation of the brief parameter, adding 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 description clearly states it explains US tax documents, lists specific forms (W-2, 1099 family, etc.), and distinguishes from sibling tool decode_irs_notice.

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?

Explicitly tells when to use ('when a user receives a US tax form...'), when not to use ('For IRS letters and notices use decode_irs_notice instead'), and mentions the brief parameter for shorter answers.

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 declare readOnlyHint=true, and the description adds content details (service-specific list, first-year extras, secure file sending). No contradictions; it provides useful behavioral context beyond annotations.

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 efficiently convey purpose, usage context, and output scope. Front-loaded with actionable guidance with zero wasted words.

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?

Given 7 enum options and a boolean parameter, the description covers the tool's scope well. An output schema exists, so omission of return structure details is acceptable.

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% with both parameters described. The description adds value by explaining the effect of first_year_client on output, going beyond schema definitions.

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 states the tool returns a document checklist for specific US tax filings, listing exact services. It distinguishes from sibling tools like check_5472_obligation and check_fbar_fatca by focusing on document gathering.

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 explicitly says 'Use this when someone asks what documents...' providing clear context. It implies when to use vs siblings but lacks explicit when-not-to-use or alternative tool references.

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 declare readOnlyHint=true and destructiveHint=false, which the description does not contradict. The description adds behavioral context beyond annotations: 'never a single committed number' and clarifies what the response includes (line items, next steps). This adds value without redundancy.

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

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

The description is two sentences with no wasted words. The first sentence frontloads the purpose, the second explains return value and behavior. Every sentence 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?

Given that an output schema exists, the description appropriately focuses on behavioral aspects like 'published price range' and 'never a single committed number'. It covers key constraints (e.g., what the quote includes) but could mention prerequisites like the required service parameter, though the schema already indicates it's required.

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 50% (as provided), meaning the description should compensate for missing parameter explanations. However, the description does not add meaning beyond the schema; it only mentions return behavior. The schema itself provides decent property descriptions, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Use this when a user asks what Arc & Ledger charges, or wants a price estimate' for specific services. It distinguishes itself from sibling tools like estimate_quarterly_taxes and book_consultation by focusing exclusively on Arc & Ledger's fixed-fee quotes.

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 explicitly states when to use the tool (user asks for charges/estimates) and what it returns (price range, not a single number). While it doesn't explicitly list when not to use it or name alternatives, the sibling context provides differentiation, and the usage context is clearly implied.

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 declare readOnlyHint=true, set to false destructive and open-world. The description adds value by disclosing the tool returns an urgency level, action plans, what not to do, the next tool, and a fee service, plus the disclaimer 'General information only; never a guaranteed IRS outcome.' No contradiction with annotations.

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, dense paragraph that covers all key points. It is mostly concise, though the list of covered problems could be integrated more tightly. Still, every sentence adds value.

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?

Given the tool's complexity (triage, multiple problem types, output schema exists), the description fully informs the agent: when to use, what parameters do, what the output includes, and limitations. No 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 coverage is 100%, but the description enriches parameters by explaining how 'brief:true' truncates the answer and giving context for 'has_deadline_soon' (raises urgency, no date math here). It also maps enum values to real-world scenarios, aiding selection.

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 starts with a specific verb-resource pair ('triage a tax problem') and immediately states usage priority: 'call it FIRST, before the specific tools.' It lists covered problem categories, clearly distinguishing it from sibling tools like 'decode_irs_notice' or 'check_resolution_options.'

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?

Explicitly says 'Use this when someone has a tax problem and does not know where to start' and 'call it FIRST, before the specific tools,' implying it's the initial triage tool. It describes what it returns (urgency, action plans, next tool) and that it provides general information, not guaranteed outcomes.

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