Loading ToolBench
MCP server for EuroValidate — validate EU VAT numbers (VIES), IBANs, EORI customs numbers and look up company data from LLM agents
EuroValidate has 7 well-named, read-only tools with clear docstrings and basic input schemas. Naming follows verb_noun convention (validate_*, lookup_*, get_*, check_*). All tools have descriptions (avg ~150 chars, within 10 - 1024 baseline). However, schemas lack formal constraints (no enums, min/max, patterns), parameter descriptions are minimal (avg ~40 chars vs 72 baseline), and output schemas are completely undocumented. Error handling is absent, the _get() helper returns raw API responses without recovery guidance. No tool annotations (readOnlyHint, idempotentHint). Composition is sound: each tool has one responsibility, and tools chain naturally (e.g., validate_vat → lookup_company_by_vat). Missing: pagination support, result limits, and structured error messages.
Check live health of upstream government services (VIES per-country, EORI, HMRC, GLEIF). Public endpoint — works without an API key. Use it to explain why a validation returned reduced confidence (e.g. Germany's VIES endpoint down).
Get current VAT rates (standard/reduced) for an EU country by ISO 3166-1 alpha-2 code.
Look up company data (legal name, address, status) by LEI via GLEIF.
Look up company data by VAT number (GLEIF cross-reference). Useful as a fallback for German/Spanish VAT numbers where VIES returns no company name/address by law.
Validate an EORI customs number (EU via EC, GB via HMRC, XI for Northern Ireland).
Validate an IBAN (offline MOD-97 checksum) and resolve the bank name and BIC. Covers all SEPA countries. Accepts the IBAN with or without spaces.
Output schemas completely undocumented. LLMs cannot predict response structure, forcing them to guess which fields exist and how to chain tools. All 7 tools return raw API responses without documented field names, types, or availability.
Input schemas lack formal constraints. No enums for country_code (should be ISO 3166-1 alpha-2), no min/max for numeric inputs, no regex patterns. LLMs can pass invalid values like country_code='INVALID' without validation.
No error handling or recovery guidance. _get() returns raw API responses (including 401 errors with generic 'Missing or invalid API key' message). LLMs receive no actionable next steps for failures like 'VAT number not found' or 'VIES service down'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Validate an EU or UK VAT number via VIES/HMRC. Returns validity, registered company name and address where the member state exposes them (Germany and Spain never do), a confidence level, and the upstream source. Accepts the number with or without country prefix (e.g. "DE123456789" or "123456789" + country_code="DE"). Greece: EL or GR both work.
Parameter descriptions are minimal (avg ~40 chars vs 72 baseline). E.g., 'The VAT number to validate, with or without country prefix' lacks format guidance. No mention of accepted formats (DE123456789 vs 123456789), Greece's EL/GR ambiguity, or what happens when both vat_number and country_code are provided.
No tool annotations. All tools are read-only and idempotent, but lack readOnlyHint and idempotentHint annotations. LLMs cannot distinguish safe tools from destructive ones without explicit hints.