Skip to main content
Glama

VAT / GST / IVA rates by country

get_vat_rates

Use this when you need the standard and reduced VAT, GST or IVA rates of a country for invoicing, pricing or tax estimates. Covers the EU-27 (from the European Commission's Taxes in Europe Database) plus AR, AU, CA, CL, CO, GB, MX, PE from their national tax laws, with super-reduced and parking rates, zero-rating, regional rates (e.g. Canadian HST by province, Mexican border region) and the date the latest rate took effect. Offline, versioned table (tableVersion), reviewed every six months. Other countries return UNSUPPORTED_COUNTRY without charge.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_vat_rates"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoOptional invoice/supply date (YYYY-MM-DD). The answer says whether the current table already applied on that date (`validForDate`).
itemsNoBatch mode: up to 500 items, each with the same fields as a single call. Omit when validating a single value through the top-level fields.
amountNoOptional net amount; when given, the standard-rate VAT and gross amount are computed (2 decimals).
countryNoISO 3166-1 alpha-2 country code, e.g. "DE", "ES", "MX", "GB". Greece is "EL" (also accepts "GR"); "UK" is accepted for "GB".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description does the heavy lifting: it discloses the data provenance (European Commission TED, national tax laws), that the table is offline and versioned (`tableVersion`) and reviewed every six months, that regional/super-reduced/zero rates are included, and that unsupported countries return UNSUPPORTED_COUNTRY without charge. It stops short of stating rate limits or the full response shape.

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?

The usage trigger comes first, followed by coverage, then provenance and error behavior — a sensible front-loaded order. It is a dense single paragraph with a few closely related clauses, but nearly every clause adds a distinct fact.

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?

No output schema and no annotations, so the description must carry behavioral context — and it does, covering provenance, versioning, freshness, error behavior, and the meaning of `validForDate`. It does not enumerate the full return payload (e.g. rate fields, gross amount), leaving a small gap.

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, but the description adds meaning the schema cannot: it enumerates which countries `country` accepts and implies the batch/regional behavior. It does not restate per-field mechanics (date, amount), which the schema already covers well.

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 (retrieve standard and reduced VAT, GST, IVA rates) and resource, plus the exact jurisdiction coverage. An agent can distinguish it from validate_vat_eu, which validates a number rather than returning rates, without needing the schemas.

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

Usage Guidelines4/5

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

Explicitly names the triggering use cases (invoicing, pricing, tax estimates) and the supported country set, and states the unsupported-country behavior. It does not, however, explicitly route to or exclude any sibling tool by name.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.