OpenAccountants

Start a tax workflow

start

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`intent`	Yes	User intent — REQUIRED. Free text, e.g. 'taxes', 'VAT return', 'set up a company'.
`reason`	No	One sentence, in the user's own words, on what they actually asked for here — captured only to improve routing. E.g. 'user sold ETH and wants to know what to report'. Optional but helpful.
`acting_as`	No	REQUIRED. Who the user is: 'self' = a taxpayer handling their OWN taxes; 'client' = a professional (accountant/advisor) working on behalf of a CLIENT. Establish this before calling — if it isn't clear from the conversation, ask the user one short question ('Are these your own taxes, or are you helping a client?'). Never guess.
`jurisdiction`	No	ISO 2-letter code or US state code (e.g. 'MT', 'GB', 'US-CA').
`taxpayer_type`	No	The taxpayer's occupation, when known. Some return-prep workflows fork by it (an employee's Form 1040 is a different guide from a freelancer's). Pass it if the conversation already makes it clear; otherwise omit — start() only asks for it (status:'needs_clarification', needs:['taxpayer_type']) when the guides for this jurisdiction/intent genuinely split by occupation. 'employee' = W-2 wages only; 'self-employed' = freelance / 1099 / sole-proprietor; 'both' = employed AND self-employed; 'company' = a corporate entity. Don't guess — ask the user one short question if unsure.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedAug 26, 2026

changedInput schema / required

Previous value: -[
-  "intent",
-  "acting_as"
-]New value: +[
+  "intent"
+]

Changed1 schema field changedJul 14, 2026

addedInput schema / properties / taxpayer_type

Added value: +{
+  "description": "The taxpayer's occupation, when known. Some return-prep workflows fork by it (an employee's Form 1040 is a different guide from a freelancer's). Pass it if the conversation already makes it clear; otherwise omit — start() only asks for it (status:'needs_clarification', needs:['taxpayer_type']) when the guides for this jurisdiction/intent genuinely split by occupation. 'employee' = W-2 wages only; 'self-employed' = freelance / 1099 / sole-proprietor; 'both' = employed AND self-employed; 'company' = a corporate entity. Don't guess — ask the user one short question if unsure.",
+  "enum": [
+    "employee",
+    "self-employed",
+    "both",
+    "company",
+    "other"
+  ],
+  "type": "string"
+}

Changed1 schema field changedJul 13, 2026

addedInput schema / properties / reason

Added value: +{
+  "description": "One sentence, in the user's own words, on what they actually asked for here — captured only to improve routing. E.g. 'user sold ETH and wants to know what to report'. Optional but helpful.",
+  "type": "string"
+}

Changed2 schema fields changedJun 30, 2026

addedInput schema / properties / acting_as

Added value: +{
+  "description": "REQUIRED. Who the user is: 'self' = a taxpayer handling their OWN taxes; 'client' = a professional (accountant/advisor) working on behalf of a CLIENT. Establish this before calling — if it isn't clear from the conversation, ask the user one short question ('Are these your own taxes, or are you helping a client?'). Never guess.",
+  "enum": [
+    "self",
+    "client"
+  ],
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "intent"
-]New value: +[
+  "intent",
+  "acting_as"
+]

Changed1 schema field changedJun 18, 2026

changedOutput schema / properties / status / enum

Previous value: -[
-  "ready",
-  "needs_input",
-  "needs_clarification"
-]New value: +[
+  "ready",
+  "needs_input",
+  "needs_clarification",
+  "uncovered"
+]

Changed2 schema fields changedJun 2, 2026

changedInput schema / properties / intent / description

Previous value: -"User intent. Free text, e.g. 'taxes', 'VAT return', 'set up a company'."New value: +"User intent — REQUIRED. Free text, e.g. 'taxes', 'VAT return', 'set up a company'."

addedInput schema / required
```
Added value: +[
+  "intent"
+]
```

AddedMay 27, 2026

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond that: it explains the return behavior (clarification request or plan) and notes that the 'reason' parameter is 'captured only to improve routing', which is transparent about its side-effect-free intent. It doesn't describe error conditions or rate limits, but the annotations plus this additional info are sufficient for an agent to understand 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place. It front-loads the purpose and usage, then covers parameters efficiently without redundancy. The structure flows logically from general to specific, and the inclusion of usage examples (e.g., 'MT', 'GB', 'US-CA') adds value without bloat. It is concise given the complexity of the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with an output schema, this description is remarkably complete. It covers all parameter semantics, provides clear usage flow, and explains the return types (clarification or plan). It also addresses edge cases like missing jurisdiction and unsure taxpayer_type. The description gives an agent everything needed to decide when and how to call this tool correctly, making it fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by providing additional meaning: it marks 'intent' as REQUIRED, explains 'acting_as' in detail with concrete examples and a directive to never guess, and elaborates on 'taxpayer_type' including when it is needed and when to omit it. These enrich the schema beyond simple field definitions, justifying a score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear purpose: it is the 'front door' for tax/accounting questions, and it explicitly differentiates itself from the sibling start_help. It names the resource (workflow) and the action (start), and the scope is well-defined (any tax/accounting question). An agent can immediately tell this is the entry-point tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage guidance: 'Call this FIRST (after start_help if needed) whenever the user asks for tax help.' It also specifies when not to use it ('If you don't yet have an intent, call start_help first') and names the alternative start_help. It even instructs how to handle missing jurisdiction or unclear actor, making the decision path unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All OpenAccountants tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation4/5

Most tools target clearly distinct actions: front-door helpers (start, start_help), skill retrieval (get_skill, get_skill_sections), discovery (list_skills, search_skills, list_jurisdictions), and specialized validators (check_audit_exemption, validate_vat_number). The only real ambiguity is between search_rules and search_skills, though the descriptions draw a careful line (rules vs. full-text skill search) that mitigates misselection.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern: check_, get_, list_, search_, share_, start_, validate_. Even the two exceptions, start and start_help, are predictable and intentionally minimal. The naming makes the API surface easy to learn and remember.

Tool Count5/5

14 tools is squarely in the well-scoped range for an accounting/tax assistant server. Each tool earns its place: discovery, retrieval, search, live validation, deadlines, audit exemption, verifiers, and the outbound feedback channel. No redundant or filler tools are present.

Completeness4/5

The server covers the full read/discovery lifecycle for skills and rules, plus practical helpers like VAT validation, audit exemption checks, and deadline lookups. The main gap is the lack of an explicit tool to execute a skill or run a method — start() returns a plan but execution appears to happen outside the MCP surface, which agents may need to work around.

Start a tax workflow

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources