OpenDealer MCP Server

Check Recalls

check_recalls

Read-onlyIdempotent

Open safety recalls for a listing. Cars use NHTSA at year, make, and model grain; a campaign may not apply to every VIN. Off-road uses CPSC and the listing id on GET /v2/listings/{listingId}/recalls. The response names the source and one outcome: confirmed for this VIN, possible for this year, make, and model, no matching published recall, or coverage unavailable. An empty list means the published source had no matching campaign.

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_recalls"
  }
}

Input Schema

Name	Required	Description
`vin`	No	17-character Vehicle Identification Number
`vertical`	No	Shopper vertical. An absent value covers every public vertical (cars and off-road). Live verticals come from list_verticals.
`listingId`	No	Canonical listing id (`dealerId-or-slug:VIN`). Required for an off-road unit when the VIN is listed at more than one rooftop. Same path key as GET /v2/listings/{listingId}/recalls.

Output Schema

Name	Required	Description	Default
`vin`	No
`count`	No
`recalls`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 11, 2026

changedInput schema / properties / vertical / description

Previous value: -"Shopper vertical. Omit for every public vertical (cars and off-road). Live verticals come from list_verticals."New value: +"Shopper vertical. An absent value covers every public vertical (cars and off-road). Live verticals come from list_verticals."

Changed7 schema fields changedNov 11, 2026
- addedInput schema / $schema
```
Added value: +"https://json-schema.org/draft/2020-12/schema"
```
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / vin / pattern
```
Added value: +"^[A-HJ-NPR-Z0-9]{17}$"
```
- addedInput schema / properties / vin / type
```
Added value: +"string"
```
- addedOutput schema / $schema
```
Added value: +"https://json-schema.org/draft/2020-12/schema"
```
- changedOutput schema / additionalProperties
```
Previous value: -trueNew value: +{}
```
- changedOutput schema / properties / recalls / items / additionalProperties
```
Previous value: -trueNew value: +{}
```

Changed1 schema field changedNov 8, 2026

changedInput schema / properties / vertical / description

Previous value: -"Shopper vertical. Omit for every public vertical (cars today). Live verticals come from list_verticals."New value: +"Shopper vertical. Omit for every public vertical (cars and off-road). Live verticals come from list_verticals."

Changed3 schema fields changedOct 24, 2026

addedInput schema / properties / listingId

Added value: +{
+  "description": "Canonical listing id (`dealerId-or-slug:VIN`). Required for an off-road unit when the VIN is listed at more than one rooftop. Same path key as GET /v2/listings/{listingId}/recalls.",
+  "maxLength": 300,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / vertical

Added value: +{
+  "description": "Shopper vertical. Omit for every public vertical (cars today). Live verticals come from list_verticals.",
+  "minLength": 1,
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "vin"
-]
```

Changed2 schema fields changedOct 17, 2026
- removedInput schema / properties / vin / pattern
```
Removed value: -"^[A-HJ-NPR-Z0-9]{17}$"
```
- removedInput schema / properties / vin / type
```
Removed value: -"string"
```
Changed4 schema fields changedJul 30, 2026
- removedInput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```
- removedOutput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```
- changedOutput schema / properties / recalls / items / additionalProperties
```
Previous value: -{}New value: +true
```
- addedOutput schema / properties / recalls / items / properties
```
Added value: +{}
```
First observedJul 29, 2026

TDQS

A3.9/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, open-world), and the description adds real behavioral context beyond them: upstream sources (NHTSA, CPSC), grain limitations, a caveat that campaigns may not apply to every VIN, and the meaning of an empty list. The enumeration of outcomes (confirmed / possible / no matching recall / coverage unavailable) is especially useful for agent decision-making, though auth, rate limits, and latency are unaddressed.

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 dense sentences, front-loaded with the purpose and followed by source routing, response semantics, and the empty-list rule; nothing is wasted. The third sentence stacks source and four outcomes in one clause, which is compressed but still parseable.

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 read-only lookup with an output schema, three fully documented parameters, and full annotation coverage, the description supplies everything needed to call it and interpret it correctly, including data provenance and the meaning of absent or empty 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 100%, so the baseline is 3, but the description earns above that by explaining what parameters mean operationally: vertical selects the upstream source (cars vs off-road), and listingId is tied to the GET /v2/listings/{listingId}/recalls path key. It also clarifies the VIN vs year/make/model distinction for matching precision.

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

Purpose4/5

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

Opens with a specific verb+resource: "Open safety recalls for a listing," then pins down scope by vertical (NHTSA for cars at year/make/model grain, CPSC for off-road). It never names a sibling such as get_safety_rating or get_vehicle_history to disambiguate, so an agent must infer the boundary from the recall vocabulary alone.

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?

Usage context is implied rather than stated: the car-vs-off-road data-source routing tells an agent which verticals are covered, and "a campaign may not apply to every VIN" warns against over-reading results. There is no explicit when-to-call-this-instead-of-something-else and no named alternative, which is the main gap.

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

All OpenDealer MCP Server 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?