OmniaAuto — Canadian Vehicle Listings

by ca.omniaauto

Overview Discussions Admin

Server Details

Live Canadian vehicle listings, VIN decode and market valuations, province by province.

Ownership verified

Status: Healthy
Uptime: 0.9% over 57 days
Last Tested: 2026-10-18 09:46
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.5/5.0

Scored 2026-10-17 22:05 across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose, and the descriptions explicitly cross-reference sibling tools (e.g. decode_vin vs get_vin, valuation vs market_stats vs search_listings, coverage vs market_stats). Potential overlaps like price estimation are actively clarified, so an agent can reliably pick the right tool.

Naming Consistency3/5

The set mixes verb_noun names (decode_vin, get_vin, search_listings) with noun-phrase names (coverage, market_stats, my_usage, valuation). It is still readable and each name is meaningful, but there is no single predictable pattern.

Tool Count5/5

Seven tools is well-scoped for a vehicle listings and valuation service, with each tool earning its place: dataset coverage, VIN decode, VIN listing, market stats, usage/billing, search, and valuation. No redundancy or filler.

Completeness4/5

The surface covers discovery (search_listings), dataset scale (coverage), VIN resolution (decode_vin, get_vin), aggregate analysis (market_stats), valuation, and account state (my_usage). Minor gaps such as listing available makes/models or filtering by brand taxonomy, but core workflows are fully supported.

Available Tools

7 tools

coverageA

Read-only

Inspect

COST: 1 credit per call (OmniaAuto credits; my_usage shows the balance; at zero a call returns out_of_credits).

Dataset size: the number of distinct vehicles currently listed in Canada, the number of brands and the last update date. Use it for how big the dataset is; use market_stats for counts of a specific make, model or area.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`unit`	No	Always vehicle
`error`	No	Set on a refusal, e.g. out_of_credits, not_found; result fields are then absent
`brands`	No	Number of makes
`vehicles`	No	Distinct vehicles currently listed
`latest_update`	No	Date of the latest data update, YYYY-MM-DD
`credits_remaining`	No	Credits left in the current period

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare this a non-destructive, closed-world read, and the description adds real behavioral context those hints do not carry: 1 credit per call, the my_usage balance reference, and the concrete failure mode (out_of_credits at zero). This billing and quota behaviour is exactly the kind of operational detail an agent cannot infer from the annotations.

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 compact statements, with the cost constraint front-loaded before the capability and sibling routing. Every clause carries information the agent needs; nothing is padding.

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?

For a zero-parameter, read-only dataset summary with an output schema, the description covers cost, scope, return content, and the alternative tool. The output schema handles return-shape detail, so nothing material is missing.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. It correctly implies a parameterless call rather than leaving the agent wondering what inputs are needed.

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 scope: the number of distinct vehicles listed in Canada, the brand count, and the last-update date. It also explicitly distinguishes the tool from market_stats, so an agent can tell the two apart without opening either schema.

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

Usage Guidelines5/5

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

It gives a direct routing rule: use this tool for how big the dataset is, and use market_stats for counts of a specific make, model, or area. There is no ambiguity left about which sibling to pick.

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

decode_vinA

Read-onlyIdempotent

Inspect

COST: free (uses no OmniaAuto credits).

Decode a VIN into full specs: year, make, model, trim, body, drivetrain, engine and more. Works for any VIN, listed for sale or not; use get_vin for its live listing, price and listing_url. A malformed VIN returns error invalid_vin.

ParametersJSON Schema

Name	Required	Description	Default
`vin`	Yes	17-character VIN, letters and digits without I, O or Q; any case

Output Schema

ParametersJSON Schema

Name	Required	Description
`vin`	No
`make`	No
`note`	No
`trim`	No
`year`	No
`error`	No	Set on a refusal, e.g. out_of_credits, not_found; result fields are then absent
`model`	No
`decode_ok`	No	False when the VIN could not be decoded
`body_class`	No
`drive_type`	No
`credits_remaining`	No	Credits left in the current period

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds non-obvious behavior: it consumes no OmniaAuto credits and returns a specific error code 'invalid_vin' for malformed input. It stops short of describing the response shape, but with an output schema present that is acceptable.

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?

