This server lets an AI browse and read OpenAccountants' open-source tax guide library by jurisdiction.
list_jurisdictions – Returns all country/jurisdiction slugs available under packages/ that contain at least one skill file.
list_files – Given a jurisdiction slug (e.g. "malta", "uk", "germany"), lists the .md and .json skill files in that jurisdiction's package.
get_file – Retrieves the full UTF-8 text of a specific skill file (up to 2 MB) so the AI can cite the actual reviewed tax guide content.
Integration with QuickBooks for accounting and bookkeeping tax skills.
Integration with Shopify for e-commerce tax and accounting skills.
Integration with Stripe for payment processing tax skills.
Integration with Wise for cross-border payment tax skills.
Integration with Xero for accounting and bookkeeping tax skills.
Open-source Tax Guides your AI can cite — reviewed by named, licensed accountants.
Every AI can do tax math. None of them can stand behind an answer. Here, real accountants put their name, credential and review date on the Guides your AI reads — publicly, on the record, in this repo.
1,864 Guides across 232 jurisdictions · 176 accountant-reviewed · 44 named accountants · 11,978 questions answered through connected AIs
Live from openaccountants.com — updated 2026-09-19 by the nightly sync.
Add the hosted connector to Claude, ChatGPT, Cursor, Windsurf or any MCP client:
https://www.openaccountants.com/api/mcpGuided setup: openaccountants.com/connect
Then ask a question your AI would otherwise guess at:
"What's the combined sales tax rate in Manatee County, Florida for 2026?"
Without OpenAccountants, models answer from training data. With it, the answer cites the current Guide — and names the accountant who reviewed it.
You: "I'm a freelancer in South Africa. What do I owe?"
↓ loads za-income-tax, za-provisional-tax
AI: ITR12 working paper · IRP6 provisional schedule
Medical credits · Retirement annuity deduction
─────────────────────────────────────────
Reviewed by Werner Britz CA(SA)pip MCP server: pip install openaccountants-mcp (mirrors this repo's packages/)
Manual: download your jurisdiction's folder from packages/ and upload the files to your AI. Start with your country's main package; index.json is the machine-readable inventory.
Related MCP server: mcp-europe-business
Every Guide is in exactly one state — and the repo greps honestly:
State | Meaning |
Accountant-reviewed | A named, licensed accountant reviewed the complete Guide. Their name is in the frontmatter ( |
Source-cited draft | Written from primary legislation, every figure cited to its source — not yet professionally reviewed |
⚠️ General reference, not advice. Guides may be incomplete, outdated, or wrong for your facts. Have a qualified professional review outputs before filing, payment, or action.
Your name on the tax knowledge AI actually uses — with attribution built in:
Build a Guide for the work you know cold: openaccountants.com/skills/new. It publishes credited to you, and lands in this repo under your name.
Review a Guide in your jurisdiction — your name, credential and review date go on it, here and on every AI answer that cites it.
Set your GitHub username in your profile and your platform edits are committed to this repo as you — your contribution graph reflects your work.
The current roster: VERIFIERS.md (generated nightly from the platform).
A tax library is only as good as its worst stale number, so machines re-check this one every night:
The maths check re-reads every guide and flags sums that do not add up, tax bands with gaps, totals that do not total, and years that disagree.
The source watch visits the official pages the figures came from and raises a hand when a page changes.
The refresh engine re-derives the stalest guides from official sources on a fixed monthly budget, refusing to publish any figure without a link.
The nightly exam tests whether AIs actually said what the guides say that day, or improvised. Improvisation gets caught, counted and fixed at the source.
The sync runs both ways: platform edits land here as commits under the author's own name, and merged PRs here flow back into what every AI serves, credited to you. A guide with an accountant's byline never changes without that accountant's one-click approval.
The whole story, in plain words: openaccountants.com/how-it-works
Edit skills/** only — everything else regenerates automatically:
packages/, index.json, llms-full.txt — generated nightly; never edit in a PR
Merged source PRs are credited to you and must be confirmed as ingested before the next platform export
Full guide: CONTRIBUTING.md · Layout: docs/REPO-LAYOUT.md
What | Where |
Guide source (per jurisdiction) | |
Per-country bundles (generated) | |
Machine-readable inventory | |
LLM entry point | |
Python MCP server | |
Repo architecture + sync |
API and platform integrations: openaccountants.com/for-developers
Independent, open-source review aids and calculation tools that complement the OpenAccountants guide library:
payday-super-checker (MIT) — Verifies superannuation contributions against Australian Payday Super deadlines (in force since 1 July 2026) and estimates SG charge exposure on late payments, with all workings and statutory assumptions disclosed.
div7a-loan-review (MIT) — Reviews Division 7A loan terms and minimum yearly repayments against the ATO benchmark interest rate, with fabricated inputs and explicit refusal boundaries.
xero-trial-balance-export (MIT) — Exports a Xero trial balance to CSV only when month-movement and YTD column pairs both balance exactly.
ato-benchmark-compare (MIT) — Evaluates business P&L statements locally against the Australian Taxation Office (ATO) small business performance benchmarks, surfacing variance flags and ratio analyses.
(External tools provide computational review assistance and do not constitute tax or legal advice.)
Code (mcp/, scripts/, tools/): AGPL-3.0
Guide content: OpenAccountants Guide License v1.0 — see LICENSING.md; commercial options in COMMERCIAL-LICENSING.md
Contact: info@openaccountants.com · Security policy · Cite this repo
Read one skill file and return its UTF-8 text.
Args: jurisdiction: Country slug (e.g. "malta"). filename: File inside that package (e.g. "foundation.md").
Returns: The full file contents as a string (capped at 2 MB).
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| jurisdiction | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that the tool is read-only and caps output at 2 MB, but omits other behavioral traits like authentication needs or error handling.
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 and well-structured: one line for purpose, two lines for parameters with examples, and one line for return value. No irrelevant 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?
For a simple tool with two string parameters, the description covers purpose, parameters, and return behavior (including the 2 MB cap). It lacks potential error conditions but is otherwise 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?
With 0% schema description coverage, the description adds valuable context by providing example values for each parameter, clarifying that 'jurisdiction' is a country slug and 'filename' is a file within that package.
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 reads a skill file and returns UTF-8 text. It specifies the two parameters with examples, distinguishing it from siblings 'list_files' and 'list_jurisdictions'.
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 for reading a single file by naming the required parameters and return type. It does not explicitly mention when not to use or alternatives, but the sibling tool names provide context, making the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List .md (and .json) skill files for a jurisdiction.
Args: jurisdiction: Country slug exactly as returned by list_jurisdictions (e.g. "malta", "uk", "germany").
Returns: Sorted list of filenames inside packages//.
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return format (sorted list of filenames) and file types, as well as the path structure, without contradicting any missing 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?
Concise, structured with purpose statement and docstring, front-loaded, with no redundant content.
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?
Fully covers input, output, and constraints for a simple list tool; output schema is present, and the description complements 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?
Adds essential detail for the single parameter, including expected format, source, and examples, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists .md and .json skill files for a jurisdiction, distinguishing it from sibling tools list_jurisdictions and get_file.
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 context on when to use (listing files for a jurisdiction) and references list_jurisdictions for the slug, but does not explicitly exclude use cases for siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available country/jurisdiction slugs under packages/.
Returns directory names that contain at least one .md file (i.e. look like a real skill package, not an empty placeholder).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of disclosure. It explains that only directory names containing at least one .md file (real skill packages) are returned, which is a useful behavioral trait. However, it does not specify whether the listing recurses into subdirectories or if the slugs are relative paths, leaving some ambiguity.
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 extremely concise: two sentences that get straight to the point. The first sentence front-loads the main purpose, and the second adds a critical detail about filtering. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and an output schema, the description is mostly complete. It explains the output (directory names) and filtering logic. However, it could be slightly more explicit about the format of the returned slugs (e.g., relative paths or just names) to eliminate any ambiguity, though the output schema likely covers this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description needs no additional parameter documentation. The baseline for 0 parameters is 4, and the description meets this by being clear about what the tool does without requiring parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to list available country/jurisdiction slugs under packages/. It specifies the verb 'list' and the resource 'slugs', and adds a filtering criterion (directories with at least one .md file). This distinguishes it from sibling tools like list_files, which list files rather than subdirectories.
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 does not provide explicit guidance on when to use this tool versus alternatives like list_files or get_file. The purpose is implied by the description, but no when-to-use, when-not-to-use, or alternative mentions are given, reducing clarity for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.0get_filelist_fileslist_jurisdictionsScored across 3 tools
Each tool has a distinct, non-overlapping purpose: list_jurisdictions returns available countries, list_files returns files within a jurisdiction, and get_file returns the content of a specific file. There is no ambiguity about which tool to use for a given task.
All tools follow a consistent verb_noun pattern using snake_case: list_jurisdictions, list_files, get_file. This makes the tool set predictable and easy for an agent to understand and use.
Three tools is exactly right for this read-only skill file retrieval server. Each tool is essential for navigating the data hierarchy (jurisdictions → files → content), and no redundant or missing operations are present.
The tool set fully covers the intended domain: listing jurisdictions, listing files within a jurisdiction, and retrieving file content. As a read-only system, there are no gaps for the given purpose.
Verifiable US tax oracle for AI agents: cited, machine-checkable federal and state tax computation
Sourced Italian tax tools for AI agents: cited primary-source search + a deterministic tax engine.
EU/UK VAT compliance for AI agents: number validation, rate lookups, reverse-charge checks.
Free public tax MCP: GST/VAT, income, company & capital-gains tax for 50+ countries, source-cited.
