taxact-mcp

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

Annotations already declare read-only, idempotent, non-destructive. The description adds value by stating 'no account required' and that answers are grounded in verified IRS references, enhancing trust 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 information-dense sentences: first states purpose and knowledge base, second enumerates topics and trust signals. 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?

For a single-parameter tool with comprehensive annotations and no output schema, the description fully covers purpose, scope, and trustworthiness, making it 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 a clear description and examples. The tool description adds domain-specific context on the scope of acceptable questions, which aids correct parameter usage.

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 answers tax questions using TaxAct's TY2025 knowledge base, lists specific covered topics, and distinguishes it from siblings like estimate_taxes or explain_tax_document.

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 indicates the tool is for tax law questions and specifies the scope (2025 federal topics). While it doesn't explicitly compare to siblings, the context signals and distinct purpose make it clear when to use.

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, indicating safe, non-destructive behavior. The description adds significant behavioral context: 'no hidden fees, no upsells,' details on what Xpert Assist includes, and guidance on how to present it. 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 well-structured, starting with the core purpose, then detailing covered services and the nature of Xpert Assist. Every sentence provides necessary information without fluff. The guidance on framing Xpert Assist is efficient and valuable.

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 tool with 7 parameters and no output schema, the description covers what the tool returns (itemized price breakdown, complete cost), the types of returns and services, and clarifies the Xpert Assist offering. It is sufficiently complete for an agent to understand and invoke correctly, with no missing critical 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 description coverage is 100%, so all parameters have descriptions in the schema. The tool description does not add extra meaning beyond what the schema provides for individual parameters; it only summarizes types of returns and services. Thus, minimal added value, consistent with 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?

The description clearly states the tool 'shows exactly what it costs to file a tax return with TaxAct' and specifies it returns an itemized price breakdown. It explicitly covers DIY, Xpert Assist, and Full Service for consumer and business returns, distinguishing it from sibling tools like estimate_taxes or connect_with_expert.

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 clarifies when to use the tool (to see filing costs) and explains the difference between Xpert Assist and Full Service, which helps in tool selection. However, it does not explicitly state when not to use it or name alternatives, though sibling names provide some 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 readOnly, idempotent, and not destructive. The description adds value by clarifying that the tool shows options and a link to get started, rather than directly connecting. 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 concise at four sentences, covering essential distinctions (separate product, pricing). It front-loads the main purpose. Could be slightly more efficient by merging some clarifications.

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 description explains the output (shows options, pricing, link) but lacks detail on the exact return format. Given no output schema, more specificity about what the user receives (e.g., list of plans, contact info) would improve completeness.

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 descriptions for all three parameters. The tool description does not add additional meaning beyond what the schema provides. Baseline is 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?

Description clearly identifies the action (connect with an expert), the specific resource (credentialed TaxAct tax professional via Xpert Assist), and distinguishes it from sibling tools like ask_tax_question by specifying it's about paid expert help. It also clarifies that Xpert Assist is a separate product, not bundled with DIY plans.

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 explains that Xpert Assist is a separate product and shows pricing, but does not explicitly state when to use this tool versus alternatives like ask_tax_question. The usage context is implied (when user wants professional help) but lacks direct comparison 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, which match the description's read-only nature. The description adds behavioral details like using 2025 brackets, OBBB senior deduction, and child tax credit, and lists supported state tax types.

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 but well-structured: first sentence states the purpose, then a list of covered aspects, then limitations and a call-to-action. It is efficient but could be slightly more concise by separating into bullet points.

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 9 parameters and no output schema, the description is quite complete: it explains the estimate scope (W-2 income, standard deduction), limitations (no itemized, self-employment, capital gains), and state support types. It omits return value format but that is acceptable for an estimate.

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 78%, and the description adds meaning beyond the schema by explaining the OBBB senior deduction, state support types, and the approximate nature of the estimate. The schema already covers most parameters with 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 it provides a rough federal/state tax estimate from basic inputs, using 2025 brackets and standard deduction. It distinguishes from sibling tools like ask_tax_question or compare_filing_costs.

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 notes it covers only W-2 income with standard deduction and excludes itemized deductions, self-employment tax, and capital gains. It advises that actual results may differ and suggests using TaxAct for exact numbers. It also specifies the limited state support types.

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 idempotentHint=true. The description adds that the tool does not read uploaded documents and is educational, providing context 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?

