OnlineCyberTools MCP (280+ filterable tools)

osint_vin_decoder

Read-only

Decode 17-character VINs to identify vehicle manufacturer, origin country, model year, and assembly plant using built-in lookup tables. Validates check digit and provides per-VIN decoded info.

Instructions

VIN Decoder (Vehicle Identification Number Lookup). Decode one or more 17-character Vehicle Identification Numbers using built-in deterministic lookup tables (WMI manufacturer, country/region, model-year code, assembly plant) and validate the position-9 check digit. Use it to identify a vehicle's maker, origin country, and model year offline; use osint_ean_upc_validator or osint_isbn_validator instead for product/book codes, and osint_credit_card_validator for PAN Luhn checks. Pure local compute — no VIN database, NHTSA vPIC, or other external API is contacted; read-only and non-destructive. Each result embeds the decode timestamp, so responses are not byte-identical across calls. Rate-limited (20 requests/min anonymous). Rejects VINs not exactly 17 chars or containing I, O, or Q. Returns per-VIN decoded info, optional segment breakdown, validity, warnings, and a batch summary.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`vins`	Yes	VINs to decode. Each is uppercased/trimmed; non-strings and entries not matching 17 chars of A-H,J-N,P-R,Z,0-9 are dropped before decoding.
`options`	No	Optional decoding flags.

Output Schema

TableJSON Schema

Name	Required	Description
`success`	No	True when at least one valid VIN was decoded.
`results`	No	One entry per accepted VIN.
`summary`	No	Batch counts.
`note`	No	Fixed disclosure that decoding is local validation plus deterministic lookup tables.
`processing_info`	No	Echo of the resolved option flags (validate_check_digit, include_manufacturer_info, detailed_breakdown).

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.5.1Jun 3, 2026

changedInput schema / additionalProperties
```
Previous value: -trueNew value: +false
```

addedInput schema / properties

Added value: +{
+  "options": {
+    "additionalProperties": false,
+    "description": "Optional decoding flags.",
+    "properties": {
+      "detailed_breakdown": {
+        "default": false,
+        "description": "When true, adds the per-segment breakdown object (WMI, VDS, check digit, year, plant, serial).",
+        "type": "boolean"
+      },
+      "include_manufacturer_info": {
+        "default": true,
+        "description": "When true, populates the info object (manufacturer, country, modelYear, vehicleType, assemblyPlant).",
+        "type": "boolean"
+      },
+      "validate_check_digit": {
+        "default": true,
+        "description": "When true, recomputes the position-9 check digit and adds a warning if it fails.",
+        "type": "boolean"
+      }
+    },
+    "type": "object"
+  },
+  "vins": {
+    "description": "VINs to decode. Each is uppercased/trimmed; non-strings and entries not matching 17 chars of A-H,J-N,P-R,Z,0-9 are dropped before decoding.",
+    "items": {
+      "type": "string"
+    },
+    "minItems": 1,
+    "type": "array"
+  }
+}

addedInput schema / required
```
Added value: +[
+  "vins"
+]
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "note": {
+      "description": "Fixed disclosure that decoding is local validation plus deterministic lookup tables.",
+      "type": "string"
+    },
+    "processing_info": {
+      "description": "Echo of the resolved option flags (validate_check_digit, include_manufacturer_info, detailed_breakdown).",
+      "type": "object"
+    },
+    "results": {
+      "description": "One entry per accepted VIN.",
+      "items": {
+        "properties": {
+          "breakdown": {
+            "description": "Per-segment breakdown; empty unless detailed_breakdown is true.",
+            "type": "object"
+          },
+          "info": {
+            "description": "Decoded fields: manufacturer, country, modelYear, vehicleType, assemblyPlant. Empty when include_manufacturer_info is false.",
+            "type": "object"
+          },
+          "timestamp": {
+            "description": "Unix epoch seconds when decoded.",
+            "type": "integer"
+          },
+          "valid": {
+            "description": "Whether the VIN passed format validation.",
+            "type": "boolean"
+          },
+          "vin": {
+            "description": "Normalized (uppercased, trimmed) VIN.",
+            "type": "string"
+          },
+          "warnings": {
+            "description": "Decode warnings (e.g. failed check digit, ambiguous year, unknown manufacturer).",
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "success": {
+      "description": "True when at least one valid VIN was decoded.",
+      "type": "boolean"
+    },
+    "summary": {
+      "description": "Batch counts.",
+      "properties": {
+        "invalid_vins": {
+          "description": "Count that failed validation.",
+          "type": "integer"
+        },
+        "total_vins": {
+          "description": "Number of accepted VINs.",
+          "type": "integer"
+        },
+        "valid_vins": {
+          "description": "Count that passed validation.",
+          "type": "integer"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "type": "object"
+}

First observedv0.1.0May 31, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes beyond annotations by detailing offline computation (no external API), non-destructive nature, timestamp embedding causing non-idempotent responses, rate limit (20/min anonymous), and input rejection criteria (exactly 17 chars, no I/O/Q). No contradictions with annotations.

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?

Description is comprehensive but slightly verbose; however, it is front-loaded with the main purpose and well-structured. Every sentence adds value.

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?

Given the tool's batch nature and available schema/output schema, the description fully covers input constraints, behavior, limitations, and output structure (per-VIN info, breakdown, validity, warnings, summary). No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds meaning beyond schema: describes input normalization (uppercased/trimmed), filtering of invalid entries, and explains each option field (validate_check_digit, include_manufacturer_info, detailed_breakdown) with behavior flags.

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 clearly states it decodes VINs using built-in tables and check digit validation, and distinguishes itself from sibling tools like osint_ean_upc_validator, osint_isbn_validator, and osint_credit_card_validator, making the purpose unmistakable.

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 when to use this tool (VIN decoding) and when not to (product/book codes, PAN Luhn checks), naming specific alternatives. Also notes it's offline and rate-limited.

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

Deploy Server