nhtsa-vehicle-safety-mcp-server

Name: nhtsa-vehicle-safety-mcp-server
Author: cyanheads

Server Details

Decode VINs, search recalls, complaints, crash ratings, and investigations.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-06 04:35
Transport: Streamable HTTP
URL
Repository: cyanheads/nhtsa-vehicle-safety-mcp-server
GitHub Stars: 1
Server Listing: nhtsa-vehicle-safety-mcp-server

Available Tools

7 tools

nhtsa_decode_vinNhtsa Decode VinA

Read-only

Inspect

Decode a Vehicle Identification Number to extract make, model, year, body type, engine, safety equipment, and manufacturing details. Pass a single 17-character VIN string, or an array of up to 50 VINs for batch decode. Partial VINs accepted — use * for unknown positions.

ParametersJSON Schema

Name	Required	Description	Default
`vin`	Yes	A single 17-character VIN (e.g., "1HGCM82633A004352") or an array of up to 50 VINs for batch decode. Partial VINs accepted — use * for unknown positions.
`modelYear`	No	Model year, a whole number. Helps resolve ambiguity for pre-1980 or partial VINs.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Present when one or more VINs decoded with VPIC warnings (errorCode != 0) — check errorCode/errorText per vehicle.
`vehicles`	No	Decoded vehicle information per VIN
`effectiveQuery`	No	Number of VINs decoded and the path taken (single or batch).

TDQS

A4.3/5.0

Behavior4/5

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

The description adds behavioral context beyond the readOnlyHint annotation by disclosing batch decoding capacity and partial VIN wildcard behavior. No contradictions with annotations exist, though details about error handling or response structure are left to the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-load the core purpose and then deliver key usage constraints. Every sentence carries useful information, with no filler or redundancy.

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 presence of a complete input schema, output schema, and a readOnlyHint annotation, the description covers the remaining essentials: purpose, batch limits, and partial VIN behavior. Nothing critical is missing for an agent to invoke the tool correctly.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema already documents the VIN format, batch limit, wildcard usage, and modelYear purpose. The description reinforces these details but does not add meaningful semantics beyond what the input schema already provides.

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 uses a specific verb ('Decode') with a clear resource ('Vehicle Identification Number') and enumerates extracted attributes such as make, model, year, body type, and engine. This clearly distinguishes it from sibling tools focused on safety ratings, recalls, or complaints.

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?

The description gives concrete invocation guidance: pass a single VIN or an array of up to 50, and partial VINs may use '*' for unknown positions. It does not explicitly mention alternatives or when not to use the tool, but the context is clear and self-contained.

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

nhtsa_get_safety_ratingsNhtsa Get Safety RatingsA

Read-only

Inspect

Get NCAP crash test ratings and ADAS feature availability for a vehicle. Use when the user specifically wants crash test stars, rollover risk, or wants to compare safety features across vehicles. NCAP data available from 1990+, best coverage for 2011+.

ParametersJSON Schema

Name	Required	Description
`make`	No	Vehicle manufacturer. Required with model and modelYear when vehicleId is omitted.
`model`	No	Vehicle model. Required with make and modelYear when vehicleId is omitted.
`modelYear`	No	Model year, a whole number. Required with make and model when vehicleId is omitted. NCAP coverage increases significantly for 2011+.
`vehicleId`	No	Specific NCAP vehicle ID (from prior results). Skips the year/make/model lookup.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Guidance when no NCAP ratings are found — e.g. coverage notes or adjacent year suggestion.
`ratings`	No	Safety ratings per vehicle variant

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already include readOnlyHint=true, and the description's 'get' verb is consistent. It adds some context (coverage years) but doesn't disclose limitations like missing data for some models or that results may be empty. With annotations covering side effects, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences front-load the core purpose and usage guidance. No filler or repetition. The coverage note is useful and concise.

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?

Output schema is present, so return values are covered. The description includes purpose, usage, and data coverage. What's missing is an explicit note about what happens if no ratings are found, but the readOnlyHint and schema cover most behavior.

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

Parameters3/5

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

Schema coverage is 100%, so all 4 parameters are described structurally. The description adds no additional meaning beyond the schema (e.g., no relationship between parameters or format requirements). Baseline 3 applies.

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?

The description clearly states the tool's purpose: 'Get NCAP crash test ratings and ADAS feature availability for a vehicle.' The verb and resource are specific, but it doesn't explicitly distinguish itself from the sibling tool 'nhtsa_get_vehicle_safety', so it falls short of full differentiation.

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?

Says explicitly when to use: 'when the user specifically wants crash test stars, rollover risk, or wants to compare safety features across vehicles.' It also mentions data coverage (2011+). However, it doesn't state when not to use or name alternative tools, so it's not a full 5.

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

nhtsa_get_vehicle_safetyNhtsa Get Vehicle SafetyA

Read-only

Inspect

Get a comprehensive safety profile for a vehicle. Combines NCAP crash test ratings, recalls, and complaint summary into a single response. Use as the default when asked about vehicle safety, reliability, or purchase decisions.

ParametersJSON Schema

Name	Required	Description
`make`	Yes	Vehicle manufacturer (e.g., "Toyota", "Ford"). Case-insensitive.
`model`	Yes	Vehicle model (e.g., "Camry", "F-150"). Case-insensitive.
`modelYear`	Yes	Model year, a whole number (e.g., 2020).

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Guidance when no NHTSA records matched the vehicle — e.g. how to verify make/model/year spelling.
`recalls`	No	All recalls for this vehicle when available
`warnings`	No	Warnings about sections that could not be loaded from NHTSA
`safetyRatings`	No	Crash test ratings per vehicle variant (e.g., FWD vs AWD)
`sectionStatus`	No	Availability of each data section in this response
`effectiveQuery`	No	The vehicle queried, as "make model modelYear".
`complaintSummary`	No	Summary of consumer complaints

TDQS

A4.3/5.0

Behavior4/5

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

With readOnlyHint=true, the safety profile is already covered. The description adds meaningful behavioral context by disclosing that the tool aggregates multiple data sources (ratings, recalls, complaints) into a single combined response. This is more informative than a simple read operation and helps set expectations for the returned payload.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two crisp sentences accomplish the goal with no filler. The first sentence scopes the purpose and contents, and the second gives immediate usage direction. Every word 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?

For a read-only aggregating tool with a rich output schema and three fully described parameters, the description is sufficient. The agent knows what data to expect, when to use it, and that the result is a single response. No important operational detail is missing for the typical calling scenario.

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

Parameters3/5

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

