Skip to main content
Glama

Autoza UK

by io.github.Screed369
OverviewDiscussionsAdmin

calculate_car_tax

Calculate annual UK vehicle tax (VED / road tax) for any car. Handles all three UK systems: cars registered before March 2001 (taxed on engine size), March 2001 to March 2017 (CO2 bands, £20–£790), and April 2017 onward (flat standard rate). Also works out the Expensive Car Supplement: over £40,000 list price when new for petrol, diesel and alternative fuel; over £50,000 for a zero-emission car first registered on or after 1 April 2025; and no supplement at all for a zero-emission car first registered before 1 April 2025, whatever it listed for. Pass registration_date as well as registration_year when you have it — the boundaries are dates, and the year alone cannot separate a March 2025 registration from an April one. Use this for any question about UK car tax, road tax, VED, or how much it costs to tax a specific car.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
co2NoCO2 emissions in g/km. Required for cars registered March 2001–March 2017; ignored for pre-2001 cars.
fuelYesFuel type. Use "alternative" for hybrid/LPG, "diesel-rde2" only for diesels meeting RDE2.
engine_size_ccNoEngine size in cc. Only used for cars registered before March 2001.
registration_dateNoFull date of FIRST registration as YYYY-MM-DD, from the V5C. Optional but strongly preferred: every UK VED boundary is a date (1 March 2001, 1 April 2017, 1 April 2025), so the year alone cannot tell a zero-emission car registered 1 March 2025 (no Expensive Car Supplement) from one registered 1 April 2025 (supplement). Without it, an ambiguous case is answered with a caveat in notes rather than a figure.
registration_yearYesYear the car was FIRST registered (not the year it was bought). This decides which tax system applies and is the single most important input.
list_price_when_newNoOriginal list price in GBP when the car was new. Needed only to work out the Expensive Car Supplement — based on the price when NEW, not what you pay for it used.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / registration_date
      Added value: +{
+  "description": "Full date of FIRST registration as YYYY-MM-DD, from the V5C. Optional but strongly preferred: every UK VED boundary is a date (1 March 2001, 1 April 2017, 1 April 2025), so the year alone cannot tell a zero-emission car registered 1 March 2025 (no Expensive Car Supplement) from one registered 1 April 2025 (supplement). Without it, an ambiguous case is answered with a caveat in notes rather than a figure.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the burden of disclosing behavior, and it does so thoroughly: it explains regime boundaries, the zero-emission-car exception, and the caveat about ambiguous cases. It doesn't mention that this is a pure read/calculation operation with no side effects, but for a calculator-style tool the disclosed edge-case handling is what matters most.

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

Conciseness4/5

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

The description is long, but every sentence earns its place by specifying regime boundaries, edge cases, and parameter intent. It front-loads the purpose and then details exceptions; a tighter structure would group the tax regimes more cleanly, but nothing is wasted.

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

Completeness4/5

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

Given six parametersament, no annotations, and no output schema, the description covers the main behavioral surface: regimes, exceptions, and date guidance. It doesn't state the return shape or currency formatting, which would help an agent consume the result, but for a calculation tool the coverage is strong.

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

Parameters5/5

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

Schema coverage is high (every parameter has a description), yet the tool description still adds real semantic value: it explains that registration_year alone is insufficient in edge cases, that engine_size only applies to pre-2001 cars, that the expensive car threshold differs for zero-emission vehicles, and that list_price_when_new means original new price, not current market value. This goes 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 opening sentence states a specific verb, object, and scope: 'Calculate UK car tax (VED / road tax)' and immediately names the alternatives. The breakdown of the three tax regimes makes it unambiguous which calculation applies. This is a model of purpose clarity.

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

Usage Guidelines4/5

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

The description gives explicit instruction on when to use the tool ('use this for any question about UK car tax') and even tells the agent to pass registration_date when available to disambiguate edge cases. It doesn't name sibling tools or exclusion conditions, but the guidance is clear enough for routing and invocation.

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

All Autoza UK toolsInspect
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