Free EU VAT, IBAN and bol.com commission tools for marketplace sellers
Scored across 3 tools
Each tool addresses a completely distinct concern: bol.com commission, VAT calculation, and IBAN validation. There is no functional overlap or ambiguity between them.
All names use snake_case and are descriptive, though 'bol_commission' follows a noun_noun pattern while the other two use verb_noun. This is a minor deviation, not a confusing mix.
Three tools feel slightly lean for a server named 'WinkelFactuur' (invoice), but each is a meaningful financial calculation. The count is within the acceptable range and not bloated.
The set covers key financial prerequisites for invoicing: seller margin, VAT, and bank account validation. A notable omission is any tool to actually generate or manage invoices, but the existing tools form a coherent, usable subset.
Work out what bol.com keeps from a sale: the commission percentage for the product category, any fixed fee, and what the seller is left with.
Category names are the Dutch ones bol.com uses ("Elektronica", "Boeken", "Speelgoed"). If the category is unknown or missing, the tool returns the list of categories it knows, so call it again with one of those.
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | Selling price in euros, including VAT, as shown to the buyer. | |
| category | Yes | bol.com main category, in Dutch. For example: Elektronica, Boeken, Speelgoed, Wonen & Koken. | |
| subcategory | No | Subcategory when the main one splits by rate, e.g. Telefoons or Televisies under Elektronica. | |
| fulfilment_type | No | lvb for Logistiek via bol, fbr when the seller ships. Leave out if it does not matter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden of behavioral disclosure. It adds value by stating that category names must be Dutch, and it reveals an important fallback behavior: unknown or missing categories return a list of known categories and suggest a retry. This goes beyond what the input schema conveys.
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 compact and front-loaded: the first sentence states the core purpose, then the following sentences address category-language requirements and the unknown-category retry behavior. Every sentence earns its place with no filler or repetition.
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 low-complexity calculation tool with no output schema, the description explains the main return contents and the important edge-case behavior. It is complete enough for an agent to call the tool correctly, though it does not describe response format in detail.
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 explains all parameters clearly. The description reinforces that category values are Dutch, but it does not add material semantics beyond the schema for price, subcategory, or fulfilment_type.
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 uses a specific verb ('Work out'), names the exact resource (bol.com sale commission), and lists the concrete outputs: commission percentage, fixed fee, and seller proceeds. This clearly distinguishes it from the sibling tools calculate_vat and validate_iban.
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 implies when to use the tool through its clear focus on bol.com commission, but it never explicitly states when to choose this tool over its siblings or when not to use it. It does provide indirect usage guidance by explaining how to handle unknown or missing categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate EU VAT (Dutch: BTW) for a cross-border or domestic sale, using the destination-country principle that applies to e-commerce.
Handles the cases sellers get wrong: OSS distance selling to another EU country, B2B reverse charge when the buyer has a VIES-valid VAT number, and zero-rated exports outside the EU. Rates are the statutory ones for the destination country, including reduced rates when a category is given.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Net amount (excluding VAT) in euros. | |
| category | No | Optional product category, used to find a reduced rate (books, food, medicine and similar). | |
| is_business | No | True when the buyer is a business (B2B). Reverse charge also needs a valid VAT number. | |
| seller_country | No | Two-letter country code the seller is established in. Defaults to NL. | |
| customer_country | Yes | Two-letter country code the goods are shipped to, e.g. NL, DE, FR. This is what determines the rate. | |
| customer_vat_number | No | Buyer VAT number. Required for B2B reverse charge; it is checked against VIES, so an invented number will not zero the VAT. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description reveals non-obvious behavior: rates follow the destination country, reverse charge depends on a VIES-valid buyer VAT number, and exports outside the EU are zero-rated. It also notes reduced rates when a category is supplied, giving an agent a solid model of how the calculation will behave.
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?
Two tight paragraphs with the core purpose and differentiating legal cases front-loaded. No filler or repetition of parameter names.
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 six-parameter tax calculation with no annotations and no output schema, the description provides most needed context: inputs, applicable rules, and special cases. The only notable gap is not describing the response shape (e.g., VAT amount vs. rate breakdown), but the tool's intent makes the output largely predictable.
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?
All six parameters are fully described in the input schema (100% coverage), so the description only needs to add value beyond that. It does by tying combinations of parameters to legal scenarios (OSS, reverse charge, exports) and noting that category selects reduced rates.
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 opens with a specific verb and resource ('Calculate EU VAT') and immediately narrows scope with 'destination-country principle' and 'cross-border or domestic sale.' It also enumerates distinct scenarios (OSS, B2B reverse charge, zero-rated exports), making it easy to distinguish from sibling tools like bol_commission and validate_iban.
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?
It gives clear invocation context: use for cross-border or domestic e-commerce sales subject to EU VAT, and it flags the edge cases where sellers commonly err. It does not explicitly say 'don't use for X' or name alternatives, but the sibling domains are so different that the absence of exclusions is not costly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an IBAN (bank account number) and report whether its check digits and country-specific length are correct.
Catches transposed or missing digits before a payment or an invoice goes out with the wrong account number. This checks the number's structure, not whether the account exists or who owns it.
| Name | Required | Description | Default |
|---|---|---|---|
| iban | Yes | The IBAN to check. Spaces, dots and dashes are ignored, so it can be pasted as printed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clearly discloses what the tool does and does not check, including the structural scope and limitations. It stops short of describing the exact return format or error behavior, but 'report whether' gives a reasonable indication.
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 compact, front-loads the core purpose in the first sentence, and uses the second paragraph to add practical context and limitations. Every sentence contributes useful information with no 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 simple one-parameter validation tool, the description covers what is validated, when to use it, and what it deliberately does not do. There is no output schema, so an explicit return contract would improve completeness, but 'report whether' is sufficient for an agent to invoke it correctly.
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?
The schema already provides 100% coverage for the single 'iban' parameter, including normalization behavior for spaces, dots, and dashes. The description adds only a minor clarification that IBAN is a bank account number, so the schema carries the semantic weight.
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 uses a specific verb ('Validate') with a clear resource (IBAN) and defines exactly what validation covers: check digits and country-specific length. It clearly distinguishes this from the unrelated sibling tools (bol_commission, calculate_vat) and from account existence or ownership checks.
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?
It explicitly states when to use the tool: before sending a payment or invoice, to catch transposed or missing digits. It also gives an explicit when-not: it does not check whether the account exists or who owns it, which prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
bol_commissioncalculate_vatvalidate_ibanEU business checks: VAT/VIES, IBAN, Peppol, KBO lookup. 16 of 19 tools need no token.
Commerce validators: live EU VAT (VIES), EORI, email/MX lookups; IBAN/ABA/GTIN checksums; VAT rates.
Utility data for AI agents: IBAN, EU holidays, VAT rates, time zones, ECB FX. Pay per call.
Free EU VAT (VIES) + pan-EU company data (10 registers), payable in EURC/USDC via x402.
Add one secure layer between your agents and this server.