The input schema has 100% description coverage for all three parameters (make, model, modelYear), so the schema already carries the parameter meaning. The tool description does not add extra detail about how these parameters are used together; it only generically refers to 'a vehicle', so the schema remains the primary source of parameter semantics.

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 states a specific verb ('Get') and clearly defines the resource as a comprehensive safety profile combining NCAP crash ratings, recalls, and complaint summaries. This distinguishes it from sibling tools that cover only one of these areas, so an agent can immediately identify how it differs.

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?

The description explicitly says to use this tool as the default when asked about vehicle safety, reliability, or purchase decisions, which is strong guidance. However, it doesn't explicitly name alternatives or state when NOT to use it, such as when a user specifically wants only recalls or only crash ratings without the combined context.

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

nhtsa_lookup_vehiclesNhtsa Lookup VehiclesA

Read-only

Inspect

Look up valid makes, models, and vehicle types in NHTSA's database. Use to resolve ambiguous vehicle names, find correct make/model spelling, or discover what models a manufacturer produces.

ParametersJSON Schema

Name	Required	Description
`make`	No	Make name (required for "models" and "vehicle_types"). Partial match supported.
`limit`	No	Max results in the returned slice. Defaults to 100; max 200.
`offset`	No	Pagination offset into the full result list. Defaults to 0.
`modelYear`	No	Filter models to a specific year, a whole number. Only for "models" operation.
`operation`	Yes	"makes" (all NHTSA makes), "models" (models for a make), "vehicle_types" (types for a make), "manufacturer" (manufacturer details).
`manufacturer`	No	Manufacturer name or ID (for "manufacturer" operation). Partial match supported.

Output Schema

ParametersJSON Schema

Name	Required	Description
`cap`	No	Maximum manufacturer records a single lookup retrieves.
`error`	No	Present when the call failed. Absent on success.
`limit`	No	Pagination limit used for this response
`makes`	No	Results for "makes" operation
`shown`	No	Manufacturer records retrieved before pagination, when the cap was reached.
`models`	No	Results for "models" operation
`notice`	No	Guidance when the result set is empty or the page is out of bounds.
`offset`	No	Pagination offset used for this response
`returned`	No	Number of results in the returned slice
`operation`	No	The operation that was performed
`truncated`	No	True when the "manufacturer" lookup stopped at its retrieval cap and further matches may exist upstream.
`totalCount`	No	Results retrieved before pagination. For "manufacturer" this is capped — check the truncated field, since VPIC reports no match total.
`vehicleTypes`	No	Results for "vehicle_types" operation
`manufacturers`	No	Results for "manufacturer" operation
`effectiveQuery`	No	The operation with key args, e.g. "models make=Toyota year=2020".

TDQS

A4.1/5.0

Behavior4/5

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

Annotations provide readOnlyHint: true, so the agent knows this is a safe read operation. The description adds value by explaining the tool's role as a lookup/reference, which implies no side effects. It also mentions partial match support and pagination parameters in the schema, but the description itself doesn't disclose behaviors like rate limits or data freshness. Given the annotation covers safety, the description's additional context on discovery is useful, but it doesn't delve into specifics of the data source or any quirks. With annotations present, a 4 is justified as the description complements rather than repeats them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, two-sentence paragraph. It is concise, with the core purpose stated upfront and then usage scenarios. Every word adds value: it names the tool's function and provides concrete examples of when to use it. No filler or redundant information. This is an exemplar of conciseness for a tool description.

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?

Given the tool has a rich input schema (6 parameters, one with enum) and an output schema (as indicated by 'has output schema: true'), the description doesn't need to explain return values or parameter details. The description is complete for the tool's purpose: it tells the agent what the tool does and when to use it. The schema handles parameter specifics, and annotations handle safety. The only slight gap is that it doesn't explicitly mention pagination behavior, but the schema covers that (offset/limit). Overall, the description is sufficient for an agent to use the tool correctly.

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 description coverage is 100%, meaning each parameter has a description. The tool description itself doesn't repeat parameter details, but it explains the overall purpose (e.g., 'find correct make/model spelling') which indirectly clarifies how parameters like 'make' and 'operation' are intended to be used. Since schema already documents each parameter, the description adds context by framing the tool's use case, which helps an agent understand parameter interactions. This goes slightly beyond baseline 3 because it clarifies the high-level semantics of the operations.

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?

