VAT Validator MCP

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

With no annotations provided, the description carries the full burden and does so well by disclosing key behavioral traits: it describes the AI-powered analysis process, lists specific fraud signals caught (e.g., name mismatches, shell company indicators), mentions rate limits ('Free tier: first 20 calls/month'), and includes legal disclaimers. It does not contradict any annotations.

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, starting with the core purpose and usage guidelines. However, it includes some verbose elements like the full legal notice and URL, which slightly reduce efficiency, though most sentences add value.

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 (AI analysis, fraud detection) and lack of annotations and output schema, the description is largely complete: it explains the purpose, usage, behavioral traits, and output format ('CLEAR/REVIEW/BLOCK recommendation with specific reasons'). It could briefly mention error handling or response structure, but it covers essential context well.

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 all parameters thoroughly. The description adds minimal parameter semantics beyond the schema, such as implying context for 'invoice_amount' and 'invoice_company_name' in fraud detection, but it does not provide additional syntax or format details. This meets the baseline for high schema coverage.

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 performs an 'AI-powered fraud risk assessment' that 'synthesises registry data with transaction context to detect fraud signals,' distinguishing it from simple validation tools like validate_vat. It specifies the verb (assess risk) and resource (VAT-related transactions) with explicit differentiation from siblings.

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 explicit usage instructions: 'Call this tool after validate_vat returns a result' and 'Use before approving any payment or signing any contract, especially with first-time counterparties.' It also implies alternatives by noting this is not a 'simple database lookup,' contrasting with validation siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds context beyond basic functionality: it specifies rate limits ('max 10 VAT numbers per call'), legal disclaimers ('Results are informational only, not tax advice'), and prerequisites ('Paid API key required'). However, it lacks details on error handling, response format, or authentication specifics, 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, starting with the core use case. Every sentence adds value: the first outlines purpose and scenarios, the second specifies constraints and frequency, and the third covers legal and API requirements. It could be slightly more concise by merging some clauses, but overall it's efficient with minimal 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 complexity (batch validation tool with no annotations and no output schema), the description is fairly complete. It covers purpose, usage guidelines, constraints, legal notes, and prerequisites. However, it lacks details on output format, error cases, or specific behavioral traits like idempotency or side effects, which could be important for an agent invoking this tool.

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 parameter (vat_numbers as an array of strings with max 10 items). The description adds marginal value by reiterating the max limit and specifying country prefixes (EU, UK, Australian), but doesn't provide additional syntax or format details beyond what the schema implies. Baseline 3 is appropriate when 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 with specific verbs ('verify multiple businesses at once') and resources ('businesses'), distinguishing it from siblings by emphasizing batch processing for multiple VAT numbers. It explicitly mentions the scope (EU, UK, Australian businesses) and capacity (up to 10 VAT numbers), which sets it apart from single-validation tools like validate_vat or validate_uk_vat.

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 explicit guidance on when to use this tool, listing specific scenarios like 'supplier onboarding batches, auditing your entire vendor database, running monthly compliance checks, or cleaning a CRM import.' It also advises 'Run this monthly on all active vendors - registrations can lapse,' giving clear context and frequency. No explicit alternatives are named, but the batch nature implicitly distinguishes it from single-validation siblings.

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

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 behavioral traits: it uses AI for comparison, flags discrepancies for fraud detection, includes a legal disclaimer about informational-only results, and specifies free tier limits (20 calls/month, no API key). It doesn't mention rate limits beyond the free tier or error handling.

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 the core purpose and usage context. The legal notice and terms reference are necessary but slightly lengthen the text. Most sentences earn their place by adding value beyond structured fields.

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 complexity (fraud detection tool with AI comparison), no annotations, and no output schema, the description does well by explaining the tool's purpose, usage context, behavioral traits, and limitations. It could benefit from more detail about output format or error cases, but covers the essential context for a tool with this function.

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 all parameters. The description adds context by explaining what the parameters represent (invoice details to compare against registry data) and that validation_result should come from validate_vat or validate_uk_vat tools, but doesn't provide additional syntax or format details beyond what the schema provides.

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: to verify supplier details on an invoice against government registry records using AI, specifically comparing company name, address, and VAT number. It distinguishes itself from siblings by focusing on invoice verification rather than validation, risk analysis, or batch operations.

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 explicitly states when to use this tool: 'when your agent has received an invoice and needs to verify the supplier details' and 'Use before approving payment on any invoice from a supplier you have not previously verified.' It also distinguishes from siblings by specifying it's for invoice verification rather than general VAT validation.

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

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.

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 behavioral traits: it returns specific data (company name, address, HMRC number), includes a legal disclaimer about informational use only, and states rate limits (20 free calls/month) and authentication requirements (no API key needed). It doesn't mention error handling or response formats.

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 efficiently structured with purpose, usage guidelines, return values, and operational details in logical order. While slightly dense due to legal and rate limit information, every sentence adds value without redundancy.

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 tool with no annotations and no output schema, the description provides strong contextual completeness: it explains the tool's purpose, when to use it, what it returns, legal constraints, and operational limits. The main gap is lack of output format details, but return values are described semantically.

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 baseline is 3. The description doesn't add parameter-specific details beyond what the schema already states about the VAT number format, but it contextualizes why this parameter matters for validation purposes.

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: validating UK VAT numbers to confirm HMRC registration. It specifies the exact use cases (onboarding, paying invoices, signing contracts) and distinguishes it from sibling tools by focusing on UK-specific validation rather than risk analysis, batch processing, rate lookup, or generic 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 this tool: 'when your agent is dealing with a UK business and needs to confirm they are genuinely registered with HMRC before onboarding them, paying an invoice, or signing a contract.' It also mentions verifying invoice name matches as a fraud check, 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.

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.