Skip to main content
Glama
Jazib-but

VAT Validation MCP Server

by Jazib-but

check_vat_test_service

Test integration with the official EU VIES service using predefined VAT numbers to verify validation workflows.

Instructions

Test VIES service integration with test VAT numbers / Testovať integráciu so službou VIES

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countryCodeYesEU member state code / Kód členského štátu EÚ
vatNumberYesTest VAT number: 100 (valid), 200 (invalid) / Testové IČ DPH: 100 (platné), 200 (neplatné)

Implementation Reference

  • MCP tool handler for 'check_vat_test_service': parses input with schema, calls ViesApiClient method, formats response as text
    case 'check_vat_test_service': {
      const params = checkVatTestSchema.parse(args);
      const result = await this.viesClient.checkVatTestService(params);
      
      const responseText = this.formatVatValidationResult(result, true);
      
      return {
        content: [
          {
            type: 'text',
            text: responseText,
          },
        ],
      };
    }
  • src/index.ts:57-75 (registration)
    Registration of 'check_vat_test_service' tool in the ListTools response, including input schema definition
      name: 'check_vat_test_service',
      description: 'Test VIES service integration with test VAT numbers / Testovať integráciu so službou VIES',
      inputSchema: {
        type: 'object',
        properties: {
          countryCode: {
            type: 'string',
            enum: [...EU_MEMBER_STATES],
            description: 'EU member state code / Kód členského štátu EÚ',
          },
          vatNumber: {
            type: 'string',
            enum: ['100', '200'],
            description: 'Test VAT number: 100 (valid), 200 (invalid) / Testové IČ DPH: 100 (platné), 200 (neplatné)',
          },
        },
        required: ['countryCode', 'vatNumber'],
      },
    },
  • Zod input validation schema used for parsing tool arguments: checkVatTestSchema
    export const checkVatTestSchema = z.object({
      countryCode: z.enum(EU_MEMBER_STATES),
      vatNumber: z.enum(['100', '200'], {
        errorMap: () => ({ message: 'Test VAT number must be 100 (valid) or 200 (invalid)' })
      }),
    });
  • ViesApiClient method implementing the HTTP POST to VIES '/check-vat-test-service' endpoint, parses response and maps to VatNumberInfo
    async checkVatTestService(params: CheckVatTestParams): Promise<VatNumberInfo> {
      try {
        const response = await this.client.post('/check-vat-test-service', {
          countryCode: params.countryCode,
          vatNumber: params.vatNumber,
        });
    
        const validatedData = vatValidationResponseSchema.parse(response.data);
    
        return {
          countryCode: validatedData.countryCode || params.countryCode,
          vatNumber: validatedData.vatNumber || params.vatNumber,
          isValid: validatedData.valid,
          companyName: validatedData.name,
          companyAddress: validatedData.address,
          requestDate: validatedData.requestDate,
          wasPreprocessed: false, // Test service doesn't preprocess
        };
      } catch (error) {
        if (error instanceof ViesApiError) {
          try {
            const errorData = errorResponseSchema.parse(error.response);
            throw new Error(`VIES test service failed: ${errorData.error}${errorData.message ? ` - ${errorData.message}` : ''}`);
          } catch {
            throw error;
          }
        }
        throw error;
      }
    }
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'test VAT numbers' which implies this is for testing/diagnostic purposes rather than production validation, but doesn't specify what the tool actually does (e.g., returns validation results, service status, or test responses). No information about rate limits, authentication needs, or response format is provided.

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

Conciseness3/5

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

The bilingual format (English/Slovak) creates redundancy that doesn't add value for an AI agent. While the core information is present, the duplicate phrasing wastes space. The description is front-loaded with the essential purpose but could be more efficiently structured as a single clear statement.

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 diagnostic/testing tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (test results, service status, validation outcomes) or how to interpret results. Given the sibling tools suggest this is part of a VAT validation system, more context about this tool's specific role in testing versus production use is needed.

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

Parameters4/5

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

The schema has 100% description coverage with clear enum values and explanations, so the baseline is 3. The description adds marginal value by emphasizing these are 'test' VAT numbers, reinforcing that this is for testing purposes rather than real validation. However, it doesn't provide additional context beyond what's already well-documented in the schema.

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

Purpose3/5

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

The description states the tool tests VIES service integration with test VAT numbers, which is a clear purpose. However, it doesn't distinguish itself from sibling tools like 'check_vat_number' or 'check_vies_status' - it's unclear how this 'test service' differs from regular VAT checking operations. The bilingual phrasing adds some noise but doesn't obscure the core function.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. There's no mention of when this test service should be used instead of 'check_vat_number' or 'check_vies_status', nor any indication of prerequisites or appropriate contexts. The agent must infer usage from the name and parameters alone.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jazib-but/check-vat-vies-mcp-Jazib'

If you have feedback or need assistance with the MCP directory API, please join our Discord server