The description clearly states the tool's purpose: to look up valid makes, models, and vehicle types in NHTSA's database. It uses a specific verb ('look up') and resource ('NHTSA's database'), and lists concrete use cases. While it doesn't explicitly differentiate from siblings, the sibling names (e.g., nhtsa_decode_vin, nhtsa_get_safety_ratings) suggest different domains, and the description's focus on lookup/discovery distinguishes it from those. However, it doesn't explicitly state what it is NOT, so it falls short of a 5.

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?

The description provides clear context on when to use the tool: 'Use to resolve ambiguous vehicle names, find correct make/model spelling, or discover what models a manufacturer produces.' This gives specific scenarios for usage. However, it doesn't explicitly mention alternatives or conditions where another tool should be used instead, which prevents a 5. The guidance is clear enough for an agent to decide, but it lacks explicit exclusions.

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

nhtsa_search_complaintsNhtsa Search ComplaintsA

Read-only

Inspect

Search consumer safety complaints filed with NHTSA for a specific vehicle. Returns a component breakdown over all matching complaints plus a paginated slice of the most recent complaints. Use for common problems, failure patterns, or owner-reported issues.

ParametersJSON Schema

Name	Required	Description
`make`	Yes	Vehicle manufacturer.
`limit`	No	Max complaint narratives to return. Defaults to 20; max 50. componentBreakdown always reflects all matching complaints.
`model`	Yes	Vehicle model.
`offset`	No	Pagination offset into the filing-date-descending complaint list. Defaults to 0. componentBreakdown is unaffected by pagination.
`component`	No	Filter to a specific component (uppercase, e.g., "ENGINE", "AIR BAGS", "ELECTRICAL SYSTEM"). Matches within comma-separated component lists. Omit to see all.
`modelYear`	Yes	Model year, a whole number.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`limit`	No	Pagination limit used for this page
`notice`	No	Guidance when no complaints match the vehicle, or when the requested page overshoots the result set.
`offset`	No	Pagination offset used for this page
`returned`	No	Number of complaints in this page
`complaints`	No	Paginated slice of the most recent complaints, date-descending
`totalCount`	No	Total complaints matching criteria
`effectiveQuery`	No	"make model modelYear" with optional component filter applied, as the server used it.
`componentBreakdown`	No	Complaints grouped by component, sorted by frequency

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true.lukas The description adds valuable behavioral details: it returns a component breakdown across all complaints plus a paginated slice of the most recent ones, and notes that the breakdown is unaffected by pagination. This is context beyond the annotation and helps the agent understand what results to expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states exactly what the tool does and returns; second gives the recommendation for when to use it. No fluff, no ambiguity. Excellent structure for agent consumption.

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 tool with complete schema documentation, the description covers purpose, result structure, and usage context. Nothing critical is missing. Pagination behavior is clarified, which is a potential source of confusion. Output structure is mentioned (component breakdown + paginated complaints). This is complete for an agent to decide and call correctly.

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?

The input schema provides complete descriptions for all 6 parameters (100% coverage). The description complements this by clarifying the result structure and the component filter's behavior. It adds semantic value about pagination and componentBreakdown, though the schema itself is thorough. Credit for the description's clarification of how offset/component interact with the breakdown.

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 states a specific verb ('search'), resource ('consumer safety complaints'), and a clear target ('filed with NHTSA for a specific vehicle'). It also distinguishes itself from siblings by focusing on complaints rather than recalls, ratings, or VIN lookups. An agent can clearly identify this as the complaints search tool.

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?

Provides a clear usage context: 'Use for common problems, failure patterns, or owner-reported issues.' While it doesn't explicitly list alternatives or when not to use it, the phrasing implies it's for complaints rather than recalls or ratings. No exclusions, but the purpose is distinct enough from sibling tools.

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

nhtsa_search_investigationsNhtsa Search InvestigationsA

Read-only

Inspect

Search NHTSA defect investigations from the ODI flat file — covering Preliminary Evaluations (PE), Engineering Analyses (EA), Defect Petitions (DP), Recall Queries (RQ), Audit Queries (AQ), and additional ODI types. make, model, and component are structured filters against the investigation record's vehicle associations. All filters are ANDed. Use nhtsaId to fetch one investigation by its exact ID — including the investigationId nhtsa_search_recalls returns for a campaign. Investigations may link to a resulting recall campaign via recallCampaign.

ParametersJSON Schema

Name	Required	Description
`make`	No	Structured filter — matches against the investigation's associated vehicle makes (e.g., "TOYOTA"). ANDed with other filters.
`limit`	No	Max investigations to return. Defaults to 20; max 25. The cap is lower than the other paginated tools because a single investigation summary can run several thousand characters and is rendered in full.
`model`	No	Structured filter — matches against the investigation's associated vehicle models. ANDed with other filters.
`query`	No	Free-text search across investigation ID, subject, and summary.
`offset`	No	Pagination offset into the matching investigations. Defaults to 0.
`status`	No	Filter by status: "O" (Open) or "C" (Closed). Omit to include both.
`nhtsaId`	No	Exact NHTSA investigation ID (e.g. "EA23003"), case-insensitive. Fetches that one record — mutually exclusive with every other filter.
`component`	No	Structured filter — matches against the investigation's affected components (e.g., "STEERING"). ANDed with other filters.
`investigationType`	No	Filter by ODI investigation type code (the leading letters of the NHTSA ID). Named types: "PE" (Preliminary Evaluation), "EA" (Engineering Analysis), "DP" (Defect Petition), "RQ" (Recall Query), "AQ" (Audit Query). Additional valid codes present in the dataset: "SQ", "EQ", "RP", "ID", "TA", "C". Pass any code exactly as it appears in the investigation ID prefix.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`limit`	No	Pagination limit used for this page
`notice`	No	Guidance when no investigations match the filters, or when the requested page overshoots the result set.
`offset`	No	Pagination offset used for this page
`returned`	No	Number of investigations in this page
`totalCount`	No	Total matching investigations
`effectiveQuery`	No	Applied filters as a readable string, e.g. make="Ford" status="O".
`investigations`	No	Matching investigations

TDQS

A4.3/5.0

Behavior4/5

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

The readOnlyHint annotation already signals safety, and the description adds valuable behavior details such as pagination (`offset`, `limit`) and the mutual exclusivity of `nhtsaId` with other filters, plus the case-insensitive fetching of a single record. This goes beyond the annotation without contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence contributes: purpose, filter types, mutual exclusivity, and pagination details. It is well-structured, front-loaded with the core purpose, and avoids redundancy or filler.

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?

The description fully equips a user to call the tool: it covers all filters, explains mutual exclusivity, pagination behavior, investigation type codes, and the single-record fetch mode. Since an output schema exists, return values need not be described. No critical usage gaps remain.

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?

All nine parameters have schema descriptions (100% coverage), and the description adds extra semantics beyond those: `nhtsaId` is case-insensitive and mutually exclusive, `investigationType` explains the leading-letter prefix and lists additional valid codes, and `query` covers specific fields. This enriches parameter understanding beyond the raw 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 clearly states the tool searches NHTSA defect investigations from the ODI flat file, listing coverage of specific investigation types (PE, EA, DP, RQ, AQ, and additional types). It uses a specific verb and resource, making its intent unambiguous and distinct from sibling tools like recalls or complaints.

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?

The description explains the tool's scope and filter behavior but does not explicitly mention when to use it over sibling tools (e.g., search_recalls) or provide exclusions. While the coverage types imply a focused use case, explicit guidance on alternatives is missing.

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

nhtsa_search_recallsNhtsa Search RecallsA

Read-only

Inspect

Search recall campaigns by vehicle or campaign number. Use for specific recall lookups, recall history for a vehicle, or looking up a known campaign number.

ParametersJSON Schema

Name	Required	Description
`make`	No	Vehicle manufacturer. Required with model and modelYear when not using campaignNumber.
`model`	No	Vehicle model. Required with make and modelYear.
`dateRange`	No	Filter recalls by received date. Applied locally since the API lacks native date filtering.
`modelYear`	No	Model year, a whole number. Required with make and model.
`campaignNumber`	No	NHTSA campaign number (e.g., "20V682000"). When provided, returns the campaign detail plus every vehicle it covers. Mutually exclusive with make/model/modelYear.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Guidance when no recalls are found — e.g. how to verify make/model/year spelling.
`recalls`	No	Matching recall campaigns
`totalCount`	No	Total recalls matching criteria
`effectiveQuery`	No	The search key used: campaign number, or "make model modelYear" for vehicle queries.

TDQS

A4/5.0

Behavior3/5

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

readOnlyHint=true already covers the non-mutating safety profile, so the description does not contradict annotations. However, the description itself adds little behavioral detail beyond the obvious search semantics, such as return behavior, pagination, rate limits, or the local dateRange filtering; the schema notes the local filtering, but the top-level description does not.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two clean sentences, front-loading the core function first and then adding meaningful use-case context. Every phrase contributes useful information, and there is no redundancy or unnecessary jargon.

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?

The presence of a complete input schema and output schema reduces the burden on the description. It explains the main situations in which the tool should be used, and the schema handles the parameter details. A small gap remains because the description does not mention how dateRange is applied locally or how campaignNumber expands to vehicle coverage, but those are covered by schema text.

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

Parameters3/5

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

Schema description coverage is 100%, with each parameter already explaining its role and constraints, including mutual exclusivity between campaignNumber and vehicle fields. The description phrase 'by vehicle or campaign number' adds a helpful framing but no additional types, requirements, or formats beyond what the schema contains.

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 identifies the resource (recall campaigns) and the operation (search), and enumerates the two entry points: vehicle details or campaign number. It is unmistakably different from sibling tools by name and content, which are about complaints, investigations, ratings, VIN decoding, and vehicle lookup.

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?

The description gives explicit use cases: specific recall lookups, recall history for a vehicle, and known campaign number lookups. It does not explicitly say when not to use the tool or point to a specific alternative, so it falls just short of a 5, but enough context for most agents to choose correctly.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesAug 21, 2026

Changednhtsa_decode_vin6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "vehicles",
+      "effectiveQuery"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `empty_vin_list`: No non-empty VIN strings supplied. `batch_too_large`: VIN array exceeds the batch limit. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "empty_vin_list",
+            "batch_too_large"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}

