How to give Claude a VIN-decoder tool with the Apify MCP server

AI agents are good at reasoning and terrible at facts. Paste a 17-character VIN into a chat and ask Claude what the car is, and it will happily tell you a make, a model, and a year. Sometimes it is right. Often it is confidently wrong, because a VIN is a coded string that maps to an exact vehicle through a manufacturer-reported database the model has never reliably memorized. For an insurance quote, a fleet record, or a marketplace listing, "the model probably guessed right" is not a number you can put in a system of record.

In this guide we fix that. We connect Claude to the official Apify MCP server, expose a single Actor that decodes a VIN into full vehicle specifications, and turn "what is this car?" from a guess into a live lookup against the authoritative source. By the end you will have a working VIN-decoder tool that Claude, Cursor, or any MCP client can call mid-conversation, and you will understand exactly where in the run the tool fires and what it returns.

Everything below is a real setup with real output. No mocked responses.

What is the Apify MCP server?

Model Context Protocol (MCP) is an open standard that lets AI clients call external tools. The Apify MCP server (https://mcp.apify.com) implements that standard on top of the Apify platform, which means every one of the thousands of Actors in the Apify Store becomes a tool an agent can invoke.

Why route an Actor through MCP instead of hard-coding an API call?

• The agent decides when to fetch. Claude reads the conversation, notices it is holding a VIN it cannot decode reliably from memory, and calls the tool on its own. You do not write glue code for every question.
• Structured input and output. The MCP server hands Claude the Actor's input schema, so the model fills in the parameters correctly, and returns a clean dataset it can reason over.
• One connection, many tools. The same MCP endpoint exposes search-actors, fetch-actor-details, and call-actor, so an agent can discover and run any Actor without new configuration.
• No infrastructure. The server is hosted. You add a few lines to a config file and you are done.

The Actor we will use

We will expose the NHTSA VIN Decoder & Vehicle Specs Scraper. Give it one or many VINs and it returns the full specification record for each vehicle: make, model, model year, body class, vehicle type, doors and seats, fuel type and electrification level, engine and transmission details, drive type, GVWR class, a long list of safety and driver-assist features (ABS, ESC, TPMS, airbag locations, forward-collision warning, blind-spot monitor, lane-keep), the manufacturer, and the assembly plant city, state, and country.

That field set is exactly what a vehicle-facing business needs to identify and price a car it has never physically seen. It accepts full 17-character VINs for the most complete result, and partial VINs with a wildcard when you only have a fragment. Every field comes from the official record for that exact VIN, not an estimate.

Step 1: Get your Apify API token

Sign in to the Apify Console, open Settings → Integrations, and copy your personal API token. The MCP server uses it to authenticate and to bill Actor runs to your account.

📌 Note: the token is a secret. Keep it in the client config only, never in a prompt or a committed file.

Step 2: Point Claude Desktop at the Apify MCP server

Open Claude Desktop's config file (Settings → Developer → Edit Config, or ~/Library/Application Support/Claude/claude_desktop_config.json on macOS) and add the Apify server. The tools query parameter is the important part: it tells the server which Actor to expose, so Claude gets one focused tool instead of the entire Store.

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=scrapers_lat/nhtsa-vin-decoder-scraper",
      "headers": {
        "Authorization": "Bearer YOUR_APIFY_TOKEN"
      }
    }
  }
}

Cursor uses the same JSON in .cursor/mcp.json. If you prefer to run it locally over stdio instead of the hosted endpoint:

{
  "mcpServers": {
    "apify": {
      "command": "npx",
      "args": ["-y", "@apify/actors-mcp-server", "--tools", "scrapers_lat/nhtsa-vin-decoder-scraper"],
      "env": { "APIFY_TOKEN": "YOUR_APIFY_TOKEN" }
    }
  }
}

Restart Claude Desktop so it picks up the new server.

Step 3: Confirm the tool is loaded

After the restart, the Actor shows up as a callable tool. If you list the tools the Apify server exposes, you will see the storage helpers plus the Actor itself, named after its Store handle:

get-actor-run, get-dataset-items, get-key-value-store-record,
abort-actor-run, scrapers_lat--nhtsa-vin-decoder-scraper

