VAT Validator MCP
Server Details
Validate EU, UK, AU VAT numbers for AI agents. EU ViDA e-invoicing compliance.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- OjasKord/vat-validator-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 6 of 6 tools scored.
Most tools have distinct purposes with clear boundaries: validate_vat for basic verification, analyse_vat_risk for AI fraud assessment, compare_invoice_details for invoice matching, get_vat_rates for tax rates, and batch_validate for bulk operations. However, validate_uk_vat overlaps significantly with validate_vat (which already handles UK VAT via auto-detection), creating potential confusion about when to use the specialized UK tool versus the general one.
Tool names follow a consistent verb_noun pattern with snake_case throughout (e.g., analyse_vat_risk, batch_validate, compare_invoice_details). The only minor deviation is validate_uk_vat, which includes a country code in the noun part, but this still fits the overall naming convention without breaking consistency.
With 6 tools, the server is well-scoped for VAT validation and fraud detection. Each tool serves a specific function in the workflow, from basic validation to advanced risk analysis and batch processing, making the count appropriate and manageable for the domain without being overwhelming or insufficient.
The tool set provides comprehensive coverage for VAT-related tasks: basic validation (validate_vat, validate_uk_vat), fraud detection (analyse_vat_risk, compare_invoice_details), bulk operations (batch_validate), and tax rate lookup (get_vat_rates). There are no obvious gaps; it supports the full lifecycle from onboarding to payment verification and compliance checks.
Available Tools
2 toolsget_vat_ratesAInspect
Call this AFTER validate_vat to confirm the current VAT rate applicable to the validated supplier's jurisdiction, or call standalone before your agent calculates invoice totals, applies tax rates, or generates VAT-inclusive pricing. Returns current standard, reduced, and zero VAT rates for all 27 EU member states and UK. VAT rates change without notice — your agent cannot rely on training data for current rates. Pass the country_code returned by validate_vat directly into this tool to complete the two-call invoice validation workflow. Returns machine-readable JSON — no parsing needed. Omit country_code to get all countries.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | No | ISO 2-letter code e.g. DE, FR, GB. Omit for all countries. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and provides substantial behavioral context: it discloses the return format (standard and reduced rates), geographic scope (27 EU states, UK, Australia), legal disclaimer, and usage limits (free tier: 20 calls/month, no API key). It doesn't mention error handling or authentication requirements.
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?
Well-structured and front-loaded with purpose and usage, though the legal notice and free tier details could be slightly more integrated. Every sentence adds value, but minor redundancy exists between 'calculate tax amount' and 'use before...pricing calculation.'
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?
Given no annotations and no output schema, the description does well by explaining return values, scope, and usage constraints. However, it lacks details on error cases, response format structure, or how 'all reduced rates' are presented, leaving some gaps for a tool with legal implications.
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 description coverage is 100% (parameter well-documented in schema), so baseline is 3. The description adds no additional parameter semantics beyond what's in the schema, though it implies the country_code parameter's purpose through context.
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 clearly states the tool's purpose: 'calculate the correct tax amount' with specific resources (EU, UK, Australian businesses) and transaction contexts (B2B/B2C). It distinguishes from siblings by focusing on rate retrieval rather than validation, analysis, or comparison.
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?
Explicit guidance is provided: 'Call this tool when your agent needs to calculate...' with specific timing ('before generating any quote, invoice, or pricing calculation') and context ('cross-border sales'). It clearly indicates when to use this tool versus when to use alternatives for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_vatAInspect
Call this BEFORE your agent approves any supplier invoice, onboards a new EU/UK/AU vendor, or processes any cross-border payment. Validates VAT numbers against EU VIES (all 27 member states), UK HMRC VAT API, and AU ABR — auto-detects jurisdiction from the number prefix. Returns valid/invalid status, registered company name, address, and AI-powered fraud risk score 0-100 with PROCEED/VERIFY_MANUALLY/HOLD verdict. An invalid or deregistered VAT number on an approved invoice creates unrecoverable tax liability. After calling this tool, call get_vat_rates with the detected country_code to confirm the applicable rate for invoice calculation — both tools together complete a full invoice validation workflow in two calls.
| Name | Required | Description | Default |
|---|---|---|---|
| vat_number | Yes | VAT number with country prefix. EU: DE123456789. UK: GB123456789. AU: ABN12345678901. | |
| invoice_amount | No | Invoice amount in local currency — used in fraud risk weighting. | |
| invoice_company_name | No | Company name as it appears on the invoice — if provided, cross-checks against registry and flags mismatches. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it mentions auto-detection of country prefixes, legal notice that results are informational only, free tier limits (20 calls/month, no API key), and terms link. However, it doesn't detail error handling or response format, leaving some gaps.
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 appropriately sized and front-loaded with key usage scenarios, followed by operational details and legal notices. Some sentences could be more concise (e.g., the list of use cases is verbose), but overall it's well-structured with zero waste.
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?
Given the tool's complexity (validation with legal implications), no annotations, and no output schema, the description does a good job covering usage, behavioral traits, and limitations. However, it lacks details on response format or error cases, which would enhance completeness for an agent.
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 description coverage is 100%, so the schema already documents the single parameter. The description adds minimal value beyond the schema by mentioning examples (DE, GB, FR prefixes) and that VAT numbers are for EU, UK, or Australian businesses, but doesn't provide additional syntax or format details. Baseline 3 is appropriate as the schema does the heavy lifting.
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 clearly states the tool's purpose: 'confirm a business is real and legally registered' using VAT numbers. It specifies the verb ('confirm') and resource ('business'), and distinguishes from siblings by focusing on validation rather than risk analysis, batch processing, rate lookup, or UK-specific 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?
Explicit guidance is provided on when to use: 'before onboarding a new supplier, customer, or contractor, before signing any B2B contract, before processing or issuing any invoice, before approving a vendor in procurement, or before enriching a CRM record.' It also specifies when to use for fraud detection and mentions auto-detection of country prefixes, giving clear context for application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!