Skip to main content
Glama
revclamp

RevClamp MCP Server

Official

revclamp_validate_eu_vat_vies

Normalize EU B2B VAT IDs and validate cross-border reverse-charge eligibility, including optional simulated VIES states for testing.

Instructions

Normalizes 27 EU member states + Northern Ireland (XI) B2B VAT IDs (auto-converting Greece GR -> EL) and checks cross-border reverse-charge format eligibility locally (or simulates VIES states when demo: true).

Input Schema

NameRequiredDescriptionDefault
demoNoRequired when using simulated viesMode values (VALID, INVALID, MS_UNAVAILABLE, GLOBAL_MAX_CONCURRENT_REQ) in local mode.
viesModeNoFORMAT_ONLY
buyerVatIdYes
sellerCountryNoDE
consultationNumberNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.20.7
    • addedInput schema / properties / consultationNumber
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / sellerCountry / default
      Added value: +"DE"
    • changedInput schema / required
      Previous value: -[
      -  "sellerCountry",
      -  "buyerVatId"
      -]New value: +[
      +  "buyerVatId"
      +]
  2. Changed3 schema fields changedv1.20.2
    • addedInput schema / properties / demo
      Added value: +{
      +  "default": false,
      +  "description": "Required when using simulated viesMode values (VALID, INVALID, MS_UNAVAILABLE, GLOBAL_MAX_CONCURRENT_REQ) in local mode.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / viesMode / default
      Previous value: -"VALID"New value: +"FORMAT_ONLY"
    • changedInput schema / properties / viesMode / enum
      Previous value: -[
      -  "VALID",
      -  "INVALID",
      -  "MS_UNAVAILABLE",
      -  "GLOBAL_MAX_CONCURRENT_REQ",
      -  "LIVE"
      -]New value: +[
      +  "FORMAT_ONLY",
      +  "VALID",
      +  "INVALID",
      +  "MS_UNAVAILABLE",
      +  "GLOBAL_MAX_CONCURRENT_REQ",
      +  "LIVE"
      +]
  3. Changed7 schema fields changedv1.20.1
    • removedInput schema / properties / buyerVatId / description
      Removed value: -"Required buyer EU or Northern Ireland VAT registration number to normalize and validate (e.g. 'DE123456789', 'GR123456789', 'NL123456789B01', 'XI123456789', max 40 chars)."
    • removedInput schema / properties / consultationNumber
      Removed value: -{
      -  "description": "Optional VIES requester consultation reference number (e.g. 'WAPIAAAAW998877', max 64 chars) to attach to deterministic 'VALID' mode tax audit records.",
      -  "type": "string"
      -}
    • removedInput schema / properties / sellerCountry / description
      Removed value: -"Two-letter EU-27 or XI member state prefix of the merchant's dispatch warehouse (e.g. 'DE', 'NL', 'FR', 'EL', 'XI'; 'GR' is automatically normalized to 'EL'; default: 'DE')."
    • addedInput schema / properties / viesMode / default
      Added value: +"VALID"
    • removedInput schema / properties / viesMode / description
      Removed value: -"VIES evaluation mode: 'VALID' (deterministic active VAT simulation, default), 'INVALID' (deterministic rejected VAT simulation), 'MS_UNAVAILABLE' (deterministic member-state outage circuit-breaker simulation), or 'LIVE' (real-time European Commission VIES lookup)."
    • changedInput schema / properties / viesMode / enum
      Previous value: -[
      -  "VALID",
      -  "INVALID",
      -  "MS_UNAVAILABLE",
      -  "LIVE"
      -]New value: +[
      +  "VALID",
      +  "INVALID",
      +  "MS_UNAVAILABLE",
      +  "GLOBAL_MAX_CONCURRENT_REQ",
      +  "LIVE"
      +]
    • changedInput schema / required
      Previous value: -[
      -  "buyerVatId"
      -]New value: +[
      +  "sellerCountry",
      +  "buyerVatId"
      +]
  4. First observedv1.20.0

TDQS

B3.1/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 burden, and it does disclose the key behavioral trait: validation happens locally by default, and demo:true yields simulated VIES states rather than real ones. It does not explain what LIVE mode does differently (network call, VIES availability, concurrency limits like GLOBAL_MAX_CONCURRENT_REQ), nor any rate limiting or error behavior.

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?

A single dense sentence with the normalization capability front-loaded ahead of the mode caveat; no filler. The stacked parentheticals make it slightly harder to scan than a two-sentence split would, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with no annotations and no output schema, the description leaves critical gaps: it never says what the call returns (validity verdict, normalized ID, error states), and the viesMode/sellerCountry/consultationNumber parameters are undocumented anywhere. An agent could invoke it but could not interpret the result or pick a mode confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20% across 5 parameters, so the description must compensate and largely does not. It clarifies buyerVatId normalization (GR->EL) and the demo flag, but viesMode — the central control with six enum values including the default FORMAT_ONLY and the LIVE path — is never explained, nor are sellerCountry or consultationNumber.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names concrete verbs and a precise resource: it normalizes EU/XI B2B VAT IDs and checks reverse-charge format eligibility. The scope (27 member states plus Northern Ireland, GR->EL conversion) is specific enough to distinguish it from any sibling, none of which touch VAT. It stops short of 5 only because 'reverse-charge format eligibility' is domain jargon that an uninitiated agent must infer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The parenthetical '(or simulates VIES states when demo: true)' implies a mode-selection rule, but the agent must infer when to prefer local format checking versus LIVE/VIES validation. There is no explicit when-to-use, when-not-to-use, or alternative-tool routing. Usage is implied rather than stated.

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