Three clear sentences with no waste. The description is efficiently structured and front-loads the main action.

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 educational reference tool with no output schema, the description fully explains its purpose, coverage, and constraints. No missing information needed 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 100% with descriptions for both parameters. The description adds examples of form names and the optional focus_box but does not significantly enhance meaning beyond what the schema provides.

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 'Explains what a tax form is, what each box means, which boxes are most important...' and lists covered forms. It distinguishes itself from sibling tools like upload_document by explicitly saying 'Does NOT read or process uploaded documents'.

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 advises 'Ask about a specific form or a general document type' and clarifies that it is an educational reference, not for processing uploads. It could better contrast with ask_tax_question but overall provides good 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 provide readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful context: 'No account required', 'covers 150+ topics', and 'Returns the interview breadcrumb path', which goes 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?

Four well-structured sentences, no filler. Front-loaded with main action, examples, result type, scope, and a bonus fact ('No account required'). Every sentence is necessary.

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 no output schema, the description explains the return (breadcrumb path) and covers input examples and scope. It lacks mention of error handling or edge cases, but overall provides sufficient context 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 coverage is 100% (both parameters described). The description adds value by providing examples for 'query' (e.g., 'W-2', 'crypto') and explaining 'return_type' with default and scope, surpassing the schema's own 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 the tool finds where to enter specific tax information in the TaxAct interview, with specific verb ('Finds') and resource ('where to enter'). It provides examples ('W-2', '1099-R') and distinguishes itself from siblings like ask_tax_question.

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 explains when to use (search by topic, form number, or keyword) and hints at what it returns (breadcrumb path). It does not explicitly state when not to use or name alternatives, but the context is 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 already indicate readOnlyHint, idempotentHint, destructiveHint false. The description adds useful behavioral context: includes specific deadline types (federal, extension, estimated, document, state) and clarifies the tax year scope. 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?

Two concise sentences with no wasted words. The most important information (what it returns, tax year, optional state) is front-loaded. Every clause 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?

Without an output schema, the description covers the main return types (federal, extension, estimated, document, state). It could mention the format (e.g., list of dates) but is adequate for a read-only info 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 coverage is 100% with detailed descriptions. The description adds some context (e.g., 'optional for state-specific', 'federal-only'), but largely reinforces what's in the schema. With full coverage, baseline is 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?

The description clearly states the tool returns key tax deadlines for the 2025 tax year, listing specific types (federal, extension, estimated, document, state). The verb 'Returns' and resource 'tax deadlines' are precise, and it distinguishes from sibling tools like 'ask_tax_question' or 'estimate_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 description explains when to use the tool: for tax deadlines in the 2025 tax year, with optional state code. It does not explicitly state when not to use it or list alternatives, but the context is clear enough.

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 the tool as read-only, idempotent, and non-destructive. The description adds that the tool generates a personalized list based on user inputs, providing meaningful 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 three clear, front-loaded sentences. Each sentence adds value: first states purpose, second explains logic, third gives examples and target audience. 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?

The tool has five parameters and no output schema. The description explains the output is a personalized list and gives examples of documents. It does not specify exact format but is adequate for a checklist 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?

The input schema has 100% parameter description coverage, so baseline is 3. The description adds value by explaining that the checklist covers specific forms (W-2s, 1099s) and is based on life events, contextualizing parameter usage.

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 personalized checklist of tax documents based on income sources, deductions, and life events. It distinguishes itself from sibling tools like 'explain_tax_document' and 'tax_deadlines' by focusing on preparation.

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 specifies that the tool is for DIY filers preparing their own return, providing clear context for use. It does not explicitly mention alternatives or when not to use, but the context implies it is not for professional preparers.

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