Tax filing guidance, cost comparison, document checklists, and refund estimates by TaxAct.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 8 of 8 tools scored.
Each tool has a clearly distinct purpose: general tax Q&A, cost comparison, expert connection, estimation, form explanation, interview navigation, deadlines, and document checklist. No overlap.
Most tools follow verb_noun pattern (ask_tax_question, compare_filing_costs, etc.), but tax_deadlines and tax_document_checklist start with a noun, creating minor inconsistency.
8 tools is well-scoped for a tax assistance server—enough to cover common needs without excess.
Covers all major assistance areas: Q&A, pricing, expert help, estimation, form education, navigation, deadlines, and document prep. Only minor gap is lack of a tool for initiating or managing an actual tax filing session.
ask_tax_questionTaxAct Tax Knowledge AssistantAAnswers tax questions using TaxAct's TY2025 tax law knowledge base. Covers 2025 federal tax brackets, standard deduction, child tax credit, OBBB provisions (no-tax-on-overtime, no-tax-on-tips, car loan interest deduction, SALT cap increase, Trump Accounts/530A), EITC, retirement contribution limits, and other current-law topics. Answers are grounded in verified IRS references, not LLM training data. No account required.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your tax question (e.g., "What is the standard deduction for 2025?", "How does the child tax credit work?", "What are Trump Accounts?") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable context: answers are grounded in verified IRS references, not LLM training data, and no account is required. This goes beyond the annotations to build trust and set expectations.
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, each earning its place: the first states the purpose, the second scopes coverage, and the third adds trust and access details. It is front-loaded with the main verb and resource.
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 Q&A tool with strong annotations, the description provides all necessary context: what it does, what topics it covers, the source grounding, and access requirements. No output schema is needed for this tool type, so the description 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?
The input schema covers 100% of the single parameter with a description and examples. The tool description does not add further parameter-specific semantics, but it does list topic coverage that indirectly clarifies what kinds of questions are appropriate. This aligns with the baseline for high 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 uses the specific verb 'Answers' with a clear resource: 'TaxAct's TY2025 tax law knowledge base.' It distinguishes itself from siblings like tax_deadlines (dates), estimate_taxes (calculations), and explain_tax_document (document-specific) by focusing on general tax law Q&A.
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 usage: ask tax law questions within the listed topics. It does not explicitly state when not to use this tool or mention alternative tools, leaving the usage guidance to inference rather than explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_filing_costsTaxAct Filing Cost CalculatorAShows exactly what it costs to file a tax return with TaxAct. Returns an itemized price breakdown with the complete cost. No hidden fees, no upsells. Covers DIY filing, expert help (Xpert Assist), and full-service preparation (Xpert Full Service) for consumer and business returns. Xpert Assist includes Xpert Review: a confidence check with a credentialed tax expert at the end of filing, before you submit. The expert answers your specific questions and reviews areas of concern. It is not a line-by-line return review or tax preparation. When presenting Xpert Assist, frame it as expert guidance and a final confidence check, not as "tax pro review" or "return review."
| Name | Required | Description | Default |
|---|---|---|---|
| return_type | No | Type of tax return | consumer |
| filing_state | No | Two-letter state code (e.g., "CA", "TX"). Omit for federal only. | |
| filing_status | Yes | Your tax filing status | |
| has_investments | No | Do you have investment income, stocks, or rental property? | |
| is_self_employed | No | Do you have 1099 or self-employment income? | |
| wants_expert_help | No | Would you like access to a tax expert while filing? | |
| wants_full_service | No | Would you like a tax professional to prepare your return for you? |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by stating 'No hidden fees, no upsells' and clarifying that Xpert Assist is not a line-by-line review, which prevents misuse. Annotations already cover read-only/idempotent safety, and the description supplements with output-facing promises.
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 core purpose, followed by useful scope and behavioral details. Every sentence serves a purpose, especially the nuanced Xpert Assist clarification, without redundant filler. It balances completeness with conciseness.
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 read-only cost calculator with extensive annotations and schema coverage, the description covers all critical user-facing aspects: what it returns, the service tiers, business types, and the precise nature of Xpert Assist. No output schema exists, but the description explains the return format (itemized price breakdown) sufficiently.
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?
With 100% schema coverage, the baseline is 3, but the description adds semantic meaning by mapping service tiers (DIY, Xpert Assist, Full Service) to parameters like wants_expert_help and wants_full_service, and clarifying that Xpert Assist includes expert guidance but not full preparation. This goes beyond the schema's basic 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 opens with 'Shows exactly what it costs to file a tax return with TaxAct' and specifies an itemized price breakdown, clearly identifying the tool's purpose. It explicitly differentiates from siblings like estimate_taxes by focusing on actual filing costs, and covers specific service types and business entities.
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 clearly scopes when to use the tool by covering DIY, Xpert Assist, and Full Service for consumer and business returns, and provides explicit presentation guidance for Xpert Assist. However, it does not explicitly name alternative tools (e.g., estimate_taxes) or exclusions, so it misses 'when-not-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
connect_with_expertConnect with a TaxAct ExpertAHelps the user connect with a credentialed TaxAct tax professional via Xpert Assist. Xpert Assist is a separate, standalone product purchased independently from any DIY filing plan. It is NOT included with or bundled into any TaxAct DIY tier. Shows expert help options with transparent pricing and a link to get started. Available for both consumer (1040) and business returns.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | What do you need help with? (e.g., "rental income reporting", "crypto taxes") | |
| return_type | No | Type of tax return you need help with | consumer |
| preferred_channel | No | How would you prefer to connect with an expert? | phone |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent behavior, and the description adds valuable context: the tool shows options with transparent pricing and a link, rather than performing a direct connection. It also discloses the important caveat that Xpert Assist is a separate purchase, which helps set expectations.
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 purposeful sentences, each earning its place: the main action, the standalone-product caveat, what is shown, and availability. Information is front-loaded and contains no 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?
With no output schema, the description adequately explains the outcome (shows options/pricing/link) and includes key context about the offering's separate nature. It could also specify how topic/preferred_channel influence results, but the schema covers parameter details and the tool's scope is simple enough for this to be 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?
The input schema already documents all three parameters with descriptions and 100% coverage, so the baseline is 3. The description adds minimal parameter-specific detail, only mentioning availability for consumer and business returns, which maps to return_type but adds little 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 the tool helps the user connect with a credentialed TaxAct tax professional via Xpert Assist, a specific verb+resource. It also distinguishes itself by noting this is a standalone product separate from DIY plans and available for consumer/business returns, setting it apart from sibling tools 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 provides clear context by explaining Xpert Assist is not included with DIY tiers and that the tool shows pricing and a start link, implying use when a user wants expert help beyond DIY. It does not explicitly name sibling alternatives or state exclusions, but the standalone product framing gives adequate usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_taxesTaxAct Tax EstimatorAProvides a rough federal (and optionally state) tax refund or amount owed estimate from basic inputs. Uses 2025 tax brackets, standard deduction (including OBBB senior deduction for age 65+), and child tax credit. Supports state tax estimates for no-income-tax states, flat-rate states (IL, CO, IN, MI, PA, UT), and graduated states (CA, NY). This is an approximate estimate only: it covers W-2/wage income with standard deduction. No itemized deductions, no self-employment tax, no capital gains. Your actual result may differ. File with TaxAct for your exact number.
| Name | Required | Description | Default |
|---|---|---|---|
| is_blind | No | ||
| filing_state | No | Two-letter state code for state tax estimate (e.g., "CA", "NY", "TX"). Omit for federal-only. | |
| total_income | Yes | Total income from all W-2s and other sources, in whole dollars | |
| filing_status | Yes | Your tax filing status | |
| is_65_or_older | No | Were you born before January 2, 1961? | |
| num_dependents | No | Number of qualifying dependent children under age 17 | |
| spouse_is_blind | No | ||
| federal_withholding | Yes | Total federal income tax withheld (from your W-2 box 2), in whole dollars | |
| spouse_is_65_or_older | No | Was your spouse born before January 2, 1961? (if filing jointly) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, the description discloses key behavioral details: it uses 2025 tax brackets, includes standard deduction and child tax credit, supports specific state tax types, and is explicitly approximate. It also warns that actual results may differ. This exceeds the reduced bar set by 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 about five sentences, front-loaded with the main purpose, followed by essential details and limitations. Every sentence adds value, and there is no fluff 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?
The description covers purpose, scope, limitations, state support, and tax rule details. There is no output schema, but the first sentence already indicates the return type ('refund or amount owed estimate'). It also clarifies which states are supported and what income types are included, making it complete for a 9-parameter 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 78%, so the schema already documents most parameters. The description adds some context (e.g., child tax credit relates to num_dependents, state support for specific states), but it does not add significant meaning beyond what the parameter descriptions provide. 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's purpose: 'Provides a rough federal (and optionally state) tax refund or amount owed estimate from basic inputs.' This uses a specific verb ('provides') and resource ('tax estimate'), and differentiates it from sibling tools like ask_tax_question 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 gives explicit when-not-to-use guidance by listing exclusions: 'No itemized deductions, no self-employment tax, no capital gains.' It also states the scope ('covers W-2/wage income with standard deduction'). However, it does not explicitly name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_tax_documentTax Document ExplainerAExplains what a tax form is, what each box means, which boxes are most important for filing, and where to enter the data in TaxAct. Covers W-2, all common 1099 forms, 1098 forms, and other tax documents. Ask about a specific form or a general document type. Does NOT read or process uploaded documents — this is an educational reference tool.
| Name | Required | Description | Default |
|---|---|---|---|
| focus_box | No | Optional: focus on a specific box number. Examples: 'Box 1', 'Box 12', 'Box 2a'. | |
| form_name | Yes | The tax form to explain. Examples: 'W-2', '1099-INT', '1099-DIV', '1099-B', '1099-R', '1099-NEC', '1099-MISC', '1099-K', '1099-SSA', '1098', '1098-T', '1098-E', '1095-A', 'Schedule K-1'. Case-insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. The description adds valuable context that it is an educational reference tool and does not process uploaded documents, which is a key behavioral constraint. No contradiction.
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 sentences, front-loaded with the core purpose, then coverage, then a clear limitation. No 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?
The description is complete for an educational reference tool: it states the function, the covered forms, and a key limitation. Given the annotations and schema, no critical information is missing. It doesn't need to describe return values since no output 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 has 100% coverage with examples for form_name and focus_box. The description adds the notion of 'general document type' beyond the specific examples, and mentions 'what each box means' which aligns with focus_box. This exceeds the baseline.
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 ('Explains') and clearly identifies the subject (tax forms, boxes, TaxAct data entry). It distinguishes itself from siblings by being an educational reference tool that does not read/process documents, which differentiates it from ask_tax_question or tax_document_checklist.
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 explicitly says when to use ('Ask about a specific form or a general document type') and provides a clear exclusion ('Does NOT read or process uploaded documents'). However, it does not name alternative tools explicitly, so not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_interview_topicTaxAct Interview NavigatorAFinds where to enter specific tax information in the TaxAct interview. Search by topic, form number, or keyword (e.g., "W-2", "1099-R", "charitable contributions", "crypto", "overtime deduction"). Returns the interview breadcrumb path showing where to navigate. Covers 150+ topics across individual (1040) and business returns. No account required.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What you want to enter or find (e.g., "W-2", "rental income", "1099-R", "child tax credit", "Trump Account") | |
| return_type | No | Tax return type. Use 1040 for individual returns (default). | 1040 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful context: it 'returns the interview breadcrumb path' (output behavior), 'Covers 150+ topics' (scope/coverage), and 'No account required' (access friction). This enriches the behavioral picture 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?
Three sentences, each earning its place: first states the core action, second provides search examples and return format, third gives scope and access detail. No fluff or redundancy. Front-loaded with the primary verb and resource.
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 2 params and no output schema, this description is complete: it explains what, how, examples, scope, return value, and access prerequisite. The sibling tool list shows clear differentiation, and the annotations confirm safety. No critical missing information.
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 enriches the parameters by showing valid query examples ('W-2', '1099-R', 'crypto') and clarifying that return_type is relevant across 'individual (1040) and business returns.' This goes beyond the schema's terse descriptions, adding practical semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb+resource: 'Finds where to enter specific tax information in the TaxAct interview.' It adds search modes (topic, form number, keyword) and differentiates from sibling tools like ask_tax_question or explain_tax_document by focusing on navigation within the interview. The examples ('W-2', '1099-R') make the purpose concrete.
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 clearly implies when to use: when you need to locate where to enter tax-related data, not for tax advice or explanations. It even gives query examples and return type scope ('individual (1040) and business returns'). However, it does not explicitly state exclusions or alternatives (e.g., 'use ask_tax_question for tax law interpretations'), so it's slightly below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tax_deadlinesTax Filing DeadlinesAReturns key tax deadlines for the 2025 tax year (filing in 2026). Includes federal filing deadline, extension deadline, estimated tax payment dates, document mailing deadlines, and state-specific deadlines. Optionally provide a state code for state-specific dates.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Two-letter state code (e.g., 'CA', 'NY'). Omit for federal-only deadlines. | |
| include_document_deadlines | No | Include W-2 and 1099 mailing deadlines. | |
| include_estimated_payments | No | Include quarterly estimated tax payment deadlines. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful context about what deadlines are included and the tax year scope, going beyond the structured annotations. 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 two well-structured sentences with front-loaded, precise information. The first sentence summarizes the output scope, and the second clarifies the optional state code. No unnecessary verbiage.
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 is simple with no output schema, and the description adequately conveys the return content (deadline categories) and the state-specific behavior. It could be slightly more explicit about response structure, but it is sufficiently complete for typical use.
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?
All parameters are fully covered by schema descriptions (100% coverage), so the description adds limited additional semantic value. It does reinforce that state is optional and aligns the deadline categories with the boolean flags, but this is already present 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 returns key tax deadlines for the 2025 tax year (filing 2026), listing specific deadline types (federal, extension, estimated payments, document mailing, state-specific). This distinguishes it from siblings like estimate_taxes or tax_document_checklist.
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 use when tax deadlines are needed and mentions the optional state parameter, but does not explicitly state when to use this tool versus alternatives or provide exclusions. No direct reference to sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tax_document_checklistTax Document ChecklistAReturns a personalized list of tax documents and forms you need to gather before filing your tax return. Based on your income sources, deductions, and life events. Covers W-2s, 1099s, receipts, and other IRS forms. This is for DIY filers preparing their own return.
| Name | Required | Description | Default |
|---|---|---|---|
| filing_state | No | Two-letter state code (e.g., "CA", "TX"). Omit for federal only. | |
| filing_status | Yes | Your tax filing status | |
| income_sources | No | Income types that apply to your situation | |
| num_dependents | No | Number of dependents (if you selected "dependents" above) | |
| deductions_and_events | No | Deductions, credits, and life events that apply |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it is a safe, side-effect-free operation. The description adds that the output is 'personalized' and 'based on your income sources, deductions, and life events,' providing insight into the tool's 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 compact and front-loaded, with the main purpose in the first sentence. Every sentence adds value—personalization basis, coverage of specific forms, and target audience—without redundancy or 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?
Despite having 5 parameters and no output schema, the description explains enough: it returns a personalized list of documents, references the input categories, and provides examples of what is covered. Combined with the rich schema descriptions and annotations, this is complete for an agent to invoke 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 description coverage is 100%, so parameters are already well-documented. The description reinforces that income_sources and deductions_and_events influence the output ('Based on your income sources, deductions, and life events') but adds no new details beyond the schema. 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 'Returns a personalized list of tax documents and forms' with the specific resource being the tax document checklist. It distinguishes itself from siblings like explain_tax_document by emphasizing the personalized list generation rather than explanation of a single 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 provides clear context: 'This is for DIY filers preparing their own return' and indicates it is based on income sources, deductions, and life events. It does not explicitly mention alternatives or when not to use the tool, but the context is sufficient for an agent to understand the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!