Arc & Ledger Tax Tools
Server Details
Enrolled Agent tax tools: IRS notices, FBAR, LLC vs S-Corp, quarterly estimates & more.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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 16 of 16 tools scored.
Each tool targets a specific tax or business scenario with clear boundaries. There is no overlap; tools like 'estimate_accountable_plan' and 'estimate_augusta_rule' address different deduction mechanisms, and all others cover distinct topics (e.g., ITIN eligibility, IRS notices, sales tax nexus). Agents can easily select the correct tool.
Most tools follow a verb_noun pattern with underscores (e.g., 'book_consultation', 'check_fbar_fatca', 'estimate_quarterly_taxes'). Minor inconsistency: 'deadline_calendar' is a noun_noun phrase, and 'decode_irs_notice' uses a different verb. Overall, the pattern is predictable and readable.
16 tools cover a comprehensive set of tax advisory needs without being overwhelming. Each tool adds value for specific common queries (e.g., ITIN, FBAR, IRS resolution, entity comparisons, various estimates). The count is well-scoped for the domain.
The tool surface covers a wide range of tax situations faced by small business owners and individuals, including international reporting, IRS resolution, entity formation, and deduction optimization. Minor gaps: no tool for direct tax return filing or state-specific income tax estimates beyond nexus, but these are likely handled through consultations.
Available Tools
16 toolsbook_consultationBook a consultationARead-onlyInspect
Use this when a user wants to talk to, hire, or get a consultation with Arc & Ledger. Returns the correct first-party booking link, what happens next, the office identity (Enrolled Agent, address, languages EN/TR/ES), and what to expect.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Which consultation to book. Cross-border or multi-year situations suit the Specialist; a single IRS letter suits the notice review. | |
| topic | No | A short subject line for the meeting (optional). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true (consistent, as the tool returns a link, not modifying state) and openWorldHint=true. The description adds context: it returns a booking link, next steps, office identity, and what to expect. No destructive behavior is mentioned, which aligns.
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 redundancy. The first sentence states the trigger, the second lists what is returned. Every word is necessary and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the purpose, usage trigger, and return value (including specifics like office identity, languages). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by explaining when to choose each consultation type (e.g., 'Cross-border or multi-year situations suit the Specialist'). This goes beyond the enum labels.
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 action ('book a consultation'), the target entity ('Arc & Ledger'), and what the tool returns (booking link, next steps, office identity). This distinguishes it from sibling tools which handle checks, estimates, and notices.
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 'Use this when a user wants to talk to, hire, or get a consultation' – a clear trigger condition. However, it does not provide exclusions or alternatives, though sibling tools are different enough that confusion is unlikely.
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 this when a user has foreign bank accounts, assets, or unfiled foreign-account reports and needs to know their US reporting obligations (FBAR / FinCEN 114 and Form 8938 / FATCA), thresholds, penalty exposure, and catch-up options.
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds context about what the tool provides (thresholds, penalties, catch-up options) beyond the annotations, without 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?
The description is a single, front-loaded sentence that efficiently conveys the use case. It could be slightly more concise but avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters, no output schema, and sibling tools, the description effectively covers the purpose and hints at return values (obligations, thresholds, penalties). It could mention account_count usage but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The tool description adds no additional parameter-level information; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'check' and the resources 'FBAR and FATCA obligations'. It differentiates from sibling tools like check_itin_eligibility or check_resolution_options by specifying foreign account reporting context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: when a user has foreign accounts, assets, or unfiled reports. It does not mention when not to use or provide alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_itin_eligibilityCheck ITIN eligibilityARead-onlyInspect
Use this when someone (typically a non-US person, a foreign business owner, or the spouse/dependent of a US filer) asks whether they need or qualify for an ITIN, or what documents an ITIN application requires. Returns eligibility, the W-7 reason category, whether a tax return must be attached, and the documents needed. Notes that an Enrolled Agent prepares the Form W-7 and represents the applicant, and how documents are submitted.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | Why you need a US taxpayer ID. file_us_tax_return = you must file a US return; owner_of_us_llc = foreign owner of a US LLC/corp needing an ID for filings; claim_treaty_benefit = reduce withholding under a tax treaty; spouse_or_dependent = of a US filer; third_party_withholding = a payer/bank needs your ID (W-8BEN); open_us_bank_or_other = other 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds return-value specifics (eligibility, reason category, document needs) and process notes (Enrolled Agent role), going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the purpose and list key returns. No extraneous words, earning 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 read-only tool with no output schema, it covers what the agent needs to know: when to use, what it returns, and process context. Minor omission of whether results are real-time, but still 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 detailed parameter descriptions, so the description adds little beyond that. Baseline of 3 is appropriate as it does not repeat schema but doesn't add new 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 explicitly states it checks ITIN eligibility and returns relevant details, with a clear verb and resource. It distinguishes from sibling tools like check_fbar_fatca by focusing on ITIN.
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 provides explicit when-to-use guidance ('when someone asks whether they need or qualify for an ITIN'). No explicit when-not-to-use or alternatives, but siblings cover other tax topics clearly.
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 this when someone owes the IRS back taxes and asks how to settle, get on a payment plan, lower what they owe, or stop collection. Screens which IRS paths may fit - short-term payment plan, streamlined or financial-disclosure installment agreement, Offer in Compromise (a fit-check only, never a promise of acceptance), Currently Not Collectible hardship status, and penalty abatement - and lists the forms needed (9465, 433-F/A, 656, 843, 8821, 2848) plus collection-statute context. Never guarantees an IRS outcome.
| Name | Required | Description | Default |
|---|---|---|---|
| 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). | |
| all_required_returns_filed | No | Whether every required tax return has actually been FILED (even if the tax was not paid). The IRS will not approve any installment agreement, Offer in Compromise, or hardship status until you are filing-compliant. 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description details that it screens paths, lists forms, and never guarantees an outcome. This provides valuable behavioral context, though it doesn't specify the exact output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that packs the usage condition, list of paths, and caveats efficiently. It is front-loaded with the usage trigger. Could be improved with structure (e.g., bullet points) but is reasonably 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?
For a tool with 4 parameters and no output schema, the description covers the purpose and behavioral intent well but does not specify what the tool returns (e.g., a list of options with forms). This leaves some ambiguity for the agent about the output structure.
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 has 100% coverage with descriptive parameter explanations. The overall description adds context about which IRS paths are considered and forms needed, but does not significantly enhance individual parameter meaning 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 identifies the tool's function: screening IRS resolution options for back taxes. It lists specific paths (e.g., installment agreements, Offer in Compromise) and distinguishes it from sibling tools like check_fbar_fatca or check_itin_eligibility, which address different tax topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The first sentence explicitly defines the trigger condition: when someone owes IRS back taxes and asks about settlement or collection. While it doesn't list exclusions or alternatives, the scope is clear and well-scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_sales_tax_nexusCheck sales-tax nexusARead-onlyInspect
Use this when an online seller or e-commerce/Amazon business asks whether they must collect sales tax in a state (economic nexus). Given annual sales, transaction count, and states, flags where economic nexus is likely met and explains the physical-nexus (FBA inventory) trap.
| Name | Required | Description | Default |
|---|---|---|---|
| states | No | US states to check, as 2-letter codes (e.g. ["CA","TX","NY"]). If omitted, the tool explains the general rule. | |
| annual_sales_usd | Yes | Your total sales into the state(s) in the current or prior calendar year. | |
| transaction_count | No | Approximate number of separate sales transactions into the state(s). Some states count transactions as well as dollars. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals no side effects. The description adds that the tool flags nexus and explains a trap, which is behavioral detail. Without an output schema, the description adequately sets expectations for what the tool returns. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The description is front-loaded with the use case and immediately explains the key inputs and outputs. 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?
The tool deals with nuanced tax rules, and the description covers the main return (nexus flags and trap explanation). It could mention that thresholds vary by state, but for a lookup tool, that's acceptable. No output schema exists, so the description does its job.
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 clear descriptions for each parameter. The tool description provides a holistic usage context but does not add new meaning 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 the tool's purpose: checking sales tax nexus for online sellers. It specifies the resource (economic nexus), the conditions (annual sales, transaction count, states), and the output (flags and explanation of physical-nexus trap). This distinguishes it from all sibling tools, none of which relate to sales tax nexus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when an online seller or e-commerce/Amazon business asks whether they must collect sales tax in a state' – clear context. It also explains the physical-nexus trap as a warning. However, it does not explicitly state when not to use it or list alternative tools, though the sibling context makes that less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_formation_statesCompare US formation statesARead-onlyInspect
Use this when someone (often a non-US founder) asks which US state to form their LLC or company in - Wyoming, New Mexico, Delaware, or California. Compares government fees, annual cost, franchise tax, privacy, and approval time, and recommends a state based on their situation.
| Name | Required | Description | Default |
|---|---|---|---|
| priority | No | What matters most: lowest_cost, most_privacy, or investor_ready. Defaults to lowest_cost. | |
| operates_in_california | No | Whether you (or the business) physically operate in, or are a resident of, California. If true, California registration is generally required regardless of where you form. | |
| raising_venture_capital | No | Whether you plan to raise venture capital or convert to a C-corp. If true, Delaware is usually preferred by investors. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and description matches as a read operation. It discloses behavioral traits like comparing fees, privacy, and recommending based on priorities, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence paragraph, no wasted words. Front-loaded with use case and context, then describes functionality. Highly 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?
Lacks output schema and description does not specify return format (e.g., text, table). Mentions 'recommends a state' but not comparison details. Adequate for a simple recommendation tool, but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions. The description does not add new param info beyond schema, so meets baseline 3. The description frames parameters in context but doesn't provide additional syntax or examples.
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 compares US formation states and recommends one based on situation. It uses specific verbs like 'compares' and 'recommends', and distinguishes from sibling tool 'compare_llc_scorp' which compares LLC vs S-Corp.
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 someone asks which US state to form their LLC or company in', targeting non-US founders. Could be improved by stating when not to use (e.g., if already formed), but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_llc_scorpCompare LLC vs S-CorpARead-onlyInspect
Use this when a self-employed user or single-member LLC owner asks whether an S-Corp election would save them money. Shows a side-by-side of self-employment tax vs salary-plus-distribution, payroll and compliance costs, California franchise taxes, and the break-even zone.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | US state, 2-letter or name. Defaults to CA. Only California franchise taxes are modeled (the SMLLC gross-receipts fee is excluded; see caveats). | |
| currently_has_llc | No | Whether the business already operates as an LLC today. Defaults to true. A plain sole proprietorship (no LLC) does not owe the California $800 franchise tax. | |
| expected_net_profit_usd | Yes | Expected annual net profit (revenue minus business expenses), before any owner salary. | |
| owner_salary_estimate_usd | No | A reasonable W-2 salary you would pay yourself as an S-corp owner. If omitted, a neutral 50% split is used to illustrate the mechanic. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true (no mutation) and openWorldHint=false (deterministic). Description adds that it only models California franchise taxes and excludes certain fees, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. The first sentence front-loads the use case, the second lists outputs. Perfectly 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 no output schema, the description adequately hints at the return format (side-by-side with costs and break-even). It covers the main inputs and limitations (California-only). Missing details on output structure, but sufficient for the comparison context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 4 parameters (100% coverage), with details like 'defaults to CA' and '50% split if omitted'. The description does not add new parameter-level meaning, staying at 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's purpose: comparing LLC vs S-Corp for self-employed individuals, with a specific verb 'shows' and resource 'side-by-side comparison'. It distinguishes itself from siblings like 'compare_formation_states' by focusing on tax election savings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when a self-employed user or single-member LLC owner asks whether an S-Corp election would save them money.' Provides a clear trigger scenario. Could improve by mentioning when not to use or alternatives, but current is strong.
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 this when a US business owner or nonresident (especially a foreign founder of a US LLC or C-corp) asks what US forms they must file and when. Returns each required federal form, its due date and extension, and the penalty for missing it, including Form 5472, FBAR, and the BOI report. Especially useful for non-US founders of US companies.
| 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description confirms it returns information without side effects. Adds detail on the types of forms returned (Form 5472, FBAR, BOI report).
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 efficient sentences front-loading purpose and usage, with 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?
Describes the output (forms, due dates, extensions, penalties) sufficiently given no output schema. Mentions specific forms and targets non-US founders, but could briefly note the role of optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all parameters. The description does not add new meaning beyond the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns federal forms, due dates, extensions, and penalties. Distinguishes from siblings like check_fbar_fatca and estimate_irs_penalty by focusing on deadlines for all required forms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: when a US business owner or nonresident asks about forms and deadlines. Provides context but does not explicitly exclude sibling tools.
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 this when a user mentions receiving an IRS or state tax letter or notice and wants to know what it means, the deadline, or what to do. Give it the notice code (e.g. CP2000, CP14, LT11) and optionally the notice date and amount shown.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is safe. The description adds that the tool computes a response deadline from the received_date, but does not mention any other behavioral traits. 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. The first sentence gives usage context, the second specifies the required input. 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?
For a simple lookup tool, the description is fairly complete. It mentions IRS and state notices, the required notice code, and optional parameters. It could specify behavior for unknown codes, but given the tool's nature, 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 described. The description reinforces usage patterns but does not add new meaning beyond the schema. 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's purpose: decode IRS or state tax notices when a user asks about receiving one. It specifies the verb 'decode' and the resource 'IRS notice', and distinguishes from siblings that handle other tax tasks like booking consultations or checking eligibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when a user mentions receiving an IRS or state tax letter or notice...' providing clear usage context. While it does not name alternative sibling tools, the context is sufficiently specific to avoid confusion with other tools.
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 this when an S-corp or C-corp owner asks how to deduct home office, mileage, cell phone, or other out-of-pocket business expenses, or asks about an "accountable plan." Totals the tax-free reimbursement, estimates the tax saving, and explains the three requirements (business connection, substantiation, return of excess) and why owner-employees get no deduction without one.
| Name | Required | Description | Default |
|---|---|---|---|
| business_miles | No | Business miles you drive per year in your personal vehicle. Reimbursed at the IRS standard mileage rate. | |
| 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. | |
| 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.). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, but the description adds significant context: it totals reimbursement, estimates tax saving, and explains the three requirements. It fully discloses the tool's behavior 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?
The description is three sentences, front-loaded with the use case. It is informative but slightly verbose; could be trimmed without losing meaning. However, it earns its sentences by covering purpose, usage, and behavioral aspects.
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 is an estimator with no required parameters and no output schema, the description is remarkably complete. It specifies the trigger (owner asking about deductions), the calculation outputs (reimbursement total, tax saving), and the underlying rule explanation. No gaps remain for an agent to understand when to invoke it.
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 parameters. The description adds value by mentioning the home office simplified method ($5/sq ft) and contextualizing the parameters within the accountable plan framework, though it does not add detailed syntax for every 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 estimates tax-free reimbursement for S-corp or C-corp owners' out-of-pocket business expenses, covering specific items like home office, mileage, cell phone. It distinguishes from sibling tools by naming the specific scenario and contrasting with other estimate tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly starts with 'Use this when...' and gives concrete scenarios. It does not provide explicit when-not-to-use guidance, but the context and sibling tools imply it's for accountable plan estimation, not for other reimbursement types like Augusta rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_augusta_ruleEstimate the Augusta rule (home rental to your business)ARead-onlyInspect
Use this when a business owner asks about the "Augusta rule," renting their home to their own S-corp or C-corp, or the 14-day tax-free home rental (IRC 280A(g)). Given a fair daily rate and number of days, estimates the business deduction and tax-free income, warns about the 14-day limit, and lists the documentation needed to make it defensible.
| Name | Required | Description | Default |
|---|---|---|---|
| days_rented | Yes | Number of days per year you rent your home to your business. The tax-free treatment ONLY applies at 14 days or fewer. | |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool estimates, warns about the 14-day limit, and lists documentation, which aligns with the readOnlyHint=true annotation. It adds behavioral context beyond annotations (documentation listing, warning), but the read-only nature is already declared in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the use case. Each sentence serves a purpose: when to use, what it does, and its constraints. No unnecessary 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 covers all key aspects: specific rule, inputs (fair daily rate, days), outputs (deduction estimate, tax-free income, warning), and documentation listing. Since there is no output schema, the description adequately explains 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 coverage is 100% with good descriptions for each parameter. The description provides high-level context (fair-market rate, IRS rule) but does not add significant nuance beyond schema. For example, the schema already explains fair_daily_rental_rate_usd as a fair-market rate needing a written quote.
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 the Augusta rule for home rental to business, explicitly naming the 14-day tax-free rule (IRC 280A(g)). It distinguishes from siblings like estimate_rental_income by focusing on the specific S-corp/C-corp owner scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when a business owner asks about the Augusta rule...' which provides clear when-to-use guidance. It does not explicitly mention when not to use it, but the specificity implies it should not be used for general rental income estimation, and alternative sibling tools like estimate_rental_income exist.
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 this when someone owes the IRS and asks how much the penalties and interest will be, or what late filing/paying costs. Estimates the failure-to-file (5%/mo) and failure-to-pay (0.5%/mo) penalties and interest on a balance, and explains first-time penalty abatement.
| 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the specific penalties estimated (failure-to-file at 5%/mo, failure-to-pay at 0.5%/mo) and that it explains first-time penalty abatement. This adds useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with usage guidance, no redundant information. Every sentence serves a clear purpose.
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, usage, and key outputs. It could mention that estimates are approximate or note limitations on interest calculation, but given the tool's simplicity and lack of output schema, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds value by stating the penalty rates (5%/mo, 0.5%/mo) which are not in the schema, enhancing understanding of the tool's output.
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 'estimates' and identifies the resource 'IRS penalties and interest'. It clearly distinguishes from sibling tools like estimate_quarterly_taxes and estimate_reasonable_comp by focusing on penalties for late payment/filing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'when someone owes the IRS and asks how much the penalties and interest will be'. It provides clear context but does not explicitly exclude alternative tools or mention 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.
estimate_quarterly_taxesEstimate quarterly taxesARead-onlyInspect
Use this when a freelancer or business owner asks how much estimated tax to pay or whether they are underpaid for the year. Computes federal self-employment and income tax on annualized income, the safe-harbor target, per-quarter amounts and due dates, plus California's 30/40/0/30 installment timing.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | US state. Defaults to CA. Only California installment timing is modeled specifically. | |
| 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description aligns by stating 'computes.' The description adds value by detailing what is computed (safe harbor, per-quarter amounts, CA timing) beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences, front-loaded with purpose, and contains no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and no output schema, the description adequately covers key outputs and usage scenarios. It could be more explicit about safe harbor thresholds, but overall is complete enough for an agent to decide.
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 adds context linking parameters (e.g., prior_year_agi_usd to safe harbor) but doesn't introduce new parameter details 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 specifies the tool's purpose: estimating quarterly taxes for freelancers/business owners, listing computations like self-employment tax, safe harbor, per-quarter amounts, and CA timing. This distinguishes it from sibling tools such as estimate_irs_penalty.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Use this when a freelancer or business owner asks how much estimated tax to pay or whether they are underpaid'). While it doesn't list when not to use or compare to siblings, the guidance is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_reasonable_compEstimate S-corp reasonable compensationARead-onlyInspect
Use this when an S-corp owner asks how much salary they should pay themselves ("reasonable compensation," "am I paying myself right?"). Given net profit and what drives it, returns a starting salary RANGE, the distribution left over, the employment tax that classification avoids, and the facts-and-circumstances test the IRS actually applies. Emphasizes that a defensible figure needs a comp study.
| Name | Required | Description | Default |
|---|---|---|---|
| profit_driver | No | What drives the profit: "primarily_owner_services" (consulting/agency/solo professional), "mixed" (your work plus staff/systems), or "capital_or_product" (product/capital/team, not your labor). Defaults to primarily_owner_services. | |
| business_net_profit_usd | Yes | Annual net profit of the S-corp BEFORE any owner salary (revenue minus business expenses). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, confirming no side effects. The description adds behavioral context: returns a salary range, distribution, tax savings, and IRS test. 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?
Three sentences, no wasted words. Front-loaded with usage scenario and outcome. Each 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?
Despite no output schema, the description explains what the tool returns (salary range, distribution, tax avoidance, IRS test). For a relatively complex estimation tool, this provides adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning: profit_driver enum options are explained, and business_net_profit_usd is defined as annual net profit before owner salary. This adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool estimates reasonable compensation for S-corp owners, providing a salary range, distribution leftover, tax savings, and IRS test. It clearly distinguishes from siblings by focusing on a specific S-corp owner need.
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 this when an S-corp owner asks how much salary they should pay themselves" and provides clear context. It does not explicitly state when not to use, but the phrasing implies the scenario.
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 this when someone asks how much tax they owe on rental income (Airbnb/short-term or long-term), or whether a rental loss is deductible. Computes net rental income after operating expenses and straight-line depreciation, the passive-loss allowance and carryforward, the short-term 14-day rule, and the marginal federal tax effect.
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns by stating 'computes'. It adds behavioral context by detailing what is computed (depreciation, passive loss, marginal effect), but does not disclose limitations or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with usage guidance, and every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 params, no output schema), the description explains key tax rules and inputs. However, it lacks description of output format or values returned, which would aid agent interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds value beyond schema by explaining parameter contexts (e.g., personal_use_days triggers 14-day rule, operating_expenses_usd excludes depreciation). It clarifies the role of key inputs.
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 rental income tax, net rental income, passive-loss allowance, 14-day rule, and marginal tax effect. It uses specific verbs like 'computes' and 'use this when someone asks', and distinguishes from sibling tools by focusing on rental income estimation.
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 (asks about rental income tax, deduction of rental loss), but does not provide when-not-to-use or compare directly with sibling tools, though context implies uniqueness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fee_quoteGet a fixed-fee quoteARead-onlyInspect
Use this when a user asks what Arc & Ledger charges, or wants a price estimate for tax preparation, bookkeeping, business formation, or IRS help. Returns a published price range and line items, never a single committed number, plus what is included and the next step by complexity.
| Name | Required | Description | Default |
|---|---|---|---|
| details | No | ||
| service | Yes | The kind of work you want priced. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, indicating a safe read operation. The description adds behavioral constraints: it returns a price range and line items, never a single committed number, and includes what is included and the next step. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key usage instruction ('Use this when...'). Every word adds value, with no redundancy. It achieves maximum information density without sacrificing clarity.
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 8 sub-properties in the details object and no output schema, the description explains the return format (range, line items, included, next step) but does not guide how to populate the details object or handle complex cases. It is mostly complete but could be improved with more parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (though the schema shows descriptions for all properties). The description does not add extra meaning beyond what the schema provides for parameters like details or service. Baseline for this coverage level is 3, and the description neither improves nor detracts from parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Use this when a user asks what Arc & Ledger charges, or wants a price estimate for tax preparation, bookkeeping, business formation, or IRS help.' It specifies the verb (get a quote), resource (fees/price estimate), and scope (list of services). It distinguishes from siblings by noting it returns a fixed-fee range, not a committed number.
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: 'when a user asks what Arc & Ledger charges, or wants a price estimate.' It implicitly guides against using it for committed quotes by stating 'never a single committed number.' However, it lacks explicit mention of alternatives among the many sibling tools (e.g., estimate_irs_penalty), though the context signals provide sibling names.
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!