removedOutput schema / required

Removed value: -[
-  "vehicles",
-  "effectiveQuery"
-]

Changednhtsa_get_safety_ratings6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "ratings"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `missing_required_combo`: Neither vehicleId nor a complete vehicle triple was supplied. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "missing_required_combo"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}

removedOutput schema / required
```
Removed value: -[
-  "ratings"
-]
```

Changednhtsa_get_vehicle_safety6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "sectionStatus",
+      "warnings",
+      "effectiveQuery"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode.",
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}

removedOutput schema / required

Removed value: -[
-  "sectionStatus",
-  "warnings",
-  "effectiveQuery"
-]

Changednhtsa_lookup_vehicles6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "operation",
+      "totalCount",
+      "returned",
+      "offset",
+      "limit",
+      "effectiveQuery"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `missing_operation_arg`: A required argument for the chosen operation was not provided. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "missing_operation_arg"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}

removedOutput schema / required

Removed value: -[
-  "operation",
-  "totalCount",
-  "returned",
-  "offset",
-  "limit",
-  "effectiveQuery"
-]

Changednhtsa_search_complaints6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "totalCount",
+      "returned",
+      "offset",
+      "limit",
+      "componentBreakdown",
+      "complaints",
+      "effectiveQuery"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode.",
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}

removedOutput schema / required

Removed value: -[
-  "totalCount",
-  "returned",
-  "offset",
-  "limit",
-  "componentBreakdown",
-  "complaints",
-  "effectiveQuery"
-]

Changednhtsa_search_investigations6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "totalCount",
+      "returned",
+      "offset",
+      "limit",
+      "investigations",
+      "effectiveQuery"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `mode_conflict`: nhtsaId was combined with another filter. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "mode_conflict"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}

removedOutput schema / required

Removed value: -[
-  "totalCount",
-  "returned",
-  "offset",
-  "limit",
-  "investigations",
-  "effectiveQuery"
-]

Changednhtsa_search_recalls6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "recalls",
+      "totalCount",
+      "effectiveQuery"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `mode_conflict`: Both campaignNumber and vehicle params were provided. `missing_required_combo`: Neither campaignNumber nor a complete vehicle triple was supplied. `campaign_not_found`: The campaignNumber did not match any NHTSA recall. `invalid_date`: A dateRange bound could not be parsed as a date. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "mode_conflict",
+            "missing_required_combo",
+            "campaign_not_found",
+            "invalid_date"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}

removedOutput schema / required

Removed value: -[
-  "recalls",
-  "totalCount",
-  "effectiveQuery"
-]

2 tool updatesJul 30, 2026

Changednhtsa_search_complaints2 fields changed

addedOutput schema / properties / complaints / items / properties / unreliableIncidentDate

