vies_checkValidate an EU VAT number via the European Commission VIES REST API, for example PL7740001454 or DE811569869. Reads a public registry and does not change it. Callable without an API key, within the daily per-IP limit.
| Name | Required | Description | Default |
|---|---|---|---|
| eu_vat | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / properties / eu_vat / maxLengthAdded value: +20Input schema / properties / eu_vat / minLengthAdded value: +4Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/destructive/openWorld, so the 'does not change the registry' line is largely redundant. The description does add genuinely new behavioral context beyond annotations: no API key required and a daily per-IP rate limit, both of which affect how an agent should call it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: what it does, safety profile, then access constraints. Front-loaded verb+resource and zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return values, and it covers access model and rate limits. It is slightly thin on edge behavior (VIES service downtime, invalid-format handling, non-EU input), but sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the parameter burden, and it does partially: the examples 'PL7740001454' and 'DE811569869' communicate the country-prefix-plus-digits format far better than minLength 4/maxLength 20 alone. It still doesn't state that the parameter is required or how malformed/invalid numbers are treated, so it is useful but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource (validate an EU VAT number) plus the backing service (European Commission VIES REST API) and concrete example inputs. It implicitly separates itself from nip_checksum (Polish checksum) and check_vat_whitelist, but never names those siblings, so the differentiation is left for the agent to infer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the statement that it reads a public registry without changing it. There is no explicit when-to-use/when-not guidance and no pointer to check_vat_whitelist or nip_checksum as alternatives, which matters given three VAT/identifier-checking siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.