OpenAccountants

Search rules across jurisdictions

search_rules

Read-onlyIdempotent

Sweep tax rules ACROSS jurisdictions and metadata and get back a bundled markdown rule set plus the jurisdiction's OFFICIAL SOURCE. Best for cross-cutting questions — 'VAT rates in MT, IE and DE', 'all income-tax thresholds for 2025', 'rules mentioning reverse charge'. WHEN YOU WANT ONE SPECIFIC FIGURE for one jurisdiction (a single rate, threshold or date), prefer search_skills then get_skill: the Guide is where a topic is covered in full, and a figure can exist in the Guide without existing as a separate rule here, in which case this tool will return related guidance rather than the number you asked for. Entries whose text is guidance rather than a value are tagged GUIDANCE — never read one as a figure. IMPORTANT: this returns human-reviewed GUIDANCE and does NOT certify that a figure is current — confirm each number against the official source returned in official_source before you state it, and prefer that source when they disagree. By default returns ALL matching rules, each tagged with its verification status; pass status:'verified' for accountant-/research-verified only. Call list_rule_facets first to see the queryable values.

Input Schema

TableJSON Schema

Name	Required	Description
`text`	No	Free-text search over each rule's label, value, and citation.
`limit`	No	Max rules to return (default 200, max 500).
`roles`	No	Skill roles: foundation \| compute \| orchestrator \| reference.
`topic`	No	Filter by a fact topic.
`offset`	No	Pagination offset — pass the previous response's next_offset.
`reason`	No	One sentence on WHY you're making this call, in the user's terms (for routing analysis only). Optional.
`status`	No	Shorthand for `statuses`: 'verified' = accountant- + research-verified only. Default 'all'.
`domains`	No	Accounting domains, e.g. ['vat-gst','income-tax']. See list_rule_facets.
`statuses`	No	Verification statuses to include. Default = all (each rule is tagged).
`tax_year`	No	Limit to a tax year, e.g. 2025.
`block_types`	No	Rule kinds to include. Default = all of these (framing prose + workflow steps are excluded).
`jurisdictions`	No	ISO codes to include, e.g. ['MT','US-CA']. Omit for all jurisdictions.

Output Schema

TableJSON Schema

Name	Required	Description
`total`	No	Total matching rules (across all pages).
`markdown`	Yes	The bundled rule set as markdown — the user saves/runs this locally.
`truncated`	No
`fact_count`	Yes	Rules returned on this page.
`next_action`	No
`next_offset`	No
`jurisdictions`	No
`accountant_verified_count`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedJul 13, 2026

addedInput schema / properties / reason

Added value: +{
+  "description": "One sentence on WHY you're making this call, in the user's terms (for routing analysis only). Optional.",
+  "type": "string"
+}

AddedJun 23, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuinely valuable behavioral caveats beyond those: entries may be GUIDANCE rather than figures ('never read one as a figure'), and the tool 'does NOT certify that a figure is current' — with the instruction to confirm against official_source and prefer it on disagreement. This level of behavioral nuance is exactly what annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Long but every sentence earns its place for a 12-parameter cross-jurisdiction tool. The core purpose is front-loaded, emphasis is used sparingly and effectively (ACROSS, OFFICIAL SOURCE, GUIDANCE, IMPORTANT), and the structure flows from purpose → routing → caveats → defaults → prerequisites. Justified length given the tool's complexity, though tighter than a 5 would require.

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

Completeness4/5

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

For a complex cross-jurisdiction tool with 12 params, full schema coverage, and an output schema (so return values need not be spelled out), the description covers all key decision points: return shape (markdown set + official_source), routing to search_skills/get_skill, the guidance-vs-figure trap, currency caveat, status filter, and the list_rule_facets prerequisite. Very complete; only minor gaps like pagination behavior (offset/next_offset) are left to the schema.

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

Parameters3/5

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 12 parameters, warranting the baseline of 3. The description does add some value: it clarifies the status:'verified' shorthand as selecting accountant-/research-verified only, and points to list_rule_facets for queryable facet values (domains, etc.). But it doesn't materially enrich what the schema already states for most parameters.

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?

Description opens with a specific verb+resource: 'Sweep tax rules ACROSS jurisdictions and metadata and get back a bundled markdown rule set plus the jurisdiction's OFFICIAL SOURCE.' It names the cross-cutting use case with concrete examples ('VAT rates in MT, IE and DE') and explicitly differentiates from the sibling search_skills/get_skill pair. An agent can tell exactly what this tool does and what it is not for.

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?

Explicit when-to-use ('Best for cross-cutting questions'), explicit when-not-to-use with the named alternative ('WHEN YOU WANT ONE SPECIFIC FIGURE... prefer `search_skills` then `get_skill`'), including the rationale (a figure can exist in the Guide without existing as a separate rule). Also prescribes a prerequisite ('Call `list_rule_facets` first'). Routing guidance is unambiguous and complete.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.