Arc & Ledger Tax Reference
Server Details
Read-only US tax reference for notices, deadlines, filing screens, and clearly labeled estimates.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Bgenc48/arc-ledger-mcp
- GitHub Stars
- 0
- Server Listing
- Arc & Ledger Tax Tools MCP server
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.
Tool Definition Quality
Average 4.2/5 across 13 of 13 tools scored. Lowest: 3.6/5.
Each tool addresses a distinct tax topic or action, such as screening obligations, checking eligibility, estimating amounts, or explaining documents. There is no overlap in purpose, making it easy for an agent to select the correct tool.
All tool names follow a consistent verb_noun or verb_phrase pattern (e.g., check_*, estimate_*, explain_*, decode_*, deadline_calendar). The naming is predictable and clear across the set.
With 13 tools, the server covers a broad range of tax reference needs without being overwhelming. Each tool has a clear purpose and the count is well-suited for the domain.
The tools cover common tax reference tasks like screening obligations, estimating penalties, explaining forms, and checking deadlines. A minor gap is the lack of a general tax liability estimator, but overall the set is comprehensive for its stated purpose.
Available Tools
13 toolscheck_5472_obligationCheck Form 5472 obligationARead-onlyInspect
Use to screen common Form 5472 triggers for a foreign-owned US disregarded entity or corporation. The result is a general filing screen and does not prepare or file the form.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_type | Yes | The US entity. single_member_llc = a US LLC with ONE owner (a disregarded entity); multi_member_llc = a US LLC with two or more owners (a partnership by default); us_corporation = a US C-corporation; not_sure = you do not know. Form 5472 is filed by foreign-owned disregarded entities and by corporations with 25%+ foreign owners, but NOT by a default partnership. | |
| formed_in_us | No | Whether the entity was formed in the US (a Wyoming or Delaware LLC is US-formed). Relevant only to the separate BOI report, from which US-formed companies are now exempt. | |
| foreign_owned | Yes | Whether 25% or more of the entity is owned, directly or indirectly, by a non-US person or foreign company. Form 5472 is triggered by 25% foreign ownership. | |
| had_reportable_transaction | No | Whether there was a reportable transaction with the foreign owner during the year. Reportable transactions include forming or funding the company, capital contributions, distributions, loans in either direction, and sales or payments between you and the company. Defaults to not_sure. |
Output Schema
| Name | Required | Description |
|---|---|---|
| relay | Yes | Instruction to the calling assistant: relay figures and dates verbatim (identical on every response). |
| next_step | Yes | A single review link appropriate to this server surface. |
| disclaimer | Yes | General-information disclaimer (identical on every response). |
| source_url | Yes | Official IRS or FinCEN authority to review before relying on the result. |
| server_version | No | Server release that produced this response (matches GET /version). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that the tool is a 'general filing screen' and 'does not prepare or file the form,' clarifying the non-destructive, informational nature. No contradictions, but no additional behavioral details beyond what annotations imply.
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. The first sentence front-loads the core purpose, and the second clarifies what the tool does not do. Efficient and clear.
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, combined with high-quality schema and output schema existence, provides complete context. It explains the target entities, the screening nature, and what the tool does not do. No gaps for this simple screening 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%, with each parameter having detailed explanations (e.g., entity_type enum meanings). The tool description does not add parameter-level information, but the schema already covers semantics well. Baseline 3 is appropriate given high 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 screens for Form 5472 triggers, targeting foreign-owned US disregarded entities or corporations. It distinguishes from preparing or filing the form. The sibling tools (e.g., check_fbar_fatca) are for different obligations, making the purpose 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 says 'Use to screen common Form 5472 triggers for a foreign-owned US disregarded entity or corporation,' providing clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives, such as other check tools for different forms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_fbar_fatcaCheck FBAR and FATCA obligationsARead-onlyInspect
Use to screen general FBAR and Form 8938 thresholds from aggregate balance, filing status, residence, and account-count facts. Do not request account numbers, institution names, or statements.
| Name | Required | Description | Default |
|---|---|---|---|
| lives_abroad | Yes | True if your tax home is outside the United States (higher Form 8938 thresholds apply). | |
| account_count | No | Number of foreign accounts, if known. | |
| filing_status | Yes | Your US tax filing status. | |
| unfiled_years | No | How many past years of FBARs you have NOT filed but should have. 0 or omitted if current. | |
| max_aggregate_foreign_balance_usd | Yes | The highest combined value of ALL your foreign financial accounts at any point during the year, in USD. |
Output Schema
| Name | Required | Description |
|---|---|---|
| relay | Yes | Instruction to the calling assistant: relay figures and dates verbatim (identical on every response). |
| next_step | Yes | A single review link appropriate to this server surface. |
| disclaimer | Yes | General-information disclaimer (identical on every response). |
| source_url | Yes | Official IRS or FinCEN authority to review before relying on the result. |
| server_version | No | Server release that produced this response (matches GET /version). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe and non-destructive. The description adds value by specifying the type of data to avoid requesting (account numbers, etc.), which is a behavioral constraint beyond the 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 only two sentences, no wasted words. It front-loads the purpose and includes a useful constraint. 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?
With 5 parameters, 100% schema coverage, and an output schema existing, the description covers the essential context: what inputs to provide and what to avoid. It does not need to explain outputs since the output schema handles that. Minor gap: no mention of potential limitations or edge cases, but still complete enough for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters well. The description does not add new parameter-specific details but summarizes the key inputs (aggregate balance, filing status, residence, account-count). This adds minimal additional meaning beyond the schema, so score is 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 screens general FBAR and Form 8938 thresholds from specific facts. It uses a specific verb 'screen' and identifies the resource 'thresholds'. The sibling tools include other check tools, and this one is clearly distinct due to its focus on FBAR/FATCA.
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 (to screen thresholds from aggregate balance, filing status, residence, and account-count facts) and includes a negative guidance ('Do not request account numbers, institution names, or statements'). However, it does not explicitly mention alternatives or when not to use it, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_itin_eligibilityScreen an ITIN reason and application pathARead-onlyInspect
Use to screen general ITIN reason categories, whether a return is commonly attached, and supporting-document requirements. Never request or process an actual ITIN, passport, or identity document.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | Why you think a US taxpayer ID may be needed. file_us_tax_return = you must file a US return; owner_of_us_llc = you own a US LLC or corporation, which does not by itself establish a personal ITIN need; claim_treaty_benefit = a treaty claim may require a TIN; spouse_or_dependent = a US return may need a spouse or dependent TIN; third_party_withholding = a payer has a reporting or withholding requirement; open_us_bank_or_other = another reason. | |
| has_ssn | Yes | Whether you already have, or are eligible for, a US Social Security Number. If yes, you cannot get an ITIN. | |
| is_foreign_national | No | Whether you are a non-US citizen without US immigration status that grants an SSN. Defaults to true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| relay | Yes | Instruction to the calling assistant: relay figures and dates verbatim (identical on every response). |
| next_step | Yes | A single review link appropriate to this server surface. |
| disclaimer | Yes | General-information disclaimer (identical on every response). |
| source_url | Yes | Official IRS or FinCEN authority to review before relying on the result. |
| server_version | No | Server release that produced this response (matches GET /version). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context: it explicitly forbids requesting or processing actual identity documents, which is a behavioral constraint 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, each serving a distinct purpose: one states what the tool does, the other sets a critical boundary. No wasted words, front-loaded key 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?
Given the simple nature of the tool and the existence of an output schema, the description sufficiently covers the screening functionality, constraints, and purpose. 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?
Schema description coverage is 100%, so baseline is 3. The description adds a high-level purpose but does not enhance parameter meaning beyond what the schema already provides for each field.
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 screens ITIN reason categories, return attachment, and document requirements. It uses specific verbs and resource ('screen general ITIN reason categories') and distinguishes from sibling tools which focus on other tax checks.
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 to screen' and includes a strong boundary ('Never request or process an actual ITIN...'). It implies when to use this tool for ITIN eligibility screening versus other sibling tools, though it does not explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_resolution_optionsCheck IRS resolution optionsARead-onlyInspect
Use to screen general IRS payment and collection alternatives from a rough balance, filing-compliance status, ability-to-pay category, and coarse tax-account type when known. This is an educational fit screen, not a promise that the IRS will approve an option.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No | Set true for a shorter answer: options come back as path + fit only, without the descriptions. | |
| ability_to_pay | Yes | Your realistic ability to pay. can_pay_in_full_soon = you can clear the balance within about 120-180 days; can_make_monthly_payments = a monthly amount but not in full; can_pay_little = only a very small monthly amount; cannot_pay_basic_living = paying the IRS would leave you unable to cover basic living expenses (financial hardship). | |
| balance_owed_usd | Yes | Total amount owed to the IRS including tax, penalties, and interest (a rough figure is fine). | |
| tax_account_type | No | Coarse, nonidentifying IRS account type. individual_income_tax includes Form 1040 income-tax balances, including a sole proprietor whose balance is on Form 1040. business_non_trust_fund_or_out_of_business covers non-trust-fund business tax or an out-of-business sole proprietor account. business_trust_fund covers in-business payroll or other trust-fund tax. Use unknown when unsure. Defaults to unknown. | |
| all_required_returns_filed | No | Whether every required tax return has actually been FILED (even if the tax was not paid). Filing compliance is generally required before the IRS formalizes a collection alternative, but the exact account requirements control. Defaults to false. | |
| balance_includes_penalties | No | Whether the balance includes failure-to-file or failure-to-pay penalties, so penalty abatement may reduce it. Defaults to true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| relay | Yes | Instruction to the calling assistant: relay figures and dates verbatim (identical on every response). |
| next_step | Yes | A single review link appropriate to this server surface. |
| disclaimer | Yes | General-information disclaimer (identical on every response). |
| source_url | Yes | Official IRS or FinCEN authority to review before relying on the result. |
| server_version | No | Server release that produced this response (matches GET /version). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, ensuring safe, read-only behavior. The description adds value by emphasizing the tool is educational and not a guarantee of IRS approval, which is critical for managing user 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 two sentences, front-loading the purpose and providing a critical caveat. Every word earns its place; no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters (2 required), an output schema, and clear annotations, the description adequately covers the tool's purpose and limitations. The output schema would handle return value details, so the description focuses on usage intent.
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% coverage with detailed parameter descriptions, so the baseline is 3. The tool description does not add additional parameter semantics beyond what the schema already provides, but the schema itself is thorough.
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 screens IRS payment/collection alternatives based on specific inputs (balance, compliance, ability to pay, tax account type). It distinguishes itself from sibling tools (e.g., check_5472_obligation, check_fbar_fatca) which focus on specific tax obligations or forms, whereas this is a general resolution screening tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to screen...' indicating when to use the tool. It also qualifies the output as 'educational fit screen, not a promise'. While it doesn't explicitly state when not to use it or name alternatives, the context from sibling tools implies its role as a broad screening tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_treaty_withholdingCheck US withholding and treaty rates (W-8BEN)ARead-onlyInspect
Use to explain general US withholding rules, documentation, and supported US-Turkey treaty rates for a payment category. Treaty eligibility and source rules depend on the full facts.
| Name | Required | Description | Default |
|---|---|---|---|
| payee_type | No | Whether the payee is an individual or a company/entity. Defaults to individual. Determines the form (W-8BEN vs W-8BEN-E) and the treaty dividend rate. | |
| income_type | Yes | The kind of US-source payment: "dividends" (from US stocks or a US corporation), "interest", "royalties" (software, content, IP licensing), "personal_services" (freelance/consulting work or wages), or "scholarship_fellowship". | |
| payee_country | Yes | Country of TAX RESIDENCE of the person or company RECEIVING the payment. "turkey" returns the US-Turkey treaty rates this server carries; "other_non_us" returns the default statutory rates and how to check your own treaty; "united_states" covers US persons (who use Form W-9, not a treaty claim). |
Output Schema
| Name | Required | Description |
|---|---|---|
| relay | Yes | Instruction to the calling assistant: relay figures and dates verbatim (identical on every response). |
| next_step | Yes | A single review link appropriate to this server surface. |
| disclaimer | Yes | General-information disclaimer (identical on every response). |
| source_url | Yes | Official IRS or FinCEN authority to review before relying on the result. |
| server_version | No | Server release that produced this response (matches GET /version). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true. Description adds value by noting the tool provides general guidance and supported treaty rates, with no side effects. It does not contradict 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 that front-load the purpose and provide essential scope. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description adequately covers purpose, usage, and limitations without needing to explain return values.
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% of parameters with detailed descriptions. The description adds no additional parameter semantics beyond what the schema provides, so 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?
Title and description clearly state the tool checks US withholding and treaty rates for W-8BEN forms, with specific mention of US-Turkey treaty rates. It distinguishes from sibling tools like check_fbar_fatca or check_itin_eligibility, which cover different 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 states 'Use to explain general US withholding rules' and notes that treaty eligibility depends on full facts. While it doesn't explicitly list exclusions or alternatives, the sibling context provides differentiation. It could be more explicit about when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
deadline_calendarUS filing deadlines for foundersARead-onlyInspect
Use to return common federal filing and payment dates for a selected filer or entity type. The user must verify the date for weekends, holidays, extensions, fiscal years, and special facts.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_type | Yes | Your US tax entity. foreign_owned_llc = a SINGLE-MEMBER US LLC owned by a non-US person (files pro-forma 1120 + 5472); a multi-member foreign-owned LLC is a partnership, use multi_member_llc. foreign_owned_c_corp = a US C-corp with foreign owners. nonresident_individual = a person filing Form 1040-NR. | |
| filing_year | No | The tax year whose deadlines you want (the year being reported). Defaults to the prior calendar year. | |
| formed_in_us | No | Whether the entity was formed in the US (relevant to the BOI report, from which most US-formed companies are now exempt). | |
| has_us_source_wages | No | Nonresident individuals only: whether you had US wages subject to withholding. Determines the 1040-NR due date (April 15 if yes, June 15 if no). | |
| has_foreign_bank_over_10k | No | Whether the aggregate of your foreign financial accounts exceeded $10,000 at any point (triggers FBAR). |
Output Schema
| Name | Required | Description |
|---|---|---|
| relay | Yes | Instruction to the calling assistant: relay figures and dates verbatim (identical on every response). |
| next_step | Yes | A single review link appropriate to this server surface. |
| disclaimer | Yes | General-information disclaimer (identical on every response). |
| source_url | Yes | Official IRS or FinCEN authority to review before relying on the result. |
| server_version | No | Server release that produced this response (matches GET /version). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=true and destructiveHint=false, so the description adds the important caveat that the user must verify dates, implying the tool may not account for all variables. This adds 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 two sentences with no wasted words. The first sentence states the purpose, and the second provides a critical usage caveat. It is front-loaded 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 rich schema descriptions, annotations, and sibling tools, the description is complete. It conveys the core functionality and a key limitation (user verification needed). The presence of an output schema further reduces the need for return-value 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 detailed descriptions for each parameter, especially the entity_type enum. The tool description does not add additional parameter semantics beyond the schema, so 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 returns 'common federal filing and payment dates for a selected filer or entity type', which is a specific verb+resource. It distinguishes from sibling tools that check obligations (e.g., check_5472_obligation) rather than provide dates.
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 instructs the user to verify dates for weekends, holidays, extensions, etc., providing clear context on when to use and what caution is needed. It does not mention alternatives, but the sibling list implies distinct purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decode_irs_noticeDecode an IRS noticeARead-onlyInspect
Use when a user provides the code from an IRS notice or letter and wants a general explanation, the usual response window, or the next procedural step. Do not request the notice itself or any taxpayer identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No | Set true for a shorter answer: skips the generic how-to-read guidance and common-error list. | |
| notice_code | Yes | The notice or letter code printed on the IRS mail, e.g. "CP2000", "CP 14", "LT11", "Letter 1058". | |
| amount_shown | No | The dollar amount the notice proposes or bills, if any. Optional; used only for context, never stored. | |
| received_date | No | Date on the notice (YYYY-MM-DD). Used to compute the response deadline. The IRS clock runs from the notice date printed on the letter. |
Output Schema
| Name | Required | Description |
|---|---|---|
| relay | Yes | Instruction to the calling assistant: relay figures and dates verbatim (identical on every response). |
| next_step | Yes | A single review link appropriate to this server surface. |
| disclaimer | Yes | General-information disclaimer (identical on every response). |
| source_url | Yes | Official IRS or FinCEN authority to review before relying on the result. |
| server_version | No | Server release that produced this response (matches GET /version). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe reading behavior is clear. The description adds that the tool does not request taxpayer identifiers or the notice itself, which is useful behavioral context. 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?
Two sentences with zero waste. The first sentence gives the core purpose and when to use, the second adds a critical constraint. Perfectly front-loaded 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 presence of an output schema and 100% parameter coverage, the description sufficiently covers all necessary aspects: purpose, usage context, parameter hints, and constraints. 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?
Schema coverage is 100%, so all four parameters are documented in the input schema. The description adds no further semantic value beyond the schema, meeting the baseline expectation adequately.
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 verb 'decode' and the resource 'IRS notice', specifying that it provides explanations, response windows, or procedural steps. It distinguishes from sibling tools like check_obligations or estimate tools by focusing on decoding notice codes.
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 states when to use: when a user provides an IRS notice code for explanation or next steps. Also includes a clear negative instruction: 'Do not request the notice itself or any taxpayer identifier.' This provides comprehensive guidance on appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_accountable_planEstimate accountable-plan reimbursementsARead-onlyInspect
Use to estimate potentially reimbursable business expenses under an accountable-plan scenario, including the split 2026 business-mileage rates. The result does not establish a plan or determine substantiation.
| Name | Required | Description | Default |
|---|---|---|---|
| business_miles | No | Business miles driven in your personal vehicle. For 2026, also identify whether the miles were before July 1, on or after July 1, or span both periods because the IRS changed the rate midyear. | |
| cell_internet_usd | No | Annual business-use portion of your cell phone and home internet. | |
| marginal_tax_rate_pct | No | Your combined marginal tax rate as a percent (e.g. 24, or 33 to include state). Used to estimate the tax saving. Defaults to 22. | |
| business_mileage_period | No | When the business miles occurred. Defaults to mixed_or_unknown, which returns a reimbursement range rather than inventing a single rate. For miles in both 2026 periods, call the tool once per period and add the results. | |
| home_office_expense_usd | No | Annual business-use portion of your home costs (rent/mortgage interest, utilities, insurance x business-use %). If you only know square footage, use the simplified method: $5/sq ft up to 300 sq ft = $1,500 max. | |
| other_business_expense_usd | No | Other out-of-pocket business expenses you personally paid (supplies, travel, professional dues, etc.). |
Output Schema
| Name | Required | Description |
|---|---|---|
| relay | Yes | Instruction to the calling assistant: relay figures and dates verbatim (identical on every response). |
| next_step | Yes | A single review link appropriate to this server surface. |
| disclaimer | Yes | General-information disclaimer (identical on every response). |
| source_url | Yes | Official IRS or FinCEN authority to review before relying on the result. |
| server_version | No | Server release that produced this response (matches GET /version). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by stating that the result does not establish a plan or determine substantiation, and that for mixed periods it returns a range rather than a single rate. Annotations already declare readOnlyHint=true, so the description reinforces the non-destructive nature with important caveats.
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, immediately front-loaded with purpose. Every sentence adds essential context. No redundant or verbose phrasing.
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 6 parameters, full schema documentation, and an existing output schema, the description sufficiently covers the tool's scope, limitations, and usage notes. It tells the agent what the result does and does not accomplish.
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 tool description does not add new information about parameters beyond what is already in the input schema. The schema itself provides detailed descriptions for each parameter, so the description carries no extra semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'estimate potentially reimbursable business expenses under an accountable-plan scenario' and mentions the specific 'split 2026 business-mileage rates'. This distinguishes it from sibling tools like estimate_augusta_rule or estimate_quarterly_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 says 'Use to estimate...' and explicitly notes that 'The result does not establish a plan or determine substantiation.' It also advises to call the tool once per period for mixed mileage. However, it lacks explicit guidance on when to use alternatives among sibling estimate tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_augusta_ruleScreen the 14-day home-rental ruleARead-onlyInspect
Use to screen the fewer-than-15-days home-rental rule under IRC 280A(g) and calculate conditional amounts. Keep the owner-side income exclusion separate from the business-side requirements for ordinary and necessary use and reasonable rent.
| Name | Required | Description | Default |
|---|---|---|---|
| days_rented | Yes | Total number of days during the year the dwelling is rented to anyone at a fair rental price, including days rented to your business. The IRC 280A(g) income exclusion requires fewer than 15 total rental days and that the dwelling is used as a home. | |
| marginal_tax_rate_pct | No | Your combined marginal tax rate as a percent (e.g. 24 for 24%, or 33 to include state). Used to translate the deduction into a tax saving. Defaults to 22. | |
| fair_daily_rental_rate_usd | Yes | The FAIR-MARKET daily rate to rent your home for a comparable business event (e.g. what a hotel meeting room or event space of similar size would charge). Must be supportable with a written quote or comparable. |
Output Schema
| Name | Required | Description |
|---|---|---|
| relay | Yes | Instruction to the calling assistant: relay figures and dates verbatim (identical on every response). |
| next_step | Yes | A single review link appropriate to this server surface. |
| disclaimer | Yes | General-information disclaimer (identical on every response). |
| source_url | Yes | Official IRS or FinCEN authority to review before relying on the result. |
| server_version | No | Server release that produced this response (matches GET /version). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds operational context (screening vs calculation) but does not disclose any additional behavioral traits like side effects or required permissions.
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 redundant or filler content. Every sentence adds value: one states the primary function (screen/calculate), the other provides a usage caution.
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 and good annotation coverage, the description is complete enough for an agent to understand the purpose and key concept. It could be slightly improved by clarifying what 'conditional amounts' refers to, but it is 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% with each parameter already described (e.g., days_rented explains the rule context). The tool description does not add new parameter-level meaning beyond what the schema provides, so 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 explicitly states the tool screens the fewer-than-15-days home-rental rule under IRC 280A(g) and calculates conditional amounts, with a clear verb ('screen' and 'calculate') and resource (specific tax rule). It distinguishes from siblings like 'estimate_rental_income' by referencing the 14-day rule and 'owner-side income exclusion'.
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 the agent when to use ('to screen the fewer-than-15-days home-rental rule') and provides a usage hint ('Keep the owner-side income exclusion separate from the business-side requirements'). However, it does not explicitly state when not to use or compare to siblings like 'estimate_rental_income'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_irs_penaltyEstimate IRS penalties and interestARead-onlyInspect
Use to estimate selected federal failure-to-file, failure-to-pay, and underpayment amounts from nonidentifying figures. The result is an estimate and does not replace an IRS account transcript.
| Name | Required | Description | Default |
|---|---|---|---|
| months_late | Yes | Whole months past the deadline. The failure-to-file penalty counts any part of a month as a full month. | |
| return_filed | No | Whether you actually FILED the return (even if you did not pay). If false, the larger 5%/month failure-to-file penalty applies. Defaults to false (not filed). | |
| balance_owed_usd | Yes | The unpaid tax balance (the tax itself, before penalties and interest). |
Output Schema
| Name | Required | Description |
|---|---|---|
| relay | Yes | Instruction to the calling assistant: relay figures and dates verbatim (identical on every response). |
| next_step | Yes | A single review link appropriate to this server surface. |
| disclaimer | Yes | General-information disclaimer (identical on every response). |
| source_url | Yes | Official IRS or FinCEN authority to review before relying on the result. |
| server_version | No | Server release that produced this response (matches GET /version). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read-only behavior. The description adds no additional behavioral traits beyond confirming it's an estimate. While consistent, it does not disclose extra details like data usage or limitations.
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 with no wasted words: the first states the core action, and the second provides a crucial caveat. It is front-loaded 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 has only 3 parameters, 100% schema coverage, and an output schema, the description is sufficient. It covers the purpose and limitation without needing to detail return values. Slightly more context about when to use this estimate versus an actual transcript could 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?
Input schema coverage is 100%, and the description does not add parameter-specific meaning beyond what the schema already provides. The schema describes 'months_late' with rounding behavior and 'return_filed' defaults, so the description adds no additional value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool estimates 'federal failure-to-file, failure-to-pay, and underpayment amounts from nonidentifying figures,' clearly specifying the verb (estimate) and resources (penalties and interest). It distinguishes from siblings like 'check_*' or 'estimate_quarterly_taxes' by focusing on penalty calculation.
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 stating the result is an estimate and does not replace an IRS transcript, setting expectations. However, it does not explicitly list when to use this tool versus other estimate tools (e.g., 'estimate_quarterly_taxes') or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_quarterly_taxesEstimate quarterly taxesARead-onlyInspect
Use to estimate federal quarterly tax payments from nonidentifying income, entity, withholding, and prior-year tax figures. Return the assumptions, safe-harbor context, and due dates.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | US state. Only California installment timing is modeled specifically; when omitted, no state is assumed and only federal figures are computed. | |
| entity | Yes | How the income is taxed. Sole proprietor / SMLLC / partnership pay self-employment tax; S-corp shareholders take wages (withheld) plus distributions. | |
| prior_year_agi_usd | No | Last year's adjusted gross income (AGI). If over $150,000 ($75,000 MFS), the prior-year safe harbor rises from 100% to 110%. | |
| ytd_net_income_usd | Yes | Your net self-employment / business income so far THIS year (year to date), before tax. | |
| ytd_withholding_usd | No | Federal tax already withheld this year (e.g. from a W-2 or S-corp salary). Counts toward the safe harbor. | |
| prior_year_total_tax_usd | No | Total federal tax on last year's return. Enables the prior-year safe harbor (often the easiest to hit). |
Output Schema
| Name | Required | Description |
|---|---|---|
| relay | Yes | Instruction to the calling assistant: relay figures and dates verbatim (identical on every response). |
| next_step | Yes | A single review link appropriate to this server surface. |
| disclaimer | Yes | General-information disclaimer (identical on every response). |
| source_url | Yes | Official IRS or FinCEN authority to review before relying on the result. |
| server_version | No | Server release that produced this response (matches GET /version). |
Tool Definition Quality
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 addition of output content (assumptions, safe-harbor context, due dates) provides some behavioral context but no critical safety traits beyond what annotations cover.
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 that are front-loaded with the core action and immediately useful. No filler 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?
For a tool with 6 parameters and an output schema, the description covers the key output elements. It does not need to detail return values since output schema exists. Minor gap: no mention of read-only nature, but annotations cover that.
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 input schema already describes all parameters thoroughly. The description adds no additional meaning beyond the schema; it only summarizes the purpose.
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 estimates federal quarterly tax payments from specified inputs. It uses a specific verb ('estimate') and resource ('quarterly tax payments'), and distinguishes from sibling tools like estimate_irs_penalty and 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 only says 'Use to estimate...' but provides no guidance on when to use this tool versus alternatives, nor when not to use it. No explicit context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_rental_incomeEstimate rental property taxesARead-onlyInspect
Use to estimate a basic rental-income result from nonidentifying figures and identify the modeled depreciation, passive-loss, and personal-use limitations.
| Name | Required | Description | Default |
|---|---|---|---|
| rental_days | No | Days the property was rented at fair value (short-term only). | |
| rental_type | No | long_term (standard residential lease) or short_term (Airbnb/VRBO-style). Defaults to long_term. | |
| land_percent | No | Percent of the purchase price attributable to non-depreciable land (default 20). The building is depreciated over 27.5 years. | |
| filing_status | No | Federal filing status. Defaults to single. | |
| other_income_usd | No | Your other taxable income (e.g. wages, business) for the year. Sets the marginal rate applied to net rental income, and gates the passive-loss allowance. | |
| personal_use_days | No | Days YOU used the property personally (short-term only). Triggers the 14-day tax-free rule when a stay is rented 14 days or fewer and used more personally. | |
| operating_expenses_usd | No | Deductible operating expenses: mortgage interest, property tax, insurance, HOA, repairs, management, utilities, supplies. Excludes depreciation (computed for you). | |
| annual_rental_income_usd | Yes | Gross rent received this year, before expenses. | |
| real_estate_professional | No | Whether you materially participate as a real-estate professional under IRC 469(c)(7). If true, rental losses are not passive-limited. | |
| property_purchase_price_usd | No | What you paid for the property (building + land). Used to compute straight-line depreciation. |
Output Schema
| Name | Required | Description |
|---|---|---|
| relay | Yes | Instruction to the calling assistant: relay figures and dates verbatim (identical on every response). |
| next_step | Yes | A single review link appropriate to this server surface. |
| disclaimer | Yes | General-information disclaimer (identical on every response). |
| source_url | Yes | Official IRS or FinCEN authority to review before relying on the result. |
| server_version | No | Server release that produced this response (matches GET /version). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the annotations by specifying that the tool 'models depreciation, passive-loss, and personal-use limitations', giving insight into the computation. Annotations already indicate read-only (readOnlyHint=true) and non-destructive (destructiveHint=false), and the description is consistent. However, it does not detail the return format or any applicable rate limits.
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 sentence that efficiently conveys the tool's purpose without redundancy. It is front-loaded with the action verb 'Use to estimate'. However, it could be slightly restructured for readability, but overall it is 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's complexity (10 parameters, output schema exists), the description is minimal but adequate. It states the high-level purpose and what limitations are identified. With an output schema, the return value details are covered, so the description does not need to elaborate further. However, it could provide more context on how the estimation works or assumptions made.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 10 parameters. The description mentions 'nonidentifying figures' but does not elaborate on any individual parameters beyond what the schema provides. Thus, it adds little extra meaning, meeting the baseline score of 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 estimates a 'basic rental-income result' and identifies key tax limitations (depreciation, passive-loss, personal-use). The verb 'estimate' combined with the resource 'rental-income result' makes the purpose specific. It is distinct from sibling tools like 'estimate_augusta_rule' or 'estimate_quarterly_taxes' which focus on different tax scenarios.
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 no guidance on when to use this tool versus alternatives, such as 'estimate_augusta_rule' or 'estimate_irs_penalty'. It simply says 'Use to estimate...' without explaining contexts where another tool would be more appropriate or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_tax_documentExplain a tax documentARead-onlyInspect
Use when a user names a US tax form or information document and wants to understand its purpose, common fields, or usual return treatment. Do not request or accept the document itself.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No | Set true for a shorter answer: skips the box-by-box guide and the pre-filing checklist. | |
| document | Yes | The tax form or document name as printed on it, e.g. "W-2", "1099-K", "1099-NEC", "Schedule K-1 (Form 1065)", "1042-S", "1098-T", "SSA-1099", "1095-A", "W-9". |
Output Schema
| Name | Required | Description |
|---|---|---|
| relay | Yes | Instruction to the calling assistant: relay figures and dates verbatim (identical on every response). |
| next_step | Yes | A single review link appropriate to this server surface. |
| disclaimer | Yes | General-information disclaimer (identical on every response). |
| source_url | Yes | Official IRS or FinCEN authority to review before relying on the result. |
| server_version | No | Server release that produced this response (matches GET /version). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds critical behavioral rule: 'Do not request or accept the document itself.' This clarifies the tool only works on form names, not the documents themselves. 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?
Two sentences, no filler. First sentence front-loads purpose and usage condition. Second sentence adds a key behavioral constraint. 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?
For a straightforward explainer tool with full schema coverage and an output schema (implied), the description provides all necessary context: what it explains, when to use, and what not to do. 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?
Input schema has 100% description coverage for both parameters. Description does not add new parameter-specific meaning beyond what the schema provides. Meets 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?
Description explicitly states the action ('explain') and resource ('US tax form or information document') and its purpose ('understand its purpose, common fields, or usual return treatment'). Sibling tools have distinct purposes (e.g., check obligations, decode notices), so no confusion.
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 clearly indicates when to use ('when a user names a US tax form ... and wants to understand'). Does not provide explicit when-not-to-use or alternatives, but sibling tools are sufficiently different that context implies correct usage.
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.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.