Tax Numbers

Check VAT or sales tax registration duty

tax_duty

Read-onlyIdempotent

Use this when a seller asks whether they must register for VAT or sales tax in a place, for example "I sell e-books from Germany and made 14,000 EUR to buyers in France, do I need to register?" or "my US company sells SaaS with 150,000 USD of sales to Texas, do I owe sales tax?". Pass seller_country, buyer_place, product_kind and yearly_sales in the money of the buyer place (leave it out when unknown); add yearly_transactions for US states that also count sales. Returns must_register (yes, no or unclear), the limit, the standard rate, the filing rhythm, where to register, the reasons, official source links with the day each was checked, and a not-tax-advice note. Covers the 27 EU states (One Stop Shop limit of 10,000 EUR), the United Kingdom and 14 US states; other places return not_covered with the covered list. It does not advise or cover sales to businesses, reduced rates, local taxes or a seller's own-country limit inside the EU, and it does not file or register anything.

Input Schema

Name	Required	Description
`currency`	No	Optional. The currency of yearly_sales. If it differs from the buyer place, the answer asks you to convert; it never guesses a rate.
`buyer_place`	Yes	Where the buyers are: an EU country code (FR, DE, EL for Greece), GB, or a US state written US-TX or by name (Texas). A bare two-letter code is a country, so CA is Canada and California is US-CA.
`product_kind`	Yes	physical_goods, digital_products (downloads such as e-books, music or apps) or saas (software used online).
`yearly_sales`	No	Optional. Sales to consumers in the last 12 months, in the money of the buyer place: EUR for the EU, GBP for the UK, USD for a US state. For an EU seller selling to another EU country, send the total to all other EU countries together. If the user gave no figure, leave this out (never send 0 as a stand-in): the answer then states the limit and asks for the figure.
`seller_country`	Yes	Where the seller is established: a two-letter country code such as DE, GB, US or VN, or the country name.
`yearly_transactions`	No	Optional. Number of sales in the last 12 months. A few US states also count sales, not only dollars.

Output Schema

Name	Required	Description
`rate`	No	standard_percent and what the rate leaves out.
`filing`	No	How often and by when returns are due.
`status`	Yes	ok, not_covered (place not in the table; see covered), currency_mismatch or invalid.
`covered`	No	With not_covered: the places the table covers.
`message`	No
`reasons`	No
`sources`	No	Official pages the answer comes from, each with the day it was checked.
`summary`	No
`threshold`	No	The registration limit that applies, with what is counted. Null when there is none.
`stale_data`	No	True when a row of the table is older than the age limit.
`stale_note`	No
`assumptions`	No
`buyer_place`	No
`data_checked`	No	The newest day any row of the table was checked.
`product_kind`	No
`yearly_sales`	No
`must_register`	No	Whether the seller has to register to collect VAT or sales tax for this place.
`register_with`	No
`not_tax_advice`	Yes
`over_threshold`	No
`seller_country`	No
`expected_currency`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare this as a safe, read-only, idempotent lookup, and the description adds substantial context beyond them: the exact return payload (must_register, limit, rate, filing rhythm, registration location, sources with check dates, not-tax-advice note), the coverage envelope (27 EU states, UK, 14 US states, not_covered otherwise), and the no-guessing behavior on currency conversion.

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?

It is long, but front-loaded with the decision context and free of filler; the coverage limits and exclusions are appended where an agent needs them. A single dense block rather than broken into scannable lines, which is the only cost.

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?

Despite an output schema existing (so return values needn't be described), the description goes further and names the coverage boundary, exclusions, currency-conversion behavior, and the not-tax-advice stance. Nothing an agent needs to call this correctly for a tax-jurisdiction lookup is missing.

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% and the schema already documents currency, buyer_place, product_kind, yearly_sales, and yearly_transactions in detail. The description restates the key parameter usage (pass the four core fields, add yearly_transactions for US states, omit sales when unknown) but adds little syntax or format information the schema lacks, so the baseline 3 applies.

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 ('check VAT or sales tax registration duty') and immediately distinguishes itself from siblings like tax_deadlines or estimate_federal_tax via the registration-duty framing and worked examples. An agent can tell exactly what question this answers.

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 concrete trigger examples ('I sell e-books from Germany...'), spells out what to pass, and explicitly enumerates exclusions: it does not advise, does not cover B2B sales, reduced rates, local taxes, or the EU seller's own-country limit, and does not file or register anything. The when/when-not boundary is unusually clear.

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

All Tax Numbers 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.