Building an MCP Server for VAT Validation: Why It’s Two Tools, Not One

When asking an AI whether a VAT number like IE6388047V is valid, there are two distinct methods to confirm it. The first is instant and free, where the algorithm checks if the string follows the correct format for an Irish VAT number, such as the prefix, length, and character pattern. The second method is slower and requires payment: it involves contacting the EU's VIES registry to verify that the number is indeed registered and retrieve the associated company name.

These two approaches answer different questions, even when applied to the same VAT number. The vatnode-mcp is the official MCP server for vatnode, a VAT-validation software as a service (SaaS), and its development required the decision of whether to treat those two methods as one tool or two separate tools. I built it as two: check_vat_format and validate_vat_number.

This split is a question of API design that MCP makes particularly evident: every tool competes for inclusion in the model's decision-making process for which tool to call next. The tempting approach would have a single tool, validate_vat_number, which first attempts validation through VIES and, if that fails or the format is clearly incorrect, falls back to a regex check.

While this design simplifies the mental model for the caller, it is incorrect due to differing cost profiles of the two methods. Format checking is a simple regex operation that runs quickly, offline, and without external dependencies, but it cannot guarantee the VAT number is valid since a correctly formatted number might still be deregistered.

In contrast, registry validation is a live network call to VIES, which is stateful, rate-limited, and subject to downtime or slow responses. Combining these two functions into a single tool would force every caller to pay for the expensive, slower VIES validation even when only the quick, free check is needed. Instead, the actual server provides five tools, with the free/paid distinction separating offline, deterministic operations from live, fallible ones.

The free tools—check_vat_format, get_country_vat_rates, list_eu_vat_rates, list_supported_countries—operate offline using a bundled npm package that is updated daily from the European Commission’s TEDB. Only validate_vat_number requires an API key and makes a real request to VIES, which is why it is metered. This separation of tools reflects the different cost and failure modes of the two approaches.

If they had the same cost and failure modes, merging them into a single tool might make sense. However, since they don't, keeping them separate ensures users receive the most appropriate answer for their specific needs. In the context of MCP, the distinction between the two tools becomes critical for the model's decision-making process.

The description of each tool must guide the model correctly, as it reads the descriptions at the moment of deciding which tool to invoke. For example, check_vat_format's description explicitly states that it only performs an offline syntactic check and does not verify the VAT with VIES. This clear delineation between the purposes of the two tools helps prevent the model from choosing the cheaper, faster tool when a more comprehensive validation is actually required.

In summary, building an MCP server for VAT validation demonstrates that separating tools for different types of checks—those that are instant, free, and offline, versus those that are slower, paid, and live—provides a more accurate and useful service to users.