Three compact sentences: cost first, then capability, then routing and error behavior. Every sentence earns its place and the most decision-relevant fact (free) is front-loaded.

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?

For a single-parameter read tool with annotations and an output schema, the description covers cost, scope, sibling routing, and the error contract. Nothing an agent needs to select or invoke it correctly is missing.

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 100% and the vin property already documents the 17-character rule, allowed characters, and case-insensitivity. The description adds the failure mode (invalid_vin) tied to that parameter, which is a small but real increment over 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?

States a specific verb (decode) and resource (VIN) and enumerates the returned specs (year, make, model, trim, body, drivetrain, engine). It also names the sibling get_vin and how it differs, so an agent can distinguish the two without opening schemas.

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

Usage Guidelines5/5

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

Explicitly says it works for any VIN 'listed for sale or not' and directs the agent to get_vin when live listing, price, and listing_url are wanted. Both the use case and the alternative are named, leaving nothing to inference.

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

get_vinA

Read-only

Inspect

COST: 1 credit per call (OmniaAuto credits; my_usage shows the balance; at zero a call returns out_of_credits).

Get the latest live listing for one VIN: price, mileage, location and listing_url. Use it when you have a VIN and want that vehicle's listing; use decode_vin for the specs of any VIN, listed or not, and search_listings to find vehicles without a VIN. Show listing_url to the user (null means no link, never invent one); a VIN with no live listing returns error not_found.

ParametersJSON Schema

Name	Required	Description	Default
`vin`	Yes	17-character VIN, letters and digits without I, O or Q; any case

Output Schema

ParametersJSON Schema

Name	Required	Description
`MY`	No	Model year
`vin`	No
`City`	No
`Make`	No
`Trim`	No
`note`	No
`error`	No	Set on a refusal, e.g. out_of_credits, not_found; result fields are then absent
`model`	No
`price`	No	Asking price, CAD; null when none is advertised
`mileage`	No	Odometer, km
`Province`	No
`Condition`	No
`listing_url`	No	Link to show the user; null means no link
`credits_remaining`	No	Credits left in the current period

TDQS

A4.7/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly/openWorld/destructive/idempotent), and the description layers on top: cost of 1 credit per call, the credit-exhaustion failure mode (out_of_credits with my_usage as the balance check), the null listing_url convention with an explicit 'never invent one' instruction, and the not_found error path. This is behavior an agent cannot infer from structured fields.

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?

Three sentences, front-loaded with the cost constraint an agent needs before calling, then purpose, then routing and edge cases. No sentence is redundant and the most decision-relevant information (credits) leads.

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, return-value structure need not be restated, and the description instead spends its budget on cost, error modes, and alternate-tool routing. For a single-parameter read tool this leaves no material gap.

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 description coverage is 100% and the single vin parameter already documents the 17-character format and the I/O/Q exclusion. The description adds no format, normalization, or validation detail beyond the schema, so the baseline 3 is the correct ceiling here.

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 opens with a concrete verb+resource — 'Get the latest live listing for one VIN' — and enumerates the returned fields (price, mileage, location, listing_url). It explicitly separates itself from decode_vin and search_listings, so an agent can pick the right tool without inspecting any schema.

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

Usage Guidelines5/5

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

