FREE, no payment required: validate an EU VAT ID against the live EU VIES register and get the registered name and address where the member state publishes them. Free entry tool - the paid tools in this server add sanctions screening, counterparty due diligence, VAT rules and e-invoice validation.
| Name | Required | Description | Default |
|---|---|---|---|
| vat_id | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds valuable behavioral context: the tool is free, performs a live check against the VIES register, and returns name/address only when the member state publishes them. This conditional disclosure is important. It does not mention error handling or rate limits, but for a simple validation tool the key behaviors are disclosed.
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?
The description is extremely concise and front-loaded with the most important fact ('FREE, no payment required'). It uses two sentences to convey purpose, data availability, and differentiation from paid siblings. Every clause adds value; there is zero fluff.
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?
For a single-parameter validation tool with no output schema, the description covers the essential context: what the tool does, its cost, the live nature of the data, and the conditional availability of name/address. It also positions itself among siblings. It does not describe the response structure or error behavior, but these are less critical for a simple validate operation, so completeness is high.
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?
The schema only provides the parameter title 'Vat Id' with no description, and schema coverage is 0%. The description adds the semantic context 'EU VAT ID', which makes clear the parameter is a European VAT identification number. However, it does not specify format requirements (e.g., country prefix) or provide examples, so the agent must rely on general knowledge. The description adds some meaning but does not fully compensate for the lack of schema documentation.
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 states a specific verb ('validate') and direct object ('an EU VAT ID against the live EU VIES register'), and also specifies the result (get registered name and address). It clearly distinguishes itself from sibling tools by positioning as the free entry tool and listing what paid tools add (sanctions screening, counterparty due diligence, VAT rules, e-invoice validation).
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?
The description provides clear context for when to use this tool (to validate an EU VAT ID and retrieve published name/address) and differentiates it from paid alternatives by explicitly listing what the paid tools cover. It does not explicitly say 'use this instead of X' or provide a strict when-not-to-use, but the positioning is clear enough for an agent to infer the appropriate use case.
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.
Many tools are clearly separate (validate_vat, validate_iban, token_status, tx_status), but several overlap by combining the same core checks: check_counterparty_eu, must_verify_before_pay, tx_preflight, and invoice_to_pay_dossier_eu all screen sanctions and/or do VIES/IBAN checks. The descriptions help, but the boundaries between a KYB check, a payment gate, and a transaction preflight are subtle enough that agents can easily pick the wrong one.
Names are uniformly lowercase snake_case, and patterns like validate_*, prepare_*, and *_eu give some predictability. However, the verb style is inconsistent: some tools are verb-led (read_url, screen_sanctions_eu, lookup_company_eu), others are noun-led (market_data, token_status, agentllm_micro), and paid/prepare pairs do not share a consistent naming scheme.
24 tools is at the upper edge of what is reasonable, and the server mixes several unrelated concerns: EU VAT/invoice compliance, sanctions/KYB, US import readiness, AI disclosure/LLM inference, market data, URL reading, and transaction status. The core comply-to-pay workflow is well represented, but the extra domains make the tool list feel heavier and less like a single coherent service.
The EU invoice/payment compliance flow is fairly complete: e-invoice validation, VAT rules, VIES, IBAN, sanctions, transaction preflight, payment decisions, bookkeeping statements, and receipt verification are all covered. Obvious gaps remain for such a broadly named server: no export/other product compliance, no broader EU regulatory coverage, and the key invoice guard explicitly does not cover duplicate-ledger detection, internal approval, or delivery checks.
