toolvend - utility APIs for agents

vat

VAT calculator for EU-27 + UK: net→gross or gross→net at standard or reduced rate. Includes rates table snapshot date. Paid per call: $0.002 in USDC via x402.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "amount": "<amount>",
      "country": "<country>"
    },
    "name": "vat"
  }
}

Input Schema

Name	Required	Description
`rate`	No	default standard
`amount`	Yes
`country`	Yes	ISO 3166-1 alpha-2, e.g. DE, FR, GB
`direction`	No	default net_to_gross

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedAug 2, 2026

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the unusual payment model ($0.002 per call in USDC via x402) and rates-table freshness, and 'calculator' implies a read-only computation, but it does not explain return values, rounding behavior, unsupported-country errors, or whether failed calls are charged.

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

Conciseness5/5

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

Two tightly written sentences front-load the core capability, then add payment and data-freshness context. Every clause contributes useful information, with no repetition of the title or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter financial calculator with no annotations and no output schema, the description covers scope, calculation direction, rate choices, data freshness, and cost. However, it does not state what the response contains, how rounding is handled, or what happens for unsupported countries, leaving meaningful gaps for correct interpretation of results.

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?

Schema coverage is 75%, with enums already documenting rate and direction and a description for country. The description adds useful meaning by mapping direction to net→gross/gross→net, scoping country to EU-27 plus UK, and implying that amount is interpreted as net or gross depending on direction. It still leaves reduced-rate availability nuances unstated, but adds value beyond the schema.

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

Purpose5/5

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

The description names a specific resource and operation: a VAT calculator for EU-27 plus the UK, supporting net→gross and gross→net at standard or reduced rates. That is precise enough for an agent to distinguish it from every sibling tool, none of which overlap with VAT calculation.

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

Usage Guidelines3/5

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

The purpose strongly implies when to use it, but there is no explicit 'use this when' guidance, no exclusions for unsupported countries, and no named alternatives. Because the sibling tools are unrelated, the lack of alternative routing is minor, but usage remains implied rather than stated.

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

All toolvend - utility APIs for agents tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?