Skip to main content
Glama
Sign In

divux

by si.divux
OverviewDiscussionsAdmin

Car: official vehicle data and fuel cost

check_car
Read-only

Returns official US vehicle data for a VIN or a year, make and model: specs from NHTSA vPIC, NHTSA recalls, owner complaints with the most-reported components, NHTSA 5-star crash ratings, and EPA fuel economy from fueleconomy.gov. With miles, it also returns fuel cost: EPA combined mpg (or a supplied mpg) times the current weekly average pump price from the US Energy Information Administration for a state, its region or the US. With a VIN, odometer and ZIP code, it also returns a market price for that car, plus the median and range of similar cars listed for sale. A VIN selects one version; a year, make and model covers the model year. Accident history and title status are not included. The value is a model estimate, not an appraisal. Applies to vehicle specs, complaints, ratings, value or fuel cost. A recall-only question is outside this result. Results report what the official sources say and are not a safety assessment.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_car"
  }
}

Input Schema

NameRequiredDescriptionDefault
mpgNoFor fuel cost: the car's mpg, if known or when there's no specific car
vinNo17-character VIN, if known
zipNoFor fair value: the 5-digit US ZIP code where the car is or will be sold
fuelNoFor fuel cost, when the model comes in both
makeNoMake, e.g. 'Honda'
yearNoModel year, when there's no VIN
milesNoFor fuel cost: driving distance in miles, one way
modelNoModel, e.g. 'CR-V'
stateNoFor fuel cost: two-letter US state where most of the driving happens, e.g. CA
countryNoCountry: US (default) or Canada
odometerNoFor fair value: the car's current mileage on the odometer (not a trip distance)
fuel_onlyNotrue when only fuel cost is wanted; skips recall, complaint and crash-rating lookups (needs miles and mpg, or year/make/model)
round_tripNoFor fuel cost: true to double the distance

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / country
      Added value: +{
+  "description": "Country: US (default) or Canada",
+  "maxLength": 60,
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / odometer
      Added value: +{
+  "description": "For fair value: the car's current mileage on the odometer (not a trip distance)",
+  "maximum": 999999,
+  "minimum": 0,
+  "type": "number"
+}
    • addedInput schema / properties / zip
      Added value: +{
+  "description": "For fair value: the 5-digit US ZIP code where the car is or will be sold",
+  "maxLength": 10,
+  "type": "string"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / fuel_only
      Added value: +{
+  "description": "true when only fuel cost is wanted; skips recall, complaint and crash-rating lookups (needs miles and mpg, or year/make/model)",
+  "type": "boolean"
+}
  4. Changed5 schema fields changed
    • addedInput schema / properties / fuel
      Added value: +{
+  "description": "For fuel cost, when the model comes in both",
+  "enum": [
+    "regular",
+    "diesel"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / miles
      Added value: +{
+  "description": "For fuel cost: driving distance in miles, one way",
+  "exclusiveMinimum": 0,
+  "maximum": 20000,
+  "type": "number"
+}
    • addedInput schema / properties / mpg
      Added value: +{
+  "description": "For fuel cost: the car's mpg, if known or when there's no specific car",
+  "exclusiveMinimum": 0,
+  "maximum": 200,
+  "type": "number"
+}
    • addedInput schema / properties / round_trip
      Added value: +{
+  "description": "For fuel cost: true to double the distance",
+  "type": "boolean"
+}
    • addedInput schema / properties / state
      Added value: +{
+  "description": "For fuel cost: two-letter US state where most of the driving happens, e.g. CA",
+  "maxLength": 2,
+  "minLength": 2,
+  "type": "string"
+}
  5. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/non-destructive, and the description goes well beyond them: it names every upstream data source, discloses that accident history and title status are NOT included, and twice qualifies the output as a model estimate rather than an appraisal or safety assessment. These are exactly the caveats an agent needs to avoid overstating results to a user.

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?

It is a single dense paragraph but front-loads the returned data, then moves through each optional mode, then the exclusions and disclaimers. Every sentence carries information, though the two closing caveats ('model estimate, not an appraisal' and 'not a safety assessment') are somewhat repetitive and could be merged.

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?

For a 13-parameter, no-required-parameter tool with no output schema, the description does the heavy lifting: it enumerates returned data types, explains each conditional mode, and flags omissions. What it does not do is sketch the shape of the response (field names, how complaints or comparable listings are structured), which matters more given there is no output schema.

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 would be 3, but the description adds real conditional meaning: which parameter combinations activate which output (miles+mpg for fuel cost, VIN+odometer+ZIP for market price), that a VIN selects one version while year/make/model covers the model year, and that state/region/US drives the pump-price lookup. That combination logic is not derivable from the flat 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 opens with a concrete verb+resource ('Returns official US vehicle data for a VIN or a year, make and model') and enumerates the exact payload: NHTSA vPIC specs, recalls, complaints, crash ratings, EPA fuel economy. It explicitly names the boundary case that belongs elsewhere ('A recall-only question is outside this result'), which cleanly separates it from the check_recalls sibling without needing to open 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 Guidelines4/5

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

It states the use cases directly ('Applies to vehicle specs, complaints, ratings, value or fuel cost') and gives an explicit exclusion for recall-only questions. It also spells out the conditional triggers that unlock each mode (miles for fuel cost, VIN+odometer+ZIP for market value). It stops short of naming the alternative tool for the excluded recall case, leaving the agent to infer check_recalls.

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

All divux 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