The Cardog MCP server: vehicle data as five tools

Connect Claude, Cursor, VS Code, and any MCP client to Cardog vehicle data.

bash
claude mcp add --transport http cardog "https://mcp.cardog.io/mcp?api_key=$CARDOG_API_KEY"

Five tools, shaped like jobs rather than endpoints: resolve_entity (free text → refs), identify_vehicle (VIN → identity), search_inventory (ref-native listings), market_quote (instrument → live book), check_recalls (VIN or ref → campaigns, Transport Canada and NHTSA fused). All five are reads.

Free text enters in exactly one place. resolve_entity turns "2026 CR-V" — or "teslla", or whatever a user typed — into refs with confidence scores, and every other tool takes refs or a VIN. This is not a stylistic preference: it is why the server does not hand back a confidently wrong vehicle. When a ref is unknown, the tool returns an error naming it with nearest-ref suggestions, and the model corrects in one turn instead of guessing.

The server is a remote Model Context Protocol server — nothing to run or update locally.

TransportURL
Streamable HTTP (preferred)https://mcp.cardog.io/mcp
SSEhttps://mcp.cardog.io/sse

Install

Claude Code

bash
claude mcp add --transport http cardog "https://mcp.cardog.io/mcp?api_key=$CARDOG_API_KEY"

Claude (web / desktop / mobile)

Add a custom connector under Settings → Connectors with the URL https://mcp.cardog.io/mcp and your API key when prompted.

Cursor

Add to Cursor — then add your key to the server URL in ~/.cursor/mcp.json:

Example

1 keys
"response": {
"mcpServers": {
"cardog": {1 item}
}
}

VS Code

bash
code --add-mcp '{"name":"cardog","type":"http","url":"https://mcp.cardog.io/mcp?api_key=YOUR_API_KEY"}'

Or click Install in VS Code, then append ?api_key=YOUR_API_KEY to the server URL it writes.

Any MCP client

The server accepts a Cardog API key (from cardog.app/account/api) via:

MethodFormat
Query parameter?api_key=YOUR_API_KEY
Authorization headerAuthorization: Bearer YOUR_API_KEY
Custom headerx-api-key: YOUR_API_KEY

The five tools

ToolWhat it does
resolve_entityFree text → entity refs with confidence — the text entry point
identify_vehicleVIN → full identity: refs, nano/squish grains, spec highlights, links
search_inventoryRef-native listings search: ref + range + spec filters → listings, facets, count
market_quoteInstrument ref (model-year: or squish:) → live book stats, history summary, sample
check_recallsVIN or entity ref → recall campaigns (Transport Canada + NHTSA, ref-keyed)

Each tool is a job a user actually has, not a route the API happens to expose:

  • resolve_entity exists because free text has to become a ref exactly once — it is the only tool that accepts prose.
  • identify_vehicle is "what is this car" in one call — refs, grains, and spec highlights together, instead of decode, specs, and lookup stitched by the model.
  • search_inventory is "what's for sale" — filters are refs, so a hallucinated make is a caught error, not a silently empty result.
  • market_quote is "what is it worth" — the model receives book stats it can quote, not raw rows it has to aggregate.
  • check_recalls is "is it under recall" — two authorities fused and ref-keyed, one answer instead of two agencies.

A transcript

<!-- HOLD-3263: re-capture quote transcript after fold fix, then uncomment -->

The exchange worth showing is the correction loop, with the mistake left in:

text
  ⏺ check_recalls(ref: "make:teslla")
    → 400 unknown_entity_refs
      hint: "Resolve free text to refs at GET /v2/entities/resolve"
      suggestions: [{ invalid: "make:teslla", nearest: [{ ref: "make:tesla", name: "Tesla" }],
                      resolve: "/v2/entities/resolve?domain=make&q=teslla" }]

  ⏺ check_recalls(ref: "make:tesla")
    → 143 campaigns (TC + NHTSA)

The API never silently corrects make:teslla to make:tesla. It returns a 400 that names the mistake and carries the fix, and the agent retries. One wrong turn, no wrong answer.

What the tool descriptions teach

The tool descriptions are instructions, not labels. They teach the model the platform's grammar before its first call: resolve first — free text goes through resolve_entity and nowhere else — and everything downstream speaks refs, not names. A ref like make:tesla is permanent vocabulary; once it appears in a tool result, the model can hold it and reuse it for the rest of the session without another resolve.

They also teach the model what an error means here. Every failure carries code, hint, and suggestions with the nearest valid refs — the error envelope is a correction, not a dead end — and the descriptions say so up front. The result is a model that is good at this API on the first try: it does not guess vocabulary, nothing fuzzy-matches on its behalf, and when it is wrong the response itself carries the fix.

Prefer raw REST for agents?

The whole v2 API is agent-native without MCP: fetch /docs.md for the entire platform as one markdown document, use GET /v2/entities/resolve as the free-text front door, and follow the links block each response carries. Errors name the offending input and suggest the nearest valid refs.

Limitations

A key is required. There is no keyless trial tier today, so installing the server and calling a tool are two steps, not one. Get a key at cardog.app/account/api; the free tier is 50 credits per month with a hard stop.

Five tools, all reads. Nothing here writes, and there is no catch-all "query" tool — if your job isn't one of the five, use the REST surface directly. /docs.md is the whole platform in one fetch, and agents do fine with it.

The data is Canadian. Listings and market quotes cover the Canadian retail market — ~190k live listings, observed continuously. Recalls fuse Transport Canada and NHTSA. If you need US listings, this is the wrong server.