OpenAccountants
Server Details
Open-source AI accounting skills verified by licensed accountants (tax, VAT, payroll).
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- openaccountants/openaccountants
- GitHub Stars
- 173
- Server Listing
- OpenAccountants
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.5/5 across 13 of 13 tools scored.
Each tool has a clearly distinct purpose. For example, 'compare_jurisdictions' and 'plan_cross_border' are explicitly contrasted in their descriptions, and 'start' vs 'start_help' separate scoping from entry. No overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., 'get_rates', 'list_jurisdictions', 'plan_cross_border'). No mixing of conventions or abbreviations.
13 tools cover the server's domain—tax rates, skill management, jurisdiction comparison, cross-border planning, feedback, and accountant review—without being overwhelming or insufficient.
The tool surface thoroughly covers the tax advisory workflow: scoping (start/help), retrieving rates and skills, searching, comparing jurisdictions, cross-border planning, review requests, and feedback. No obvious gaps.
Available Tools
13 toolscompare_jurisdictionsCompare tax across jurisdictionsARead-onlyIdempotentInspect
Quick SIDE-BY-SIDE loader. Loads the income-tax skills for 2–5 jurisdictions as independent blocks so the agent can produce a static comparison (effective rates at a given income level, headline differences, entity-choice implications). It does NOT sequence events or bridge treaties. Use for 'should I incorporate in X or Y?', 'compare tax in MT vs IE', or any standalone side-by-side. NOTE: if the person's facts actually INTERACT across borders (a US person abroad, a residence change, a foreign trust/company, an expatriation), use plan_cross_border instead — that tool returns a sequenced plan and the treaty bridge this one deliberately leaves out. The two are siblings: this one for static compares, plan_cross_border for live cross-border planning.
| Name | Required | Description | Default |
|---|---|---|---|
| income | No | Optional: income figure with currency, e.g. 'EUR 80000' or 'USD 250000'. | |
| entity_type | No | Optional taxpayer/entity type for the comparison context. One of the listed values. | |
| jurisdictions | Yes | Array of 2-5 ISO codes (e.g. ['MT', 'IE'] or ['US-CA', 'US-TX', 'US-FL']). |
Output Schema
| Name | Required | Description |
|---|---|---|
| income | No | |
| entity_type | No | |
| jurisdictions | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false. The description adds that the tool does NOT sequence events or bridge treaties, which is valuable 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 moderately long but well-structured with clear sections and every sentence adds value, though slightly verbose for a simple tool.
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 3 parameters with full schema coverage, output schema presence, rich annotations, and sibling tools, the description covers purpose, usage, limitations, and alternatives comprehensively.
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 parameter descriptions. The description echoes schema constraints (2–5 jurisdictions, income with currency) but adds no deeper meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads income-tax skills for 2–5 jurisdictions as independent blocks for static comparison, distinguishing it from the sibling tool plan_cross_border that handles cross-border interactions.
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 provides when-to-use examples ('should I incorporate in X or Y?') and when-not-to-use conditions (facts interact across borders), naming the alternative tool plan_cross_border.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ratesGet current-year indexed tax ratesARead-onlyIdempotentInspect
Returns the machine-readable annual rates for a given jurisdiction + tax year. Covers federal brackets, Social Security wage base, retirement plan limits (401(k), IRA, HSA), FEIE cap, gift/estate exemptions, 1099-K thresholds, mileage rates, supplemental wage rates, capital gains brackets, CTC. Currently US federal for tax years 2025 and 2026. Use this when the user asks specific dollar amounts that change yearly (e.g. '2025 401(k) limit', 'this year's Social Security wage base').
| Name | Required | Description | Default |
|---|---|---|---|
| tax_year | Yes | Tax year (e.g. 2025, 2026). | |
| jurisdiction | Yes | Jurisdiction code. Currently only 'US' (US federal) is supported. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rates | No | |
| tax_year | No | |
| source_url | No | |
| next_action | No | |
| jurisdiction | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds context about supported jurisdictions, years, and specific rate categories, enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, contents, usage guidance. No wasted words, front-loaded with key action. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema and rich annotations, the description covers intended use, supported values, and examples. Could mention error handling or rate format, but overall sufficient.
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 3. The description adds semantic value by specifying that jurisdiction is currently only 'US' and providing examples of tax year usage, going beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'returns' and resource 'machine-readable annual rates for a given jurisdiction + tax year', listing specific rate types. It distinguishes from siblings indirectly but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use this when the user asks specific dollar amounts that change yearly' with examples. No explicit when-not-to-use, but clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_skillGet a tax skillARead-onlyIdempotentInspect
Fetch a published skill by slug, including its current-version markdown, quality tier, named verifier (where accountant-verified), and a provenance/attribution footer.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Skill slug, e.g. 'us-schedule-c-and-se-computation' |
Output Schema
| Name | Required | Description |
|---|---|---|
| skill | Yes | The skill record (slug, name, jurisdiction, tier, etc.) |
| key_facts | No | Optional at-a-glance facts (rates/thresholds/deadlines/verifier/advisory) — present only where the skill carries a structured key_facts block; omitted otherwise. |
| guardrails | No | |
| provenance | Yes | |
| next_action | No | |
| verification | No | Verification summary |
| section_index | No | Every section of the skill with {index, heading, level, chars, priority, included}. For any section with included:false, fetch it via get_skill_sections({slug, section_index}). |
| current_version | No | Current version. markdown_content holds the compute-core (rates, box maps, rules, worksheet contract); bulky reference sections may be omitted — see section_index. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds beyond that by specifying the returned data: current-version markdown, quality tier, verifier, and footer. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb and resource, lists key included items, and contains no extraneous information. 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 simple tool with one parameter and an output schema, the description is complete. It explains what is fetched without needing to describe return values, as the output schema covers 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 description coverage is 100% for the single parameter 'slug'. The description mentions 'by slug' but adds no additional meaning beyond the schema example. 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 verb 'Fetch', the resource 'published skill by slug', and lists specific items included (markdown, quality tier, verifier, footer). This distinguishes it from sibling tools like list_skills or get_skill_sections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a single skill by slug, but it does not explicitly mention when not to use it or provide alternatives like list_skills or search_skills. Clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_skill_sectionsGet a skill's sectionsARead-onlyIdempotentInspect
Fetch the parsed sections of a skill's current version. Each section has a heading and its markdown content. Use this to pull a specific section that get_skill listed in section_index as not inlined (e.g. a supplier-pattern library) — pass section_index to fetch just that one. Omit it to get every section.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Skill slug | |
| section_index | No | Optional. Return only this section (matches the `index` from get_skill's `section_index`). | |
| section_indices | No | Optional. Return only these sections. |
Output Schema
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| version | No | |
| sections | Yes | |
| key_facts | No | Optional at-a-glance facts — present only where the skill carries a structured key_facts block; omitted otherwise. |
| guardrails | No | |
| next_action | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, providing strong behavioral transparency. The description adds that output includes heading and markdown content, which is consistent but not a significant addition 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?
Three sentences, front-loaded with purpose, followed by structure and usage. Every sentence is necessary and concise, 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?
Covers purpose, usage, and the most important parameter. Minor omission: does not explicitly mention section_indices parameter, but schema handles it. Output schema exists, so return values are documented. Overall sufficient for correct tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. Description adds useful context for section_index (linking to get_skill's section_index) but does not mention section_indices. Overall, it adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches parsed sections of a skill's current version, with each section containing heading and markdown content. It distinguishes from sibling tool get_skill by specifying it retrieves the actual content, not just indices.
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?
Explicit guidance on when to use section_index (for a specific non-inlined section from get_skill's section_index) and when to omit it (to get all sections). Clearly differentiates use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_jurisdictionsList all jurisdictions coveredARead-onlyIdempotentInspect
Returns every jurisdiction with published skills — countries (ISO 2), US states (US-XX), Canadian provinces — with skill counts, accountant-verified counts, and named lead verifier. Use when the user asks 'which countries does OpenAccountants cover?' or 'what's available for [country]?' Avoids paginating through list_skills to compute this.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| next_action | No | |
| total_skills | No | |
| jurisdictions | No | |
| total_jurisdictions | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds valuable context about returned data fields and pre-computed nature, complementing annotations (readOnlyHint, idempotentHint, openWorldHint). Could mention if any latency or caching, but overall sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a usage sentence. Front-loaded with key information, no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema, the description fully covers what the tool does, what it returns, and when to use it. Complete for its 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?
No parameters in schema, baseline 4. Description implicitly explains that no input is needed since it returns all jurisdictions. No further param detail required.
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?
Clear verb 'Returns' with specific resource 'jurisdictions' and detailed output fields (skill counts, verified counts, lead verifier). Explicitly distinguishes from sibling tool 'list_skills' by noting it avoids pagination.
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?
Provides explicit when-to-use examples ('which countries does OpenAccountants cover?', 'what's available for [country]?') and tells what to avoid ('Avoids paginating through list_skills').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_skillsList tax & accounting skillsARead-onlyIdempotentInspect
List all published OpenAccountants skills with their quality tier and verification status. Optionally filter by jurisdiction (e.g. 'US', 'MT', 'DE', 'GB'), domain (the accounting area, e.g. 'vat-gst', 'payroll', 'income-tax'), or role ('foundation' | 'compute' | 'orchestrator' | 'reference').
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Filter by pipeline role: foundation, compute, orchestrator, reference. | |
| domain | No | Filter by accounting domain: income-tax, vat-gst, payroll, bookkeeping, e-invoicing, formation, financial-statements, transfer-pricing, tax-optimization, crypto, cross-border. | |
| category | No | (Legacy) display label; prefer domain/role. | |
| jurisdiction | No | Filter by jurisdiction code, e.g. 'US', 'MT', 'DE' |
Output Schema
| Name | Required | Description |
|---|---|---|
| skills | Yes | Matching published skills. |
| next_action | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral context by stating it lists 'published' skills and returns 'quality tier and verification status', which adds value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It front-loads the primary purpose and follows with optional filters. 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?
Given the rich annotations, complete schema, output schema, and sibling tools, the description is fully adequate. It explains the tool's core function and all filtering options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description reinforces parameter meanings with real-world examples (jurisdiction codes, domain names) and notes that 'category' is legacy. This adds clarity and convenience beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'skills', specifies the returned fields (quality tier, verification status), and mentions optional filters. It distinguishes from siblings like 'get_skill' and 'search_skills' by being a broad list with filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (list all skills with optional filters) and provides concrete examples for each filter parameter. It does not explicitly state when not to use or list alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_verifiersList named accountant verifiersARead-onlyIdempotentInspect
Returns named licensed accountants who have signed off on OpenAccountants jurisdictions. Use ONLY when the user explicitly asks to see the verifier network or 'who verified this skill'. Do NOT use this to check whether a jurisdiction is covered before calling request_accountant_review — just call request_accountant_review directly, it routes to the right person regardless.
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | No | Optional ISO code filter — only return verifiers for this jurisdiction. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | No | |
| verifiers | No | |
| next_action | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, indicating safe, read-only behavior. The description adds context by specifying that it returns 'named licensed accountants', but does not introduce any additional behavioral 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?
The description is concise, consisting of two sentences that front-load the purpose and provide clear usage guidelines. No superfluous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, robust annotations, and an output schema), the description is complete. It covers the tool's purpose, usage context, and restrictions without needing additional elaboration.
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 the single parameter 'jurisdiction' already described in the schema as 'Optional ISO code filter — only return verifiers for this jurisdiction.' The tool description does not add extra meaning beyond the schema's description, 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 verb 'Returns', the resource 'named licensed accountants', and the context 'who have signed off on OpenAccountants jurisdictions'. It distinguishes itself from sibling tools by providing specific usage instructions, such as not using it to check jurisdiction coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use conditions ('when the user explicitly asks to see the verifier network or 'who verified this skill'') and when-not-to-use ('Do NOT use this to check whether a jurisdiction is covered before calling request_accountant_review'). It also gives an alternative action: 'just call request_accountant_review directly'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plan_cross_borderPlan a cross-border / multi-country tax situationARead-onlyIdempotentInspect
THE cross-border tool. Use this — not compare_jurisdictions — whenever a person's facts touch more than one country: a US citizen living abroad, a dual resident, someone changing residence, a non-dom, an expatriating citizen, or an owner of a foreign trust/company. Unlike compare_jurisdictions (which loads each country as an independent block and disclaims treaty/PE interaction), this returns a SEQUENCED plan: it builds the residency/citizenship/domicile map, identifies the country skills AND the international topic skills (FEIE/FTC, FBAR/FATCA, CFC/GILTI, foreign trusts, exit tax) the facts engage, fixes the ORDER of events (order changes the tax — e.g. sever residency before vs. after a sale), names the verifier per country, states the treaty bridge for double-tax relief, and mandates a request_accountant_review hand-off to the lead country's accountant. Always load cross-border-tax-router + cross-border-tax-workflow-base first (returned in load_first). Output is research-grade (tier 2) until a licensed human signs off.
| Name | Required | Description | Default |
|---|---|---|---|
| event | No | The asset/income/event in question and ideally WHEN — e.g. 'sell an Australian discretionary trust in 2026', 'renounce US citizenship', 'exercise founder options before moving'. | |
| assets | No | Optional: foreign entities/assets owned — companies, trusts, partnerships, pensions, foreign funds. Drives the anti-deferral and reporting skills. | |
| domicile | No | Optional: domicile, if a remittance-basis country (UK, Malta, Ireland, Cyprus) is involved. | |
| citizenship | No | Citizenship(s) held — ISO codes, slugs, or names (e.g. ['US', 'malta']). Drives citizenship-based taxation (US) and exit-tax tests. | |
| event_timing | No | When is the key event expected to occur? e.g. 'sale expected to complete in 6 weeks', 'planning to move in 3 months', 'still conceptual'. Drives urgency assessment and scenario feasibility. | |
| tax_residences | No | Country(ies) of tax residence now, and any country being moved to/from. First entry is treated as the primary residence. |
Output Schema
| Name | Required | Description |
|---|---|---|
| needs | No | |
| status | No | |
| guardrails | No | |
| load_first | No | |
| next_action | No | |
| residency_map | No | |
| country_blocks | No | |
| engagement_scope | No | Per-country advisor scope derived from the facts and skills available. |
| lead_jurisdiction | No | |
| scenario_guidance | No | 2-4 event-ordering scenarios derived from the facts, each with a sequence, consequence summary per country, and urgency rating. |
| sequence_guidance | No | |
| treaty_bridge_note | No | |
| uncovered_jurisdictions | No | |
| international_topic_skills | No | |
| us_citizenship_taxation_engaged | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by disclosing that the tool returns a sequenced plan, that order of events matters, that it identifies specific international skills, and that it mandates a hand-off to request_accountant_review. No contradiction with annotations (readOnlyHint, idempotentHint).
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 well-structured paragraph that efficiently conveys all necessary information: purpose, usage, behavior, prerequisites, and output. Every sentence adds distinct value, no 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 complex cross-border tax tool with 6 parameters and many siblings, the description covers all essential aspects: what it does, when to use, what it returns (sequenced plan with ordering, skills, verifier, treaty bridge), and what to load first (cross-border-tax-router etc.). The presence of an output schema reduces the need to explain return structure, but the description still provides critical context about the output's nature and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context for several parameters: explains how assets drive anti-deferral skills, domicile relevance for remittance, citizenship for citizenship-based taxation, event_timing for urgency, and tax_residences for primary residence. This adds value beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose as the cross-border tax planning tool, lists specific use cases (US citizen abroad, dual resident, etc.), and distinguishes it from compare_jurisdictions by emphasizing sequencing and interaction.
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 this tool ('whenever a person's facts touch more than one country') and when not to ('not compare_jurisdictions'), with clear reasoning about the limitations of the alternative (no treaty/PE interaction in compare_jurisdictions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_accountant_reviewRequest a licensed accountant to reviewAInspect
THE handoff tool. Call this for ANY jurisdiction whenever (a) the user wants their working paper reviewed before filing, (b) the situation needs professional sign-off, (c) it involves cross-border or high-stakes advice, (d) the user asks to speak to an accountant, or (e) real money is at stake. BEFORE calling this tool: ask the user for their email address (contact_email) and name (contact_name) — the accountant needs these to follow up if the user does not book via Calendly. Do NOT proceed without at least contact_email. Do NOT call list_verifiers first. The network handles coverage. CRITICAL: always pass the full working_paper so the reviewer sees the computation before the call.
| Name | Required | Description | Default |
|---|---|---|---|
| urgency | No | urgent = filing in <2 weeks; standard = current filing season; planning = future-year strategy. | |
| scenario | Yes | Brief description of the situation the user needs reviewed — e.g. '2025 sole-trader Schedule C with home office + crypto disposals + new dependant', 'considering S-corp election', 'multi-state RSU vest'. The verifier reads this before the call. | |
| tax_year | No | Tax year the review concerns, if relevant. | |
| worksheet | No | Optional structured worksheet (JSON object) conforming to WORKSHEET_CONTRACT.md: { jurisdiction, tax_type, period, currency, lines:[{net_box,vat_box,net,rate,vat}], boxes:[{box,label,amount,sources:[{label,amount}]}], result:{type,amount} }. Provide for VAT returns where box-level reconciliation can be foot-checked. Not required for income tax or other working papers — the prose working_paper alone is sufficient. | |
| source_url | No | Optional public URL where the working paper can also be viewed (e.g. a Google Doc the user authored, a Notion page). | |
| contact_name | No | User's name — ask for this alongside the email. The accountant uses it to address the user before the call. | |
| jurisdiction | Yes | ISO code or slug for the user's tax jurisdiction (e.g. 'ZA', 'US-CA', 'malta'). Required. | |
| contact_email | No | User's email address — REQUIRED. Ask the user for this before calling the tool. The accountant needs it to follow up if the user does not book via Calendly. Do not submit without it. | |
| working_paper | No | The full working paper — classified transactions, computation, draft return lines, issue map — as plain markdown. ALWAYS pass this when you have produced any structured tax output. Without it, the accountant walks into the call blind. With it, they can review before the call and the user gets a better outcome. Capped at 512 KB UTF-8; trim if needed. No worksheet JSON required — the prose working paper alone is sufficient to create the consultation request. | |
| working_paper_format | No | Format hint for the working paper. Default 'markdown'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| captured | Yes | Whether the request landed server-side. |
| accountant | No | |
| request_id | No | |
| calendly_url | Yes | |
| capture_error | No | |
| worksheet_attached | No | |
| no_verifier_assigned | No | |
| working_paper_attached | No | |
| worksheet_recon_status | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool initiates a human review process, requiring critical inputs (contact info, working_paper) for accountant follow-up. Adds behavioral context beyond annotations: the accountant reads the working paper before a call, and the tool should not be called without proper preparation. 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?
Well-structured with front-loaded purpose, clear bullet-point conditions, and explicit warnings. Slightly verbose in listing all scenarios but each sentence adds value. Could be marginally more concise without losing 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?
Covers prerequisites, parameter usage, and important warnings. Lacks explicit expectations about post-call outcomes (e.g., confirmation, timing). With an existing output schema, this gap is partially mitigated, but a brief note on what happens after calling would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description enriches parameter meaning: emphasizes contact_email and working_paper as critical, explains worksheet is optional for VAT, and describes how scenario aids the verifier. Adds usage context beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies it as a handoff tool for accountant review, listing five specific trigger scenarios (working paper review, professional sign-off, cross-border/high-stakes, user requests accountant, real money at stake). It distinguishes itself by warning against calling list_verifiers first, showing purpose differentiation from siblings.
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 call (five clear criteria), what prerequisites to fulfill (ask for contact_email and contact_name), and what not to do (do not call list_verifiers). Also warns not to proceed without contact_email, providing unambiguous usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_skillsSearch skills by keywordARead-onlyIdempotentInspect
Search across all published skills by keyword. Finds skills mentioning specific tax concepts, deduction types, or regulations (e.g. 'home office deduction', 'crypto capital gains', 'reverse charge'). Optionally limit to one jurisdiction.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term, e.g. 'home office deduction', 'crypto capital gains', 'reverse charge' | |
| domain | No | Optional accounting domain to limit the search (e.g. 'vat-gst', 'payroll', 'income-tax', 'crypto'). | |
| jurisdiction | No | Optional ISO 2-letter country code to limit the search |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| results | Yes | |
| next_action | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, etc.) cover safety and idempotence. Description adds domain/jurisdiction filtering but not deeper behavioral traits (e.g., pagination, result count).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action and examples, no filler.
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 output schema present, return values need no explanation. Description covers purpose, filters, and examples, providing sufficient context for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds examples but does not enhance parameter meaning 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 clearly states it searches skills by keyword, with examples (e.g., 'home office deduction'), and mentions optional jurisdiction filter, distinguishing it from siblings like get_skill or list_skills.
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?
Provides clear context with examples of when to use (searching specific tax concepts) and optional filters, but lacks explicit 'when not to use' or comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
startStart a tax workflowARead-onlyIdempotentInspect
Front door for any tax / accounting question once you know what the user wants. intent is REQUIRED (e.g. 'taxes', 'VAT return', 'set up a company', 'find deductions', 'classify transactions', 'payroll'); pass a jurisdiction too (ISO 2-letter, e.g. 'MT', 'GB', 'US-CA'). If you don't yet have an intent, call start_help first. Returns either a clarification request (if jurisdiction is missing) or a ready-to-execute plan with the list of skills to load. Call this FIRST (after start_help if needed) whenever the user asks for tax help.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | User intent — REQUIRED. Free text, e.g. 'taxes', 'VAT return', 'set up a company'. | |
| jurisdiction | No | ISO 2-letter code or US state code (e.g. 'MT', 'GB', 'US-CA'). |
Output Schema
| Name | Required | Description |
|---|---|---|
| needs | No | |
| intent | No | |
| status | No | |
| guardrails | No | |
| next_action | No | |
| expectations | No | |
| jurisdiction | No | |
| skills_to_load | No | |
| available_intents | No | |
| available_jurisdictions | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by stating the tool returns either a clarification request or a plan, and that `intent` is required. Annotations already provide readOnlyHint, idempotentHint, and non-destructive nature, so the description complements them well 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 concise (two sentences plus a note) and front-loaded with the primary purpose. It efficiently conveys critical usage information without unnecessary verbosity, though the inline code formatting slightly reduces readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description adequately covers the tool's core behavior (returns plan or clarification). It addresses potential confusion about intent and jurisdiction, making it complete for the 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?
With 100% schema coverage, the description still adds value by explaining the `intent` parameter is 'REQUIRED' and providing examples for both parameters (e.g., 'taxes', 'MT'). It clarifies optionality of jurisdiction and its effect on return type.
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 is the 'Front door for any tax / accounting question once you know what the user wants', specifying verb (start), resource (workflow), and required parameters. It also distinguishes itself from sibling `start_help` by indicating when to call that alternative.
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 provides usage guidance: 'Call this FIRST (after start_help if needed) whenever the user asks for tax help', and explains when to use `start_help` instead ('If you don't yet have an intent, call `start_help` first').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_helpGet tax-workflow scoping guidance (no args)ARead-onlyIdempotentInspect
No-argument front door. Call this when a user asks for tax / accounting help but you don't yet know WHAT they want or WHERE. Returns the two scoping questions to ask plus the available intents and jurisdictions. Once you have an intent, call start(intent, jurisdiction). Use this instead of calling start with empty arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| needs | No | |
| status | No | |
| next_action | No | |
| available_intents | No | |
| available_jurisdictions | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false. The description adds significant behavioral context beyond annotations by stating the tool returns two scoping questions plus available intents and jurisdictions. This clarifies the exact output and confirms no side effects, fully informing the agent of the tool's behavior.
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 very concise at five short sentences, each contributing unique value. It is front-loaded with the core purpose ('No-argument front door'), followed by usage condition, return content, and sibling alternative. No redundant or unnecessary information is present.
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, the description does not need to detail return values. It covers the tool's purpose, usage, and relationship to siblings (especially 'start'). The context is fully sufficient for an agent to understand when and how to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description does not need to add parameter details since none exist. It reiterates that it's a 'No-argument front door,' which aligns with the schema. No additional semantics are required.
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 as a 'No-argument front door' for tax/accounting help, specifying it returns scoping questions and available intents/jurisdictions. It distinguishes itself from the sibling 'start' tool, which requires explicit intent and jurisdiction, thereby clarifying its unique role as a discovery 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 provides explicit usage guidance: 'Call this when a user asks for tax/accounting help but you don't yet know WHAT they want or WHERE.' It also instructs when to use the sibling tool 'start' instead—'Once you have an intent, call start(intent, jurisdiction)'—and advises against calling 'start' with empty arguments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackSubmit feedback on a skillARead-onlyIdempotentInspect
When the user finds an error in a skill, says rates look outdated, or wants to suggest an improvement, call this to generate a pre-filled GitHub Issue URL. The URL opens in the user's browser with the report partially filled — they review and submit. This creates a public feedback loop that maintains skill quality over time. Use whenever the user says 'this seems wrong', 'the rate is outdated', 'add this rule', or asks how to flag an issue.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_slug | Yes | Slug of the skill the feedback relates to (e.g. 'malta-income-tax'). | |
| description | Yes | What's wrong, outdated, or missing — be specific. | |
| feedback_type | No | Category of feedback. | |
| user_jurisdiction | No | Optional: the user's jurisdiction context for the report. |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | No | |
| github_issue_url | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, idempotentHint, and non-destructive behavior; the description adds context about the URL being opened in the user's browser for review and submission, and mentions the public feedback loop. 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: first states purpose, second explains behavior, third provides usage cues. Well-structured, front-loaded, and 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 output schema exists (context confirms), the description covers the flow, usage scenarios, and behavioral context. It is complete for the 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 coverage is 100%, so the description doesn't need to add much. It mentions skill_slug and description as required, and gives examples of feedback keywords, but does not elaborate beyond the schema details.
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 generates a pre-filled GitHub Issue URL for feedback on a skill, specifying the verb (submit_feedback) and resource (feedback). It differentiates from siblings by focusing on user feedback, not data retrieval or comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios ('error', 'outdated', 'suggestion') and example user utterances ('this seems wrong', 'the rate is outdated'). It lacks explicit when-not-to-use guidance 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.
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.