Skip to main content
Glama

vat_check

Verify any EU VAT number through VIES to confirm the company is active and retrieve its official registered name and address.

Instructions

Verify an EU VAT number against VIES and get the officially registered name and address back. Confirms a company exists and is active. Cannot be searched by name — you need the number.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countryNoCountry code, if not part of vat_number
vat_numberYesWith country code, e.g. NL123456789B01

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.6.1

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool performs a VIES lookup, returns official registration data, and confirms existence/active status. It does not mention potential external-service availability issues, invalid-number errors, or that this is a read-only operation, though the verb 'Verify' strongly implies it.

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

Conciseness5/5

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

Three short sentences, each earning its place. The core action and result are front-loaded, and the constraint is stated at the end without repetition or fluff.

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?

Given no output schema and no annotations, the description reasonably explains the return value (official name and address), the verification semantics, and the prerequisite input. It could go further on error cases or the optional country parameter, but the schema already covers the parameters and the core behavior is adequately specified.

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%, so the baseline is 3. The description adds the general constraint that a number is required and name search is impossible, but it does not add detail about the optional country parameter or the expected combined format beyond what the schema already states.

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 ('Verify') and resource ('EU VAT number against VIES'), and clearly says what is returned: officially registered name and address. It also differentiates from siblings by emphasizing this is a number-based verification, not a search tool.

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?

Provides clear usage context: the tool requires a VAT number and cannot be used to search by name. It does not explicitly name sibling alternatives like eu_company_search, but the 'cannot be searched by name' constraint is a practical when-not that helps an agent select this tool.

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