Skip to main content
Glama

euroref — European government reference data

invoice_check

Read-onlyIdempotent

PAID ($0.60). Check an invoice in one call: is the VAT right (place of supply, rate, expected amount vs vat_charged), is it overdue and how much statutory late interest is owed, and do seller/buyer tax IDs pass the official format check. Seller countries here: AT, BE, BG, CH, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HR, HU, IE, IS, IT, LT, LU, LV, MT, NL, NO, PL, PT, RO, RS, SE, SI, SK, TR. Send due_date, or invoice_date with terms_days. Anything we cannot answer in full is refused free (coverage_gap, no_charge). Shares the 3 free calls per IP per day with the answer tools. Pass api_key if you have one (card checkout at /pricing); otherwise the result is the x402 payment requirement. Optional receipt (boolean, default false): on a paid success, include an Ed25519 answer receipt at no extra USDC. An answer receipt is not a series certified extract (GET /v1/certified/{country}/{series} is $0.10 and is not an MCP tool) and is not legal advice. Verify with verify_answer_receipt against /certified/public-key.

Input Schema

NameRequiredDescriptionDefault
as_ofNoYYYY-MM-DD; default today
amountYesInvoice amount, local currency
api_keyNoAPI key (bypasses x402; metered for invoicing)
receiptNoDefault false. When true, a paid success includes an Ed25519 answer receipt (kind answer_receipt) at no extra USDC. Unpaid 402 and free refusals do not include one. Not a series certified extract (GET /v1/certified/{country}/{series} at $0.10; that SKU is not an MCP tool).
due_dateNoYYYY-MM-DD contractual due date
amount_isNoDefault net
buyer_typeNo
terms_daysNoAgreed payment term in days
vat_chargedNoVAT amount on the invoice, to be checked
buyer_tax_idNoNeeds buyer_country
invoice_dateNoYYYY-MM-DD; with terms_days instead of due_date
buyer_countryNoISO code; omit for a domestic invoice
seller_tax_idNo
seller_countryYesISO country code of the seller

Output Schema

NameRequiredDescriptionDefault
jobNo
errorNoPresent on a free refusal or error; no charge
statusNo
evidenceNo
no_chargeNo
price_usdNo
disclaimerNo
how_to_payNo
bind_seriesNo
explanationNo
x_next_bindNo
http_endpointNo
payment_requiredNotrue when the call needs payment; how_to_pay explains x402 or card

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

The description provides deep behavioral context beyond annotations and schema, including specific business logic (list of supported seller countries), pricing model details ('free calls', 'x402 payment requirement'), and technical constraints (detailed receipt format and linked external SKU pricing).

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

Conciseness2/5

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

The definition is extremely verbose and dense. While this level of detail is operationally necessary for this complex tool, it violates the principle of conciseness and requires a high cognitive load to parse.

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 its length, the definition is maximally complete. It covers what the tool does, what it can't do, how it's priced, what inputs it requires (including conditional ones), and what specific external tools it relates to, leaving virtually no ambiguity for the AI agent.

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

Parameters5/5

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

Although schema coverage is high (86%), the description clarifies critical operational semantics not explicit in the schema, such as the interchangeable use of `due_date` or `invoice_date` with `terms_days`, and the function of `api_key`.

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 clearly defines the tool's multi-faceted purpose, which is to conduct a holistic invoice check covering VAT, overdue status, statutory late interest, and tax ID format validation. This comprehensive scope immediately distinguishes it from narrower sibling tools like `compute_vat` or `validate_tax_id`.

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?

The tool sets clear boundaries on its usage, specifically stating that unsupported checks will result in a 'coverage_gap' refusal free. It also provides context on shared resource limits (3 free calls per IP per day) and operational prerequisites like the API key requirement.

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.

Resources