Autoza UK

Get UK asking-price guide

get_uk_price_guide

Read-only

Get current UK used-car asking-price guidance from live dealer listings on Autoza — typical (median), lowest and highest asking price, optionally narrowed to a make or model. Where too few cars match to give a fair figure it says so instead of answering. Cars unless vehicle_type asks for vans, motorcycles or other stock. Prices are GBP and reflect what dealers are asking right now, not trade or valuation estimates. Use to answer "what do X cost used in the UK" or to sanity-check whether an advertised price is reasonable.

Input Schema

TableJSON Schema

Name	Required	Description
`make`	No	Optional: narrow to a manufacturer.
`model`	No	Optional: narrow to a model.
`vehicle_type`	No	Vehicle type. Defaults to "car". Results are filtered on the vehicle type each listing is recorded under. Pass "van", "motorcycle", "motorhome", "truck" or "caravan" for other stock.

Output Schema

TableJSON Schema

Name	Required	Description
`_note`	Yes	Where the figures come from: Autoza, prices in GBP, distances in miles.
`basis`	No
`scope`	No
`message`	No
`vat_note`	No
`available`	No	False, with a message, when too few cars match to give a fair figure. Absent when a figure is given.
`make_note`	No
`model_note`	No
`typical_is`	No
`vehicle_type`	No
`make_interpreted_as`	No
`lowest_asking_price_gbp`	No
`highest_asking_price_gbp`	No
`typical_asking_price_gbp`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 6, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "_note": {
+      "description": "Where the figures come from: Autoza, prices in GBP, distances in miles.",
+      "type": "string"
+    },
+    "available": {
+      "description": "False, with a message, when too few cars match to give a fair figure. Absent when a figure is given.",
+      "type": "boolean"
+    },
+    "basis": {
+      "type": "string"
+    },
+    "highest_asking_price_gbp": {
+      "type": "number"
+    },
+    "lowest_asking_price_gbp": {
+      "type": "number"
+    },
+    "make_interpreted_as": {
+      "type": "string"
+    },
+    "make_note": {
+      "type": "string"
+    },
+    "message": {
+      "type": "string"
+    },
+    "model_note": {
+      "type": "string"
+    },
+    "scope": {
+      "type": "string"
+    },
+    "typical_asking_price_gbp": {
+      "type": "number"
+    },
+    "typical_is": {
+      "type": "string"
+    },
+    "vat_note": {
+      "type": "string"
+    },
+    "vehicle_type": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "_note"
+  ],
+  "type": "object"
+}

Changed1 schema field changedSep 23, 2026

addedInput schema / properties / vehicle_type

Added value: +{
+  "description": "Vehicle type. Defaults to \"car\". Results are filtered on the vehicle type each listing is recorded under. Pass \"van\", \"motorcycle\", \"motorhome\", \"truck\" or \"caravan\" for other stock.",
+  "enum": [
+    "car",
+    "van",
+    "motorcycle",
+    "motorhome",
+    "truck",
+    "caravan"
+  ],
+  "type": "string"
+}

First observedSep 1, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover the read-only/non-destructive safety profile, and the description adds substantial context beyond them: the data source (live dealer listings), the aggregation behavior (typical/lowest/highest), the degraded-case behavior ('where too few cars match... it says so'), and the semantic caveat that these are asking prices, not valuations.

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?

Four sentences, each carrying distinct information (source, output figures, fallback behavior, scope/pricing semantics, use cases), with the core capability front-loaded. Slightly dense, but nothing is redundant.

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

Completeness5/5

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

With an output schema present, the description does not need to enumerate return fields, yet it still clarifies what the figures mean and how the tool behaves when data is thin. For a 3-optional-parameter read tool, an agent has everything needed to call and interpret it correctly.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents make, model, and vehicle_type, including the default of 'car' and the enum values. The description restates the narrowing behavior and the vehicle-type switch without adding syntax or format detail beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource ('Get current UK used-car asking-price guidance') plus the data source ('live dealer listings on Autoza') and the exact values returned (median, lowest, highest asking price). This is clearly distinguishable from siblings like search_used_cars and estimate_running_costs.

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?

Gives concrete use cases ('what do X cost used in the UK', 'sanity-check whether an advertised price is reasonable') and an explicit exclusion ('not trade or valuation estimates'). No sibling tool is named as an alternative, but the when-to-use guidance is clear enough to route an agent.

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

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