Added value: +{
+  "additionalProperties": false,
+  "description": "An incident date NHTSA reported that this complaint's own filing date or model year rules out — report it as contradicted, never as when the incident happened. Appears in place of dateOfIncident, never alongside it; both absent means NHTSA reported no incident date at all.",
+  "properties": {
+    "reason": {
+      "description": "What the reported date contradicts: \"postdates_filing\" — it falls after this complaint was filed; \"predates_model_year\" — it falls before a vehicle of this model year existed.",
+      "enum": [
+        "postdates_filing",
+        "predates_model_year"
+      ],
+      "type": "string"
+    },
+    "reported": {
+      "description": "The incident date NHTSA reported, ISO YYYY-MM-DD",
+      "type": "string"
+    }
+  },
+  "required": [
+    "reported",
+    "reason"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / notice / description

Previous value: -"Guidance when no complaints are found — e.g. how to verify make/model/year spelling."New value: +"Guidance when no complaints match the vehicle, or when the requested page overshoots the result set."

Changednhtsa_search_investigations1 field changed

changedOutput schema / properties / notice / description

Previous value: -"Guidance when no investigations match — e.g. suggestions for broadening the search."New value: +"Guidance when no investigations match the filters, or when the requested page overshoots the result set."

7 tool updatesJul 30, 2026

Changednhtsa_decode_vin4 fields changed

changedInput schema / properties / modelYear / description

Previous value: -"Helps resolve ambiguity for pre-1980 VINs or partial VINs."New value: +"Model year, a whole number. Helps resolve ambiguity for pre-1980 or partial VINs."

addedInput schema / properties / modelYear / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / modelYear / minimum
```
Added value: +-9007199254740991
```
changedInput schema / properties / modelYear / type
```
Previous value: -"number"New value: +"integer"
```

Changednhtsa_get_safety_ratings4 fields changed

changedInput schema / properties / modelYear / description

Previous value: -"Model year. Required with make and model when vehicleId is omitted. NCAP coverage increases significantly for 2011+."New value: +"Model year, a whole number. Required with make and model when vehicleId is omitted. NCAP coverage increases significantly for 2011+."

addedInput schema / properties / modelYear / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / modelYear / minimum
```
Added value: +-9007199254740991
```
changedInput schema / properties / modelYear / type
```
Previous value: -"number"New value: +"integer"
```

Changednhtsa_get_vehicle_safety4 fields changed
- changedInput schema / properties / modelYear / description
```
Previous value: -"Model year (e.g., 2020)."New value: +"Model year, a whole number (e.g., 2020)."
```
- addedInput schema / properties / modelYear / maximum
```
Added value: +9007199254740991
```
- addedInput schema / properties / modelYear / minimum
```
Added value: +-9007199254740991
```
- changedInput schema / properties / modelYear / type
```
Previous value: -"number"New value: +"integer"
```

Changednhtsa_lookup_vehicles8 fields changed

changedInput schema / properties / modelYear / description

Previous value: -"Filter models to a specific year. Only for \"models\" operation."New value: +"Filter models to a specific year, a whole number. Only for \"models\" operation."

addedInput schema / properties / modelYear / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / modelYear / minimum
```
Added value: +-9007199254740991
```
changedInput schema / properties / modelYear / type
```
Previous value: -"number"New value: +"integer"
```

addedOutput schema / properties / cap

Added value: +{
+  "description": "Maximum manufacturer records a single lookup retrieves.",
+  "type": "number"
+}

addedOutput schema / properties / shown

Added value: +{
+  "description": "Manufacturer records retrieved before pagination, when the cap was reached.",
+  "type": "number"
+}

changedOutput schema / properties / totalCount / description

Previous value: -"Total results matching before pagination"New value: +"Results retrieved before pagination. For \"manufacturer\" this is capped — check the truncated field, since VPIC reports no match total."

addedOutput schema / properties / truncated

Added value: +{
+  "description": "True when the \"manufacturer\" lookup stopped at its retrieval cap and further matches may exist upstream.",
+  "type": "boolean"
+}

Changednhtsa_search_complaints7 fields changed

changedInput schema / properties / modelYear / description

Previous value: -"Model year."New value: +"Model year, a whole number."

addedInput schema / properties / modelYear / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / modelYear / minimum
```
Added value: +-9007199254740991
```
changedInput schema / properties / modelYear / type
```
Previous value: -"number"New value: +"integer"
```

changedInput schema / properties / offset / description

Previous value: -"Pagination offset into the date-descending complaint list. Defaults to 0. componentBreakdown is unaffected by pagination."New value: +"Pagination offset into the filing-date-descending complaint list. Defaults to 0. componentBreakdown is unaffected by pagination."

changedOutput schema / properties / complaints / items / properties / dateComplaintFiled / description

Previous value: -"Date complaint was filed"New value: +"Date complaint was filed (ISO YYYY-MM-DD)"

changedOutput schema / properties / complaints / items / properties / dateOfIncident / description

Previous value: -"Date the incident occurred"New value: +"Date the incident occurred (ISO YYYY-MM-DD)"

Changednhtsa_search_investigations2 fields changed

addedInput schema / properties / nhtsaId

Added value: +{
+  "description": "Exact NHTSA investigation ID (e.g. \"EA23003\"), case-insensitive. Fetches that one record — mutually exclusive with every other filter.",
+  "type": "string"
+}

changedInput schema / properties / query / description

Previous value: -"Free-text search across investigation subject and summary."New value: +"Free-text search across investigation ID, subject, and summary."

Changednhtsa_search_recalls9 fields changed

changedInput schema / properties / campaignNumber / description

Previous value: -"NHTSA campaign number (e.g., \"20V682000\"). When provided, returns campaign details. Other params ignored."New value: +"NHTSA campaign number (e.g., \"20V682000\"). When provided, returns the campaign detail plus every vehicle it covers. Mutually exclusive with make/model/modelYear."

changedInput schema / properties / modelYear / description

Previous value: -"Model year. Required with make and model."New value: +"Model year, a whole number. Required with make and model."

addedInput schema / properties / modelYear / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / modelYear / minimum
```
Added value: +-9007199254740991
```
changedInput schema / properties / modelYear / type
```
Previous value: -"number"New value: +"integer"
```

addedOutput schema / properties / recalls / items / properties / affectedVehicles

Added value: +{
+  "description": "Every distinct make/model the campaign covers (campaign queries). Equipment and tire campaigns name the part here — make is the brand, model is the part — and carry no model year.",
+  "items": {
+    "additionalProperties": false,
+    "description": "One vehicle covered by the campaign",
+    "properties": {
+      "make": {
+        "description": "Vehicle make",
+        "type": "string"
+      },
+      "model": {
+        "description": "Vehicle model",
+        "type": "string"
+      },
+      "modelYear": {
+        "description": "Model year",
+        "type": "number"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / recalls / items / properties / investigationId

Added value: +{
+  "description": "ODI investigation that preceded this campaign, when NHTSA links one (campaign queries) — pass it as nhtsaId to nhtsa_search_investigations for the full record.",
+  "type": "string"
+}

changedOutput schema / properties / recalls / items / properties / reportReceivedDate / description
```
Previous value: -"Date received by NHTSA"New value: +"Date received by NHTSA (ISO YYYY-MM-DD)"
```

removedOutput schema / properties / recalls / items / properties / subject

Removed value: -{
-  "description": "Recall subject (campaign queries)",
-  "type": "string"
-}

1 tool updateJul 30, 2026

Changednhtsa_get_vehicle_safety8 fields changed

addedOutput schema / properties / effectiveQuery

Added value: +{
+  "description": "The vehicle queried, as \"make model modelYear\".",
+  "type": "string"
+}

addedOutput schema / properties / notice

Added value: +{
+  "description": "Guidance when no NHTSA records matched the vehicle — e.g. how to verify make/model/year spelling.",
+  "type": "string"
+}

addedOutput schema / properties / recalls / items / properties / consequence

Added value: +{
+  "description": "Safety consequence",
+  "type": "string"
+}

addedOutput schema / properties / recalls / items / properties / manufacturer

Added value: +{
+  "description": "Vehicle/equipment manufacturer",
+  "type": "string"
+}

addedOutput schema / properties / recalls / items / properties / overTheAirUpdate

Added value: +{
+  "description": "OTA update availability when provided by NHTSA",
+  "type": "boolean"
+}

addedOutput schema / properties / recalls / items / properties / parkOutSide

Added value: +{
+  "description": "Park-outside advisory when provided by NHTSA",
+  "type": "boolean"
+}

changedOutput schema / properties / recalls / items / required

Previous value: -[
-  "campaignNumber",
-  "component",
-  "summary",
-  "remedy",
-  "reportReceivedDate"
-]New value: +[
+  "campaignNumber",
+  "manufacturer",
+  "component",
+  "summary",
+  "consequence",
+  "remedy",
+  "reportReceivedDate"
+]

changedOutput schema / required

Previous value: -[
-  "sectionStatus",
-  "warnings"
-]New value: +[
+  "sectionStatus",
+  "warnings",
+  "effectiveQuery"
+]

1 tool updateJul 30, 2026

Changednhtsa_search_investigations14 fields changed

changedInput schema / properties / limit / description

Previous value: -"Max results to return. Default: 20."New value: +"Max investigations to return. Defaults to 20; max 25. The cap is lower than the other paginated tools because a single investigation summary can run several thousand characters and is rendered in full."

addedInput schema / properties / limit / maximum
```
Added value: +25
```
addedInput schema / properties / limit / minimum
```
Added value: +1
```

changedInput schema / properties / limit / type

Previous value: -"number"New value: +"integer"

changedInput schema / properties / offset / description

Previous value: -"Pagination offset. Default: 0."New value: +"Pagination offset into the matching investigations. Defaults to 0."

addedInput schema / properties / offset / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / offset / minimum
```
Added value: +0
```

changedInput schema / properties / offset / type

Previous value: -"number"New value: +"integer"

changedInput schema / properties / status / description

Previous value: -"Filter by status: \"O\" (Open), \"C\" (Closed)."New value: +"Filter by status: \"O\" (Open) or \"C\" (Closed). Omit to include both."

addedInput schema / properties / status / enum
```
Added value: +[
+  "O",
+  "C"
+]
```

addedOutput schema / properties / limit

Added value: +{
+  "description": "Pagination limit used for this page",
+  "type": "number"
+}

addedOutput schema / properties / offset

Added value: +{
+  "description": "Pagination offset used for this page",
+  "type": "number"
+}

addedOutput schema / properties / returned

Added value: +{
+  "description": "Number of investigations in this page",
+  "type": "number"
+}

changedOutput schema / required

Previous value: -[
-  "totalCount",
-  "investigations",
-  "effectiveQuery"
-]New value: +[
+  "totalCount",
+  "returned",
+  "offset",
+  "limit",
+  "investigations",
+  "effectiveQuery"
+]

1 tool updateJun 2, 2026

Changednhtsa_search_investigations1 field changed

changedInput schema / properties / investigationType / description

Previous value: -"Filter by type: \"PE\" (Preliminary Evaluation), \"EA\" (Engineering Analysis), \"DP\" (Defect Petition), \"RQ\" (Recall Query)."New value: +"Filter by ODI investigation type code (the leading letters of the NHTSA ID). Named types: \"PE\" (Preliminary Evaluation), \"EA\" (Engineering Analysis), \"DP\" (Defect Petition), \"RQ\" (Recall Query), \"AQ\" (Audit Query). Additional valid codes present in the dataset: \"SQ\", \"EQ\", \"RP\", \"ID\", \"TA\", \"C\". Pass any code exactly as it appears in the investigation ID prefix."

2 tool updatesMay 30, 2026

Changednhtsa_decode_vin3 fields changed

addedOutput schema / properties / effectiveQuery

Added value: +{
+  "description": "Number of VINs decoded and the path taken (single or batch).",
+  "type": "string"
+}

addedOutput schema / properties / notice

Added value: +{
+  "description": "Present when one or more VINs decoded with VPIC warnings (errorCode != 0) — check errorCode/errorText per vehicle.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "vehicles"
-]New value: +[
+  "vehicles",
+  "effectiveQuery"
+]

Changednhtsa_search_investigations15 fields changed

addedInput schema / properties / component

Added value: +{
+  "description": "Structured filter — matches against the investigation's affected components (e.g., \"STEERING\"). ANDed with other filters.",
+  "type": "string"
+}

changedInput schema / properties / make / description

Previous value: -"Free-text filter — matches manufacturer name against subject/description text. ANDed with other filters."New value: +"Structured filter — matches against the investigation's associated vehicle makes (e.g., \"TOYOTA\"). ANDed with other filters."

changedInput schema / properties / model / description

Previous value: -"Free-text filter — matches model name against subject/description text. ANDed with other filters."New value: +"Structured filter — matches against the investigation's associated vehicle models. ANDed with other filters."

changedInput schema / properties / query / description

Previous value: -"Free-text search across investigation subjects and descriptions."New value: +"Free-text search across investigation subject and summary."

addedOutput schema / properties / investigations / items / properties / closeDate

Added value: +{
+  "description": "Date investigation closed (YYYY-MM-DD), if closed",
+  "type": "string"
+}

addedOutput schema / properties / investigations / items / properties / components

Added value: +{
+  "description": "Affected components",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

removedOutput schema / properties / investigations / items / properties / description

Removed value: -{
-  "description": "Investigation description (HTML stripped)",
-  "type": "string"
-}

removedOutput schema / properties / investigations / items / properties / latestActivityDate
```
Removed value: -{
-  "description": "Date of latest activity",
-  "type": "string"
-}
```

addedOutput schema / properties / investigations / items / properties / makes

Added value: +{
+  "description": "Associated vehicle makes",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / investigations / items / properties / manufacturer
```
Added value: +{
+  "description": "Manufacturer name",
+  "type": "string"
+}
```

addedOutput schema / properties / investigations / items / properties / models

Added value: +{
+  "description": "Associated vehicle models",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / properties / investigations / items / properties / openDate / description

Previous value: -"Date investigation opened"New value: +"Date investigation opened (YYYY-MM-DD)"

addedOutput schema / properties / investigations / items / properties / recallCampaign

Added value: +{
+  "description": "Linked recall campaign number (if any) — use with nhtsa_search_recalls",
+  "type": "string"
+}

addedOutput schema / properties / investigations / items / properties / summary

Added value: +{
+  "description": "Investigation summary",
+  "type": "string"
+}

addedOutput schema / properties / investigations / items / properties / years

Added value: +{
+  "description": "Associated model years",
+  "items": {
+    "type": "number"
+  },
+  "type": "array"
+}

5 tool updatesMay 30, 2026

Changednhtsa_get_safety_ratings2 fields changed

removedOutput schema / properties / message

Removed value: -{
-  "description": "Contextual guidance populated when no ratings are returned",
-  "type": "string"
-}

addedOutput schema / properties / notice

Added value: +{
+  "description": "Guidance when no NCAP ratings are found — e.g. coverage notes or adjacent year suggestion.",
+  "type": "string"
+}

Changednhtsa_lookup_vehicles4 fields changed

addedOutput schema / properties / effectiveQuery

Added value: +{
+  "description": "The operation with key args, e.g. \"models make=Toyota year=2020\".",
+  "type": "string"
+}

removedOutput schema / properties / message

Removed value: -{
-  "description": "Contextual guidance populated when the result set is empty",
-  "type": "string"
-}

addedOutput schema / properties / notice

Added value: +{
+  "description": "Guidance when the result set is empty or the page is out of bounds.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "operation",
-  "totalCount",
-  "returned",
-  "offset",
-  "limit"
-]New value: +[
+  "operation",
+  "totalCount",
+  "returned",
+  "offset",
+  "limit",
+  "effectiveQuery"
+]

Changednhtsa_search_complaints3 fields changed

addedOutput schema / properties / effectiveQuery

Added value: +{
+  "description": "\"make model modelYear\" with optional component filter applied, as the server used it.",
+  "type": "string"
+}

addedOutput schema / properties / notice

Added value: +{
+  "description": "Guidance when no complaints are found — e.g. how to verify make/model/year spelling.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "totalCount",
-  "returned",
-  "offset",
-  "limit",
-  "componentBreakdown",
-  "complaints"
-]New value: +[
+  "totalCount",
+  "returned",
+  "offset",
+  "limit",
+  "componentBreakdown",
+  "complaints",
+  "effectiveQuery"
+]

Changednhtsa_search_investigations4 fields changed

addedOutput schema / properties / effectiveQuery

Added value: +{
+  "description": "Applied filters as a readable string, e.g. make=\"Ford\" status=\"O\".",
+  "type": "string"
+}

removedOutput schema / properties / message

Removed value: -{
-  "description": "Contextual guidance populated when no investigations match the filters",
-  "type": "string"
-}

addedOutput schema / properties / notice

Added value: +{
+  "description": "Guidance when no investigations match — e.g. suggestions for broadening the search.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "totalCount",
-  "investigations"
-]New value: +[
+  "totalCount",
+  "investigations",
+  "effectiveQuery"
+]

Changednhtsa_search_recalls3 fields changed

addedOutput schema / properties / effectiveQuery

Added value: +{
+  "description": "The search key used: campaign number, or \"make model modelYear\" for vehicle queries.",
+  "type": "string"
+}

addedOutput schema / properties / notice

Added value: +{
+  "description": "Guidance when no recalls are found — e.g. how to verify make/model/year spelling.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "recalls",
-  "totalCount"
-]New value: +[
+  "recalls",
+  "totalCount",
+  "effectiveQuery"
+]

1 tool updateMay 8, 2026

Changednhtsa_get_safety_ratings3 fields changed

changedOutput schema / properties / ratings / items / properties / complaintsCount / description

Previous value: -"Number of complaints on file"New value: +"Complaints linked by NHTSA to this specific NCAP record. Variant-scoped — for vehicle-level totals call nhtsa_search_complaints."

changedOutput schema / properties / ratings / items / properties / investigationCount / description

Previous value: -"Number of investigations on file"New value: +"Investigations linked by NHTSA to this specific NCAP record. Variant-scoped — for vehicle-level totals call nhtsa_search_investigations."

changedOutput schema / properties / ratings / items / properties / recallsCount / description

Previous value: -"Number of recalls on file"New value: +"Recalls linked by NHTSA to this specific NCAP record. Variant-scoped — for vehicle-level totals call nhtsa_search_recalls."

7 tool updatesApr 24, 2026
- Changednhtsa_decode_vin3 fields changed
  - changedInput schema / properties / vin / anyOf
```
Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  }
-]New value: +[
+  {
+    "description": "A single VIN string (up to 17 characters, * for unknown positions)",
+    "type": "string"
+  },
+  {
+    "description": "An array of up to 50 VINs for batch decode",
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]
```
  - addedOutput schema / properties / vehicles / items / description
```
Added value: +"Decoded details for a single VIN"
```
  - changedOutput schema / properties / vehicles / items / properties / vin / description
```
Previous value: -"The decoded VIN"New value: +"The decoded VIN, echoed back from the request"
```
- Changednhtsa_get_safety_ratings1 field changed
  - addedOutput schema / properties / ratings / items / description
```
Added value: +"Safety ratings for a single vehicle variant"
```
- Changednhtsa_get_vehicle_safety3 fields changed
  - addedOutput schema / properties / complaintSummary / properties / componentBreakdown / items / description
```
Added value: +"Complaint counts for a single component"
```
  - addedOutput schema / properties / recalls / items / description
```
Added value: +"A single recall campaign"
```
  - addedOutput schema / properties / safetyRatings / items / description
```
Added value: +"Safety ratings for a single vehicle variant"
```
- Changednhtsa_lookup_vehicles5 fields changed
  - addedOutput schema / properties / makes / items / description
```
Added value: +"A single make entry"
```
  - addedOutput schema / properties / manufacturers / items / description
```
Added value: +"A single manufacturer entry"
```
  - addedOutput schema / properties / manufacturers / items / properties / vehicleTypes / items / description
```
Added value: +"A single vehicle-type entry produced by this manufacturer"
```
  - addedOutput schema / properties / models / items / description
```
Added value: +"A single model entry"
```
  - addedOutput schema / properties / vehicleTypes / items / description
```
Added value: +"A single vehicle-type entry"
```
- Changednhtsa_search_complaints2 fields changed
  - addedOutput schema / properties / complaints / items / description
```
Added value: +"A single consumer complaint"
```
  - addedOutput schema / properties / componentBreakdown / items / description
```
Added value: +"Complaint counts for a single component"
```
- Changednhtsa_search_investigations1 field changed
  - addedOutput schema / properties / investigations / items / description
```
Added value: +"A single NHTSA investigation"
```
- Changednhtsa_search_recalls1 field changed
  - addedOutput schema / properties / recalls / items / description
```
Added value: +"A single recall campaign"
```

2 tool updatesApr 23, 2026

Changednhtsa_lookup_vehicles8 fields changed

changedInput schema / properties / limit / description

Previous value: -"For \"makes\" only: maximum makes to return. Defaults to 100; max 200. Ignored for other operations."New value: +"Max results in the returned slice. Defaults to 100; max 200."

changedInput schema / properties / offset / description

Previous value: -"For \"makes\" only: pagination offset into the full makes list. Defaults to 0. Ignored for other operations."New value: +"Pagination offset into the full result list. Defaults to 0."

changedInput schema / properties / operation / description

Previous value: -"\"makes\" (paginated slice of all makes), \"models\" (models for a make), \"vehicle_types\" (types for a make), \"manufacturer\" (manufacturer details)."New value: +"\"makes\" (all NHTSA makes), \"models\" (models for a make), \"vehicle_types\" (types for a make), \"manufacturer\" (manufacturer details)."

removedOutput schema / properties / count

Removed value: -{
-  "description": "Number of results returned in this response",
-  "type": "number"
-}

addedOutput schema / properties / returned

Added value: +{
+  "description": "Number of results in the returned slice",
+  "type": "number"
+}

removedOutput schema / properties / totalAvailable

Removed value: -{
-  "description": "Total results available before pagination, when relevant",
-  "type": "number"
-}

addedOutput schema / properties / totalCount

Added value: +{
+  "description": "Total results matching before pagination",
+  "type": "number"
+}

changedOutput schema / required

Previous value: -[
-  "operation",
-  "count"
-]New value: +[
+  "operation",
+  "totalCount",
+  "returned",
+  "offset",
+  "limit"
+]

Changednhtsa_search_investigations3 fields changed

removedOutput schema / properties / total

Removed value: -{
-  "description": "Total matching investigations",
-  "type": "number"
-}

addedOutput schema / properties / totalCount

Added value: +{
+  "description": "Total matching investigations",
+  "type": "number"
+}

changedOutput schema / required

Previous value: -[
-  "total",
-  "investigations"
-]New value: +[
+  "totalCount",
+  "investigations"
+]

5 tool updatesApr 19, 2026

Changednhtsa_get_safety_ratings1 field changed

addedOutput schema / properties / message

Added value: +{
+  "description": "Contextual guidance populated when no ratings are returned",
+  "type": "string"
+}

Changednhtsa_get_vehicle_safety2 fields changed
- addedOutput schema / properties / safetyRatings / items / properties / sideCrash / properties / combinedBarrierPoleFront
```
Added value: +{
+  "description": "Combined barrier/pole front rating",
+  "type": "string"
+}
```
- addedOutput schema / properties / safetyRatings / items / properties / sideCrash / properties / combinedBarrierPoleRear
```
Added value: +{
+  "description": "Combined barrier/pole rear rating",
+  "type": "string"
+}
```

Changednhtsa_lookup_vehicles1 field changed

addedOutput schema / properties / message

Added value: +{
+  "description": "Contextual guidance populated when the result set is empty",
+  "type": "string"
+}

Changednhtsa_search_complaints7 fields changed

addedInput schema / properties / limit

Added value: +{
+  "description": "Max complaint narratives to return. Defaults to 20; max 50. componentBreakdown always reflects all matching complaints.",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "description": "Pagination offset into the date-descending complaint list. Defaults to 0. componentBreakdown is unaffected by pagination.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

changedOutput schema / properties / complaints / description

Previous value: -"Most recent complaints (up to 50)"New value: +"Paginated slice of the most recent complaints, date-descending"

addedOutput schema / properties / limit

Added value: +{
+  "description": "Pagination limit used for this page",
+  "type": "number"
+}

addedOutput schema / properties / offset

Added value: +{
+  "description": "Pagination offset used for this page",
+  "type": "number"
+}

addedOutput schema / properties / returned

Added value: +{
+  "description": "Number of complaints in this page",
+  "type": "number"
+}

changedOutput schema / required

Previous value: -[
-  "totalCount",
-  "componentBreakdown",
-  "complaints"
-]New value: +[
+  "totalCount",
+  "returned",
+  "offset",
+  "limit",
+  "componentBreakdown",
+  "complaints"
+]

Changednhtsa_search_investigations1 field changed

addedOutput schema / properties / message

Added value: +{
+  "description": "Contextual guidance populated when no investigations match the filters",
+  "type": "string"
+}

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

CheckMyVIN A
net.checkmyvin
Decode any VIN and check open NHTSA safety recalls. Free official US government data, no auth.
Government Data Open Data
22
NHTSA Vehicle Safety A
com.olyport
Vehicle safety recalls, complaints, and crash data from NHTSA
Government Data Open Data Search
62
vin-recall-mcp A
io.github.pratikmehkarkar
Decodes US VINs and looks up open NHTSA safety recall campaigns for a vehicle.
Travel & Transportation Government Data
22
CarScout A
com.usecarscout
Search used car inventory, check NHTSA recalls, decode VINs, and manage automated search scouts.
Search Open Data E-commerce & Retail
32

Related MCP Servers

nhtsa
Government Data Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables querying U.S. vehicle safety and specification data, including VIN decoding, recalls, complaints, investigations, and crash test ratings.
Updated 10 days ago (2026-08-26 17:25 UTC)
3
MIT
CarsXE
Developer Tools Documentation Access
carsxe
A
license
A
quality
B
maintenance
Decode VINs, look up specs, history, recalls, market value, and OBD codes. Recognize license plates and VINs from images. Access comprehensive vehicle data by year, make, and model to power automotive workflows.
Updated 2 hours ago (2026-09-06 03:31 UTC)
12
MIT
VIN MCP
Search Open Data Government Data
keptlive
A
license
Not graded
quality
D
maintenance
Provides comprehensive vehicle reports by aggregating data from multiple public sources to decode VINs, check recalls, and view safety ratings. It enables users to validate VINs locally and retrieve technical specifications, fuel economy, and vehicle photos without requiring API keys.
Updated 6 months ago (2026-02-28 19:35 UTC)
16
MIT
RecallChecker
Government Data Open Data
ollo12-prog
A
license
Not graded
quality
D
maintenance
Enables instant U.S. vehicle recall lookup by make, model, and year using official NHTSA data.
Updated 3 months ago (2026-05-25 02:06 UTC)
MIT

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation4/5

Tools are mostly distinct, but nhtsa_get_safety_ratings and nhtsa_get_vehicle_safety overlap, with the latter subsuming the former. Descriptions help clarify when to use each, so agents are unlikely to misselect.

Naming Consistency5/5

All tools consistently use the nhtsa_ prefix followed by a verb_noun pattern (decode_vin, get_safety_ratings, lookup_vehicles, search_recalls). The verb varies by action but follows a predictable, uniform structure.

Tool Count5/5

Seven tools is well within the ideal range and fits the NHTSA vehicle safety domain. Each tool covers a distinct facet (VIN, ratings, complaints, recalls, investigations), justifying its presence without bloat.

Completeness4/5

The set covers core vehicle safety workflows: VIN decoding, safety ratings, complaints, recalls, and investigations. A minor gap is the lack of a dedicated tool for detailed recall or investigation record retrieval beyond search, but the existing search tools appear sufficient for most use cases.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Frequently Asked Questions

Discussions

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources