Skip to main content
Glama

AccountsOS

by io.github.paulgosnell
OverviewDiscussionsAdmin

Lookup Tax Rule

lookup_tax_rule
Read-onlyIdempotent

Look up a verified tax or accounting rule by its key. The system automatically routes to the active company's own country library: every live country has one (e.g. India: gst-rate-slabs, personal-income-tax-slabs-new-regime), so never tell a user you only know UK rules. Use this for ANY question about specific deadlines, thresholds, notice periods, regulatory dates, or rules where being wrong would mislead the user. UK examples: vat-registration-threshold, ct-filing-deadline, mtd-itsa-mandatory-50k, dividend-allowance-2026-27, mileage-rates-2026-27. UAE examples: ct-rates, ct-filing-deadline, vat-rate, free-zone-qfzp, no-personal-income-tax. Returns the exact answer + an official source URL you MUST cite in your reply, and where the rule has a validity period, the dates it applies between. ALWAYS prefer this over stating a rule from memory. Apply the rule to the user's facts: when the answer turns on a fact only the user knows (when goods were delivered, when work was finished, when money arrived), ask for that fact, never for the conclusion (ask "when did you deliver it?", not "does it belong in Q3 or October?"). Once the user gives the fact, that is the fact: state the result the rule gives for it, with the source, and do not add that you cannot check it or that their accountant should confirm it. Point to an accountant only when the rule itself leaves the question open. For a question about a PAST period, or a FUTURE one (next year's rates where a budget has already set them), pass as_of so you get the rule for that date rather than the current one. If you do not know the exact key, call list_tax_rules first.

Input Schema

NameRequiredDescriptionDefault
keyYesThe rule key. Use list_tax_rules to see all available keys for the active company's country.
as_ofNoOptional ISO date (YYYY-MM-DD) the answer must be true for. Pass this whenever the question is about a PAST period - a prior-year return, an old invoice, a historic filing - or a FUTURE one such as next year's rates, because rates change and the current rule may not be the one that applies then. The system walks the rule history and returns the version in force on that date, plus the period it applies to. Omit for questions about today: the answer is then the version in force today. A next-year rule may not be law yet; its answer says so.
companyNoWhich company to read, by name or id, when the account has more than one (see list_companies). Leave it out to use the only company, or the default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds substantial behavior beyond them: automatic routing to the active company's country library, that it returns the exact answer plus a mandatory-cite source URL, that validity periods are included, and that as_of walks the rule history and may return a not-yet-in-law future rule.

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?

Front-loaded with purpose and country-routing, and nearly every sentence carries actionable guidance. It is long and has mild redundancy ('Use this for ANY question...' restated as 'ALWAYS prefer this over stating a rule from memory') plus answer-styling instructions that sit slightly outside the tool's mechanics.

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?

With no output schema, the description fully compensates by describing the return payload (exact answer, official source URL, validity period) and the as_of history behavior. An agent has everything needed to call it and to present the result correctly.

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 baseline is 3; the description still adds value by framing as_of around past/future-period intent and by pairing key with the list_tax_rules escape hatch. It doesn't add format details beyond the schema, so it doesn't reach 5.

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?

States a specific verb and resource ('look up a verified tax or accounting rule by its key') and immediately scopes it by explaining the automatic country-library routing. It is clearly distinguishable from list_tax_rules (enumeration) and search_tax_facts (free-text search) named in the same description.

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?

Gives explicit triggering conditions ('ANY question about specific deadlines, thresholds, notice periods, regulatory dates'), a strong exclusion ('ALWAYS prefer this over stating a rule from memory'), the fallback path ('if you do not know the exact key, call list_tax_rules first'), and a routing rule for as_of on past vs future periods.

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

All AccountsOS toolsInspect
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.

Resources