That last entry, scrapers_lat--nhtsa-vin-decoder-scraper, is our decoder tool. Claude now knows it exists, what it does (from the Actor's README), and what inputs it takes (from the input schema the server passes along).

Step 4: Ask Claude to decode a VIN

Now the payoff. In a normal chat, ask a question that requires ground truth:

"I'm pricing a used vehicle for an insurance quote. Decode VIN 5YJ3E1EA7JF006588 and tell me exactly what this car is: make, model, year, body, powertrain and where it was built."

Claude recognizes it cannot answer this reliably from memory, selects the decoder tool, and fills in the input from your question. Under the hood the client sends a tools/call with the Actor's parameters:

{
  "name": "scrapers_lat--nhtsa-vin-decoder-scraper",
  "arguments": {
    "vins": ["5YJ3E1EA7JF006588"],
    "maxVins": 1
  }
}

The Apify MCP server starts the Actor, waits for it to finish, and returns the dataset. Here is the real run metadata it produced:

{
  "runId": "xr2ExvBEZggZ7OeoX",
  "actorName": "scrapers_lat/nhtsa-vin-decoder-scraper",
  "status": "SUCCEEDED",
  "startedAt": "2026-07-30T17:43:50.777Z",
  "finishedAt": "2026-07-30T17:43:59.361Z",
  "stats": { "runTimeSecs": 8.4 }
}

Under nine seconds, live against the official database.

Step 5: Read the real output

The dataset the tool returns is a structured specification record. This is an actual record from the run (trimmed to the fields that matter for identifying and pricing the car):

{
  "vin": "5YJ3E1EA7JF006588",
  "make": "TESLA",
  "model": "Model 3",
  "modelYear": "2018",
  "bodyClass": "Sedan/Saloon",
  "vehicleType": "PASSENGER CAR",
  "basePrice": 46000,
  "doors": 4,
  "seats": 5,
  "fuelTypePrimary": "Electric",
  "electrificationLevel": "BEV (Battery Electric Vehicle)",
  "otherEngineInfo": "Single Motor - Standard",
  "transmissionStyle": "Automatic",
  "manufacturer": "TESLA, INC.",
  "plantCity": "FREMONT",
  "plantState": "CALIFORNIA",
  "plantCountry": "UNITED STATES (USA)"
}

Claude reads that and answers in plain language: this VIN is a 2018 Tesla Model 3, a four-door Sedan/Saloon passenger car, a battery-electric vehicle with a single standard motor and automatic transmission, built by Tesla, Inc. in Fremont, California, with a base price of $46,000. Every one of those facts is traceable to the official record for that exact VIN, not the model's memory. The full record carries dozens more fields, GVWR class, ABS, ESC, TPMS, airbag locations, and driver-assist features such as forward-collision warning, blind-spot monitor, and lane-keep, that a pricing or safety workflow can read straight through.

The value shows up most on ambiguous cars. Feed the decoder a VIN like 1HGCM82633A004352 and it comes back as a 2003 Honda Accord Coupe, two doors, a 3.0-liter V6, gasoline, automatic, built in Marysville, Ohio. The trim and engine that a human would have to look up by hand are already in the record. An agent doing this at scale never has to open a VIN-lookup website.

A real use case: an intake agent for vehicle listings

Put this in context. An auto marketplace, an insurer, or a fleet operator takes in vehicles by VIN all day. Before a car can be listed, quoted, or added to a fleet register, someone has to turn that 17-character string into structured facts: what it is, how it is powered, how many doors and seats, what safety equipment it carries, and where it was built.

Without a tool, an analyst opens a VIN-decoder site, pastes the number, waits for the page, and copies fields into a form, once per vehicle. With the decoder wired into Claude, the analyst pastes a batch of VINs into the chat and asks the agent to normalize them. Claude calls the Actor, reads back make, model, year, body class, fuel type, and safety features for each one, flags the electric vehicles for a different rate class, and produces a clean table ready to import. The mechanical decode step disappears; the underwriting or pricing judgment stays with the human.

This is the shape of every good agent tool: it removes the mechanical fetch, not the decision.

Going further: chain a second tool

Decoding a VIN tells you what the car is. The next question a serious workflow asks is whether that exact vehicle has any open safety problems. The same MCP connection can expose more Actors by extending the tools parameter:

https://mcp.apify.com?tools=scrapers_lat/nhtsa-vin-decoder-scraper,scrapers_lat/nhtsa-recalls-scraper

Now the agent can decode the VIN into make, model, and year with the first tool, then pass those straight into the NHTSA Vehicle Recalls & Complaints Scraper to pull any open recalls and owner complaints for that vehicle, and combine both into a single condition summary in one conversation. Because each Actor is a separate tool, the agent picks the right one for each step on its own: identify first, then check safety history.

🏹 Troubleshooting: if the tool does not appear in Claude, the two usual causes are a missing or misspelled Actor handle in the tools parameter (it must be the exact username/actor-name from the Store URL) and a config that was edited while Claude was running. Fix the handle, save, and fully restart the client.

📌 Note: each tool call is a real Actor run billed to your Apify account (this Actor is pay-per-result). Decoding a single VIN in a chat costs a fraction of a cent. If you plan to decode thousands of VINs on a schedule, send them to the Actor in batches through the Apify API or a scheduled task rather than one call per chat message; the same Actor accepts a whole list at once.

Wrapping up

You now have an AI agent that can turn any VIN into a full, authoritative vehicle specification, on demand, mid-conversation, with the body, powertrain, safety, and plant detail that pricing and intake workflows actually need. The pattern is reusable: pick an Actor that returns authoritative structured data, expose it through the Apify MCP server with the tools parameter, and let the agent decide when to call it.

To take it further:

• Feed the decoder a batch of VINs at once to normalize an entire intake queue in a single call.
• Add the recalls Actor, a market-pricing Actor, or a title-history Actor to build a multi-step vehicle-intelligence agent.
• Read the Apify MCP server docs for OAuth setup, resource reads, and the search-actors / call-actor tools that let an agent discover Actors it was not preconfigured with.

The Actor used in this guide: NHTSA VIN Decoder & Vehicle Specs Scraper.