Jithox

Check EU VAT numbers

check_vat_list

Read-only

Check up to 20 rows of EU VAT numbers in EU VIES, row for row; a malformed or non-EU row is judged locally (not_covered, never invalid). UNKNOWN COSTS NOTHING, and the balance must cover the whole call (20 credits for 20 rows) before it runs. Optional requesterVatId adds a consultation number registered to you; a requester VIES refuses costs nothing. 1 credit (EUR 0.01) per answered row; needs a bearer token.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`rows`	Yes	The list: 1 to 20 rows per call.
`requesterVatId`	No	Your OWN EU VAT number with country prefix (e.g. BE0403170701). Never stored.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`kind`	Yes
`billing`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 2, 2026
- changedInput schema / properties / rows / maxItems
```
Previous value: -200New value: +20
```

Changed8 schema fields changedSep 25, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

changedInput schema / properties / requesterVatId / description

Previous value: -"Your OWN EU VAT number with country prefix (e.g. BE0403170701). When given, the European Commission issues a consultation number per answered row, registered to you. Optional. Never stored."New value: +"Your OWN EU VAT number with country prefix (e.g. BE0403170701). Never stored."

changedInput schema / properties / rows / description

Previous value: -"The list: 1 to 20 rows per call. A longer list is refused with the limit named — send it in parts of 20."New value: +"The list: 1 to 20 rows per call."

changedInput schema / properties / rows / items / properties / reference / description

Previous value: -"Your own label for the row — a customer number, a name. Optional, at most 80 characters. It is echoed back, never interpreted."New value: +"Your own label for the row — a customer number, a name. It is echoed back, never interpreted."

removedInput schema / properties / rows / items / properties / reference / maxLength
```
Removed value: -200
```

changedInput schema / properties / rows / items / properties / vatId / description

Previous value: -"The VAT number as written, WITH its two-letter country prefix, e.g. \"BE0400378485\" or \"NL 8558.76.323.B01\". Spaces, dots and dashes are fine."New value: +"The VAT number as written, WITH its two-letter country prefix, e.g. \"BE0400378485\" or \"NL 8558.76.323.B01\"."

removedInput schema / properties / rows / items / properties / vatId / maxLength
```
Removed value: -200
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "billing": {
+      "type": "object"
+    },
+    "data": {
+      "type": "object"
+    },
+    "kind": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "kind",
+    "data",
+    "billing"
+  ],
+  "type": "object"
+}

First observedSep 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations: UNKNOWN results cost nothing, the balance must cover the whole call upfront (20 credits for 20 rows), a refused requester VIES costs nothing, billing is 1 credit per answered row, and a bearer token is required. This is exactly the cost/auth/failure-mode context an agent needs before calling.

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-loads the operation, then cost and auth constraints, with no filler sentences. The prose is very dense and crams pricing, auth, and requester behavior into a few long clauses, which costs a little readability but every sentence earns its place.

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 an output schema present, return values need no explanation; the description still covers cost model, batch limits, auth, and the not_covered verdict rule. Nothing material is missing for an agent to call this 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 the baseline is 3, but the description adds real meaning: requesterVatId attaches a consultation number registered to the requester, and a requester the VIES refuses is free. The row-level `counted-per-answered-row` semantics also clarify how the array size maps to cost.

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 up to 20 rows of EU VAT numbers in EU VIES, row for row') with the batch scope and the upstream registry named. An agent can immediately distinguish this from siblings like verify_iban or lookup_peppol_participant.

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?

Explains the key behavioral rule for use — malformed or non-EU rows are judged locally as `not_covered` and never `invalid` — and when to pass requesterVatId (to get a consultation number registered to you). It does not explicitly route the agent away from or toward sibling tools, so it stops short of full when/when-not guidance.

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

All Jithox 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.