It states the selecting condition ('when you have a VIN and want that vehicle's listing') and names both alternatives with the conditions that route to them: decode_vin for specs of any VIN, search_listings to find vehicles without a VIN. The not_found case for a VIN with no live listing is disclosed as well.

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

market_statsA

Read-only

Inspect

COST: 1 credit per call (OmniaAuto credits; my_usage shows the balance; at zero a call returns out_of_credits).

Market statistics for any slice of Canadian vehicle listings: vehicle counts, average/median price and mileage, with optional group_by breakdowns. Use it for price and supply questions across many vehicles; use valuation for one year/make/model estimate, search_listings to see individual vehicles and coverage for the dataset's overall size. An invalid condition, group_by, sort, near or radius_km returns an error and costs nothing.

ParametersJSON Schema

Name	Required	Description
`make`	No	Make, e.g. Toyota; exact match, any case
`near`	No	Centre of a radius search: city, postal code or lat,lng (e.g. 53.54,-113.49); radius_km sets its size
`sort`	No	n = largest groups first (default); sold_30d = most sold in 30 days, needs group_by and condition Used or New
`model`	No	Model, e.g. RAV4; exact match, any case
`group_by`	No	Up to 2 of city, trim, year, condition, model (largest 25 groups, rest as Other); city needs province or near, trim needs make and model
`province`	No	2-letter province code, e.g. AB, ON, QC; empty = all Canada
`year_max`	No	Latest model year, e.g. 2024; 0 = any
`year_min`	No	Earliest model year, e.g. 2020; 0 = any
`body_type`	No	SUV, Sedan, Pickup, Hatchback, Minivan, Coupe, Van, Convertible or Wagon; empty = any
`condition`	No	New, Used, Certified or Demo; empty = any
`radius_km`	No	Radius around near, in km (default 25, max 500); requires near

Output Schema

ParametersJSON Schema

Name	Required	Description
`geo`	No	Resolved near anchor and radius_km, on a radius search
`note`	No
`unit`	No	Always vehicle
`error`	No	Set on a refusal, e.g. out_of_credits, not_found; result fields are then absent
`detail`	No
`groups`	No	One object per group, with n and price figures
`allowed`	No	Accepted values, on an invalid_* error
`pricing`	No
`summary`	No	n, unique_vins, avg_price, median_price, min_price, max_price, avg_mileage, priced
`group_by`	No	Breakdown dimensions applied
`by_province`	No
`by_condition`	No
`by_certification`	No
`credits_remaining`	No	Credits left in the current period

TDQS

A4.4/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing the cost model (1 credit per call, out_of_credits at zero balance) and the failure semantics (invalid condition, group_by, sort, near or radius_km errors and costs nothing). It does not add much on the read-only/idempotency side, but the annotations already cover that profile and the credit/error behavior is genuinely new information.

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?

Cost is front-loaded in a dedicated labeled sentence, and the usage routing follows immediately. Two dense paragraphs; the description is slightly long but every sentence carries either cost, scope, routing or error behavior.

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?

Output schema exists, so return values need no explanation, and the description still supplies cost, error implications, filtering scope and sibling routing for an 11-parameter tool. Nothing an agent needs to call it correctly is missing.

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 description coverage is 100%, so the schema already documents all 11 parameters including defaults and constraints like radius_km's 25/500 bounds. The description only alludes to group_by breakdowns and lists the condition/group_by/sort/near/radius_km parameters as error sources, which adds marginal value over 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?

States a specific verb+resource: market statistics for Canadian vehicle listings, enumerating the exact metrics returned (counts, average/median price and mileage) plus group_by breakdowns. An agent can distinguish it from valuation, search_listings and coverage without opening any schema.

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

Usage Guidelines5/5

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

Explicitly names the alternative for each case: valuation for a single year/make/model estimate, search_listings for individual vehicles, coverage for overall dataset size, and this tool for price/supply questions across many vehicles. Nothing is left to inference.

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

my_usageA

Read-onlyIdempotent

Inspect

COST: free (uses no OmniaAuto credits).

Your OmniaAuto plan, credits used and remaining, reset date and per-tool costs. Use it to check the balance or after an out_of_credits error; it returns no vehicle data (use search_listings or market_stats). Works even with zero credits left.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`plan`	No
`error`	No	Set on a refusal, e.g. out_of_credits, not_found; result fields are then absent
`plans_url`	No
`resets_on`	No	Date credits reset, YYYY-MM-DD; null when they do not refill
`plan_label`	No
`tool_costs`	No	Credits per call, by tool
`credits_used`	No
`rows_per_search`	No	Maximum vehicles per search_listings call
`credits_included`	No	Credits in the current period; null on an account with no limit
`credits_remaining`	No	Credits left in the current period

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral facts not in structured data: the call is free, consumes no OmniaAuto credits, and still works at zero balance — important for an agent deciding whether it can call it after an out_of_credits failure.

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?

Front-loaded cost line, then return contents, then usage guidance — efficient ordering. Slight redundancy across 'free', 'uses no OmniaAuto credits' and 'works even with zero credits left', which are three near-identical statements, costing a little density.

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?

For a no-argument, read-only status tool with an output schema and full annotation coverage, the description supplies everything needed: what it returns, what it costs, when to call it, and what it does not return.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter claims are made.

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 the specific resource returned — plan, credits used/remaining, reset date, per-tool costs — and explicitly excludes vehicle data, naming search_listings and market_stats as the tools for that. An agent can distinguish it from every sibling without opening a schema.

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

Usage Guidelines5/5

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

Gives two concrete triggers: checking the balance and recovering after an out_of_credits error, plus an explicit redirect to search_listings or market_stats when vehicle data is wanted. Both when-to-use and when-not-to-use are covered.

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

search_listingsA

Read-only

Inspect

COST: 3 credits per call (OmniaAuto credits; my_usage shows the balance; at zero a call returns out_of_credits).

Search live Canadian vehicle listings by make, model, location, price and other filters: returns up to 10 matching vehicles (specs, price, mileage, location, listing_url) and the total count. Use it to see individual vehicles, not market-wide figures (market_stats) or a price estimate (valuation). Show listing_url to the user (null means no link, never invent one); an unrecognised condition, near or radius_km returns an error and costs nothing.

ParametersJSON Schema

Name	Required	Description
`city`	No	City name, e.g. Calgary; exact match, any case
`make`	No	Make, e.g. Toyota; exact match, any case
`near`	No	Centre of a radius search: city, postal code or lat,lng (e.g. 53.54,-113.49); radius_km sets its size
`sort`	No	price, mileage, year, last_seen (default), first_seen or distance (requires near)
`limit`	No	Vehicles to return, 1-10; larger values are capped at 10
`model`	No	Model, e.g. RAV4; exact match, any case
`order`	No	asc or desc; default is asc for price, mileage and distance, desc otherwise
`province`	No	2-letter province code, e.g. AB, ON, QC; empty = all Canada
`year_min`	No	Earliest model year, e.g. 2020; 0 = any
`body_type`	No	SUV, Sedan, Pickup, Hatchback, Minivan, Coupe, Van, Convertible or Wagon; empty = any
`condition`	No	New, Used, Certified or Demo; empty = any
`price_max`	No	Max price in CAD; 0 = no limit
`price_min`	No	Min price in CAD; 0 = no limit
`radius_km`	No	Radius around near, in km (default 25, max 500); requires near
`mileage_max`	No	Max odometer in km; 0 = no limit

Output Schema

ParametersJSON Schema

Name	Required	Description
`geo`	No	Resolved near anchor and radius_km, on a radius search
`note`	No
`unit`	No	Always vehicle
`error`	No	Set on a refusal, e.g. out_of_credits, not_found; result fields are then absent
`total`	No	Vehicles matching the filters
`results`	No	One object per vehicle: vin, MY, Make, model, Trim, Condition, mileage, price, City, Province, listing_url, distance_km on a radius search
`returned`	No	Vehicles in results
`total_exact`	No
`pricing_note`	No
`credits_remaining`	No	Credits left in the current period
`allowance_exhausted`	No	True when the plan's vehicle limit is reached: total is returned, results is empty

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds the non-obvious economics and failure modes instead of repeating them. It discloses the 3-credit cost, that my_usage shows the balance, the out_of_credits return at zero balance, and that an unrecognised condition, near or radius_km errors out and costs nothing.

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?

Three sentences, each load-bearing, with the highest-stakes fact (credit cost) front-loaded. Slightly dense in the middle sentence, where filter and return detail run together, but there is no filler and nothing is repeated from the schema.

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?

For a 15-parameter, zero-required search tool with an output schema present, the description covers everything the schema and annotations do not: cost, credit exhaustion, error-and-no-charge behavior, link handling, and sibling routing. No gaps remain that would cause a mis-call.

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 description coverage is 100%, so the per-parameter syntax is already carried by the schema and the baseline would be 3. The description adds validation semantics the schema does not state: unrecognised values for condition, near and radius_km produce an error, and null listing_url means no link rather than a fabricated one.

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 ('Search live Canadian vehicle listings') plus the filter dimensions and the exact return shape (up to 10 vehicles with specs, price, mileage, location, listing_url, plus total count). It explicitly names the two siblings it is not (market_stats, valuation), so an agent can route without opening any schema.

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

Usage Guidelines5/5

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

Gives an explicit when-to-use rule ('Use it to see individual vehicles') and an explicit when-not, naming the alternatives market_stats for market-wide figures and valuation for a price estimate. It also states the operator-side constraint that listing_url must be shown and never invented.

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

valuationA

Read-only

Inspect

COST: 1 credit per call (OmniaAuto credits; my_usage shows the balance; at zero a call returns out_of_credits).

Price estimate (low/average/median/high) for one year, make, model and condition, from recent Canadian comparables, with province and mileage breakdowns. Use it for what a specific car is worth; use market_stats for market-wide figures and search_listings for individual vehicles. No comparables returns empty figures and a note, not an error; an invalid condition or a free-plan key returns an error (invalid_condition, upgrade_required) and costs nothing.

ParametersJSON Schema

Name	Required	Description
`make`	Yes	Make, e.g. Toyota; any case
`trim`	No	Trim, e.g. XLE, to narrow the estimate; empty = all trims
`year`	Yes	Model year, e.g. 2020
`model`	Yes	Model, e.g. RAV4; a common alternate spelling is resolved
`mileage`	No	Odometer in km; compares similar-mileage cars (band widened if few); 0 = ignore mileage
`province`	No	2-letter province code, e.g. AB, ON, QC; empty = all Canada
`condition`	Yes	New, Used, Certified or Demo (required)

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`error`	No	Set on a refusal, e.g. out_of_credits, not_found; result fields are then absent
`notes`	No	Caveats to relay with the figures
`query`	No	The year, make, model, condition, province, trim and mileage priced
`detail`	No
`allowed`	No	Accepted values, on an invalid_* error
`valuation`	No	low, average, median, high (CAD), sample_size, avg_mileage, mileage_band
`confidence`	No	low, medium or high, from the sample size
`sold_comps`	No
`by_province`	No
`total_comps`	No	Comparables found
`window_days`	No	Age of the comparables window, days
`by_mileage_band`	No
`credits_remaining`	No	Credits left in the current period
`by_province_mileage_band`	No

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare this a safe read, but the description goes well beyond them: 1 credit per call, balance visible via my_usage, out_of_credits at zero, empty figures plus a note (not an error) when there are no comparables, and invalid_condition/upgrade_required errors that cost nothing. That is exactly the failure-mode detail an agent needs and cannot get from structured fields.

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?

Cost is front-loaded and the routing rule follows, so the most actionable facts come first. The parenthetical about OmniaAuto credits and my_usage is slightly dense, but no sentence is filler.

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?

A 7-parameter required-4 tool with full schema descriptions, annotations, and an output schema — the description covers the remaining gaps (credits, error semantics, empty-result behavior) so nothing an agent needs to call it correctly is missing.

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 100%, so the baseline is 3; the description still adds value by explaining that province and mileage drive breakdowns in the output and that the estimate is built from recent Canadian comparables. It does not add meaning for trim, which the schema already covers.

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 concrete verb and resource — a low/average/median/high price estimate for one year/make/model/condition from recent Canadian comparables — and names two siblings it is not (market_stats, search_listings). An agent can distinguish it from every sibling without opening a schema.

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

Usage Guidelines5/5

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

Gives an explicit selection rule: 'use it for what a specific car is worth; use market_stats for market-wide figures and search_listings for individual vehicles.' It also states the cost model and when a call does or does not consume credits.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesOct 17, 2026

Changedcoverage1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "brands": {
+      "description": "Number of makes",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "credits_remaining": {
+      "description": "Credits left in the current period",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "error": {
+      "description": "Set on a refusal, e.g. out_of_credits, not_found; result fields are then absent",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "latest_update": {
+      "description": "Date of the latest data update, YYYY-MM-DD",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "note": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "unit": {
+      "description": "Always vehicle",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "vehicles": {
+      "description": "Distinct vehicles currently listed",
+      "type": [
+        "integer",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

Changeddecode_vin2 fields changed

changedInput schema / properties / vin / description

Previous value: -"17-character VIN"New value: +"17-character VIN, letters and digits without I, O or Q; any case"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "body_class": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "credits_remaining": {
+      "description": "Credits left in the current period",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "decode_ok": {
+      "description": "False when the VIN could not be decoded",
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "drive_type": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "error": {
+      "description": "Set on a refusal, e.g. out_of_credits, not_found; result fields are then absent",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "make": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "model": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "note": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "trim": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "vin": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "year": {
+      "type": [
+        "integer",
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

Changedget_vin2 fields changed

changedInput schema / properties / vin / description

Previous value: -"17-character VIN"New value: +"17-character VIN, letters and digits without I, O or Q; any case"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "City": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "Condition": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "MY": {
+      "description": "Model year",
+      "type": [
+        "integer",
+        "string",
+        "null"
+      ]
+    },
+    "Make": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "Province": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "Trim": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "credits_remaining": {
+      "description": "Credits left in the current period",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "error": {
+      "description": "Set on a refusal, e.g. out_of_credits, not_found; result fields are then absent",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "listing_url": {
+      "description": "Link to show the user; null means no link",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "mileage": {
+      "description": "Odometer, km",
+      "type": [
+        "integer",
+        "number",
+        "null"
+      ]
+    },
+    "model": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "note": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "price": {
+      "description": "Asking price, CAD; null when none is advertised",
+      "type": [
+        "integer",
+        "number",
+        "null"
+      ]
+    },
+    "vin": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

Changedmarket_stats12 fields changed

changedInput schema / properties / body_type / description

Previous value: -"e.g. SUV, Sedan, Pickup"New value: +"SUV, Sedan, Pickup, Hatchback, Minivan, Coupe, Van, Convertible or Wagon; empty = any"

changedInput schema / properties / condition / description

Previous value: -"New, Used, Certified or Demo"New value: +"New, Used, Certified or Demo; empty = any"

changedInput schema / properties / group_by / description

Previous value: -"Breakdown: city, trim, year, condition or model"New value: +"Up to 2 of city, trim, year, condition, model (largest 25 groups, rest as Other); city needs province or near, trim needs make and model"

changedInput schema / properties / make / description

Previous value: -"Make, e.g. Toyota"New value: +"Make, e.g. Toyota; exact match, any case"

changedInput schema / properties / model / description

Previous value: -"Model, e.g. RAV4"New value: +"Model, e.g. RAV4; exact match, any case"

changedInput schema / properties / near / description

Previous value: -"City, postal code or lat,lng"New value: +"Centre of a radius search: city, postal code or lat,lng (e.g. 53.54,-113.49); radius_km sets its size"

changedInput schema / properties / province / description

Previous value: -"Province, e.g. AB"New value: +"2-letter province code, e.g. AB, ON, QC; empty = all Canada"

changedInput schema / properties / radius_km / description

Previous value: -"Radius around near, km (default 25, max 500)"New value: +"Radius around near, in km (default 25, max 500); requires near"

changedInput schema / properties / sort / description

Previous value: -"n (default) or sold_30d"New value: +"n = largest groups first (default); sold_30d = most sold in 30 days, needs group_by and condition Used or New"

changedInput schema / properties / year_max / description

Previous value: -"Latest model year"New value: +"Latest model year, e.g. 2024; 0 = any"

changedInput schema / properties / year_min / description

Previous value: -"Earliest model year"New value: +"Earliest model year, e.g. 2020; 0 = any"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "allowed": {
+      "description": "Accepted values, on an invalid_* error",
+      "items": {},
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "by_certification": {
+      "additionalProperties": true,
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "by_condition": {
+      "items": {},
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "by_province": {
+      "items": {},
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "credits_remaining": {
+      "description": "Credits left in the current period",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "detail": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "error": {
+      "description": "Set on a refusal, e.g. out_of_credits, not_found; result fields are then absent",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "geo": {
+      "additionalProperties": true,
+      "description": "Resolved near anchor and radius_km, on a radius search",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "group_by": {
+      "description": "Breakdown dimensions applied",
+      "items": {},
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "groups": {
+      "description": "One object per group, with n and price figures",
+      "items": {},
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "note": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "pricing": {
+      "additionalProperties": true,
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "summary": {
+      "additionalProperties": true,
+      "description": "n, unique_vins, avg_price, median_price, min_price, max_price, avg_mileage, priced",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "unit": {
+      "description": "Always vehicle",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

Changedmy_usage1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "credits_included": {
+      "description": "Credits in the current period; null on an account with no limit",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "credits_remaining": {
+      "description": "Credits left in the current period",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "credits_used": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "error": {
+      "description": "Set on a refusal, e.g. out_of_credits, not_found; result fields are then absent",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "note": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "plan": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "plan_label": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "plans_url": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "resets_on": {
+      "description": "Date credits reset, YYYY-MM-DD; null when they do not refill",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "rows_per_search": {
+      "description": "Maximum vehicles per search_listings call",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "tool_costs": {
+      "additionalProperties": {
+        "type": "integer"
+      },
+      "description": "Credits per call, by tool",
+      "type": [
+        "object",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

Changedsearch_listings16 fields changed

changedInput schema / properties / body_type / description

Previous value: -"e.g. SUV, Sedan, Pickup"New value: +"SUV, Sedan, Pickup, Hatchback, Minivan, Coupe, Van, Convertible or Wagon; empty = any"

changedInput schema / properties / city / description

Previous value: -"City name"New value: +"City name, e.g. Calgary; exact match, any case"

changedInput schema / properties / condition / description

Previous value: -"New, Used, Certified or Demo"New value: +"New, Used, Certified or Demo; empty = any"

changedInput schema / properties / limit / description

Previous value: -"Max vehicles to return"New value: +"Vehicles to return, 1-10; larger values are capped at 10"

changedInput schema / properties / make / description

Previous value: -"Make, e.g. Toyota"New value: +"Make, e.g. Toyota; exact match, any case"

changedInput schema / properties / mileage_max / description

Previous value: -"Max mileage, km"New value: +"Max odometer in km; 0 = no limit"

changedInput schema / properties / model / description

Previous value: -"Model, e.g. RAV4"New value: +"Model, e.g. RAV4; exact match, any case"

changedInput schema / properties / near / description

Previous value: -"City, postal code or lat,lng"New value: +"Centre of a radius search: city, postal code or lat,lng (e.g. 53.54,-113.49); radius_km sets its size"

changedInput schema / properties / order / description

Previous value: -"asc or desc"New value: +"asc or desc; default is asc for price, mileage and distance, desc otherwise"

changedInput schema / properties / price_max / description

Previous value: -"Max price, CAD"New value: +"Max price in CAD; 0 = no limit"

changedInput schema / properties / price_min / description

Previous value: -"Min price, CAD"New value: +"Min price in CAD; 0 = no limit"

changedInput schema / properties / province / description

Previous value: -"Province, e.g. AB"New value: +"2-letter province code, e.g. AB, ON, QC; empty = all Canada"

changedInput schema / properties / radius_km / description

Previous value: -"Radius around near, km (default 25, max 500)"New value: +"Radius around near, in km (default 25, max 500); requires near"

changedInput schema / properties / sort / description

Previous value: -"price, mileage, year, last_seen, first_seen or distance"New value: +"price, mileage, year, last_seen (default), first_seen or distance (requires near)"

changedInput schema / properties / year_min / description

Previous value: -"Earliest model year"New value: +"Earliest model year, e.g. 2020; 0 = any"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "allowance_exhausted": {
+      "description": "True when the plan's vehicle limit is reached: total is returned, results is empty",
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "credits_remaining": {
+      "description": "Credits left in the current period",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "error": {
+      "description": "Set on a refusal, e.g. out_of_credits, not_found; result fields are then absent",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "geo": {
+      "additionalProperties": true,
+      "description": "Resolved near anchor and radius_km, on a radius search",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "note": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "pricing_note": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "results": {
+      "description": "One object per vehicle: vin, MY, Make, model, Trim, Condition, mileage, price, City, Province, listing_url, distance_km on a radius search",
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "returned": {
+      "description": "Vehicles in results",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "total": {
+      "description": "Vehicles matching the filters",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "total_exact": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "unit": {
+      "description": "Always vehicle",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

Changedvaluation8 fields changed

changedInput schema / properties / condition / description

Previous value: -"New, Used, Certified or Demo"New value: +"New, Used, Certified or Demo (required)"

changedInput schema / properties / make / description

Previous value: -"Make, e.g. Toyota"New value: +"Make, e.g. Toyota; any case"

changedInput schema / properties / mileage / description

Previous value: -"Odometer, km"New value: +"Odometer in km; compares similar-mileage cars (band widened if few); 0 = ignore mileage"

changedInput schema / properties / model / description

Previous value: -"Model, e.g. RAV4"New value: +"Model, e.g. RAV4; a common alternate spelling is resolved"

changedInput schema / properties / province / description

Previous value: -"Province, e.g. AB"New value: +"2-letter province code, e.g. AB, ON, QC; empty = all Canada"

changedInput schema / properties / trim / description

Previous value: -"Trim"New value: +"Trim, e.g. XLE, to narrow the estimate; empty = all trims"

changedInput schema / properties / year / description

Previous value: -"Model year"New value: +"Model year, e.g. 2020"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "allowed": {
+      "description": "Accepted values, on an invalid_* error",
+      "items": {},
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "by_mileage_band": {
+      "items": {},
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "by_province": {
+      "items": {},
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "by_province_mileage_band": {
+      "items": {},
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "confidence": {
+      "description": "low, medium or high, from the sample size",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "credits_remaining": {
+      "description": "Credits left in the current period",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "detail": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "error": {
+      "description": "Set on a refusal, e.g. out_of_credits, not_found; result fields are then absent",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "note": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "notes": {
+      "description": "Caveats to relay with the figures",
+      "items": {
+        "type": "string"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "query": {
+      "additionalProperties": true,
+      "description": "The year, make, model, condition, province, trim and mileage priced",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "sold_comps": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "total_comps": {
+      "description": "Comparables found",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "valuation": {
+      "additionalProperties": true,
+      "description": "low, average, median, high (CAD), sample_size, avg_mileage, mileage_band",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "window_days": {
+      "description": "Age of the comparables window, days",
+      "type": [
+        "integer",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

7 tool updatesOct 17, 2026
- First observedcoverage
- First observeddecode_vin
- First observedget_vin
- First observedmarket_stats
- First observedmy_usage
- First observedsearch_listings
- First observedvaluation

Related MCP Connectors

vehicle-data A
com.vincario
Vehicle data for AI: VIN decoder, automotive specs, stolen checks, valuation and way more.
Search Open Data Research & Data
422
MarketCheck APIOAuth
com.marketcheck
MarketCheck automotive data: search US/UK listings, predict prices, decode VINs, market history.
E-commerce & Retail Search Finance
2
scrap-autos-mcp A
com.scrap-autos
Instant Canadian scrap-car value quotes by year/make/model, provincial rates, and pickup leads.
Finance
42
OpenDealer MCP Server A
app.opendealer
Automotive inventory search for AI assistants: vehicles, dealers, deals, and market data.
E-commerce & Retail Search
252

Related MCP Servers

carsearch-mcp
Web Scraping E-commerce & Retail Search
Lironktf
F
license
A
quality
C
maintenance
MCP server for Canadian used-car search, monitoring, and market analysis, providing tools to search listings, analyze deals, track price history, and more.
Updated 19 days ago (2026-09-29 02:00 UTC)
23
-
mcp-carsxe
E-commerce & Retail
pipeworx-io
A
license
Not graded
quality
B
maintenance
Provides vehicle data tools for VIN specification decoding, used-car market valuation, license plate lookup, and vehicle history retrieval.
Updated 22 days ago (2026-09-25 22:19 UTC)
15 npm
MIT
Vehicle Database MCP Server
Search Databases Research & Data
BACH-AI-Tools
A
license
C
quality
D
maintenance
Enables access to comprehensive vehicle information including VIN decoding, license plate OCR, vehicle history checks (theft, title, salvage records), market valuations, specifications, and warranty data for vehicles across North America and Europe.
Updated 10 months ago (2025-12-08 09:35 UTC)
61
1
MIT
CarsXE
Developer Tools Documentation Access
carsxe
A
license
A
quality
A
maintenance
Decode VINs, look up specs, history, recalls, market value, and OBD codes. Recognize license plates and VINs from images. Access comprehensive vehicle data by year, make, and model to power automotive workflows.
Updated a day ago (2026-10-16 22:53 UTC)
12
1
MIT

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?