Decode VINs, search recalls, complaints, crash ratings, and investigations.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 7 of 7 tools scored.
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.
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.
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.
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.
nhtsa_decode_vinNhtsa Decode VinADecode 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.
| 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. |
| Name | Required | Description |
|---|---|---|
| notice | No | Present when one or more VINs decoded with VPIC warnings (errorCode != 0) — check errorCode/errorText per vehicle. |
| vehicles | Yes | Decoded vehicle information per VIN |
| effectiveQuery | Yes | Number of VINs decoded and the path taken (single or batch). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which description does not contradict. The description adds non-obvious behavior: batch decoding up to 50 VINs and partial VIN handling with '*', which are useful details beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose, followed by input format and special cases. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple two-parameter interface with an output schema. The description covers purpose, input formats, batch limits, and partial VIN handling. The modelYear ambiguity resolution is in the schema. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description repeats some of the vin parameter info (single/array, partial) but adds nothing new beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool decodes a Vehicle Identification Number and lists specific outputs (make, model, year, body type, engine, safety equipment, manufacturing details). This distinguishes it from sibling tools focused on safety ratings, complaints, and recalls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear input constraints: single VIN or array up to 50, partial VINs with *, and modelYear helps with ambiguity. It doesn't explicitly name alternatives, but the purpose and sibling contexts make appropriate usage obvious.
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 RatingsAGet 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+.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no NCAP ratings are found — e.g. coverage notes or adjacent year suggestion. |
| ratings | Yes | Safety ratings per vehicle variant |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context about data availability ('NCAP data available from 1990+, best coverage for 2011+') which goes beyond the annotation. No contradiction with the read-only hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence states purpose, the second provides usage guidance and data limitations. Every sentence earns its place and it is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and read-only annotation, the description provides adequate contextual coverage: purpose, usage scenarios, and data scope. The only minor gap is not explicitly explaining the vehicleId-based lookup path, but the schema already documents that, so completeness is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are rich (e.g., vehicleId 'Skips the year/make/model lookup'). The description mentions 'compare safety features across vehicles' which loosely relates to parameters but does not add meaningful syntax or dependency information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the exact resource ('NCAP crash test ratings and ADAS feature availability'). It also lists concrete examples ('crash test stars, rollover risk') that clearly distinguish it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases ('Use when the user specifically wants crash test stars, rollover risk, or wants to compare safety features across vehicles'), which is clear context. However, it does not mention alternatives or explicitly state when not to use this tool, so it misses the full 'when-not/alternatives' bar.
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 SafetyAGet 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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). |
| Name | Required | Description |
|---|---|---|
| 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 | Yes | Warnings about sections that could not be loaded from NHTSA |
| safetyRatings | No | Crash test ratings per vehicle variant (e.g., FWD vs AWD) |
| sectionStatus | Yes | Availability of each data section in this response |
| effectiveQuery | Yes | The vehicle queried, as "make model modelYear". |
| complaintSummary | No | Summary of consumer complaints |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint already declaring the read-only nature, the description adds meaningful behavioral context by revealing that the tool aggregates data from multiple sources (NCAP ratings, recalls, complaints). It does not contradict annotations and provides value beyond the structured safety hints, though it does not discuss limitations like response size or potential slowness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the core purpose and followed by usage guidance. Every sentence earns its place with no filler or redundancy, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists to explain return values and annotations cover read-only safety, the description is complete for a straightforward aggregated lookup tool. It covers what the tool does, what data it combines, and when to use it, leaving no critical gaps for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 description carries no additional parameter-level meaning. Baseline 3 applies because the schema already documents the parameters fully; the description adds nothing beyond referring to a 'vehicle' generically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get a comprehensive safety profile for a vehicle' and enumerates its components: 'Combines NCAP crash test ratings, recalls, and complaint summary into a single response.' This specific verb+resource combination distinguishes it from siblings like nhtsa_get_safety_ratings and nhtsa_search_recalls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Use as the default when asked about vehicle safety, reliability, or purchase decisions,' giving clear when-to-use guidance. However, it does not mention when not to use it or point to alternatives for specialized queries, so it lacks the full exclusions/alternatives expected for a 5.
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 VehiclesALook 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| cap | No | Maximum manufacturer records a single lookup retrieves. |
| limit | Yes | 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 | Yes | Pagination offset used for this response |
| returned | Yes | Number of results in the returned slice |
| operation | Yes | The operation that was performed |
| truncated | No | True when the "manufacturer" lookup stopped at its retrieval cap and further matches may exist upstream. |
| totalCount | Yes | 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 | Yes | The operation with key args, e.g. "models make=Toyota year=2020". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, annotations already cover the safety profile, and the description adds context about resolving ambiguity and discovering models. However, it doesn't disclose any behavioral quirks such as pagination behavior, default limits, or the fact that 'manufacturer' is also a supported operation. The description stays at the level of purpose rather than adding richer behavioral detail, so 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the core purpose and followed by practical use cases. Every word earns its place; there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main operations (makes, models, vehicle types) and gives practical scenarios, but it omits the 'manufacturer' operation, which is listed in the schema. It also doesn't mention that limited results and pagination are available, but the output schema likely explains return structure. Overall, this is a solid description that could be slightly more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a description. The tool description doesn't add any parameter-level semantics beyond what the schema already states, such as that 'make' is required for 'models' and 'vehicle_types'. Since the schema does the heavy lifting, the baseline 3 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up valid makes, models, and vehicle types in NHTSA's database, using the specific verb 'Look up' and naming the resource. This distinguishes it from sibling tools like VIN decoding, safety ratings, complaints, and recalls, which all serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'resolve ambiguous vehicle names, find correct make/model spelling, or discover what models a manufacturer produces.' This gives clear context for when to use the tool, but it doesn't explicitly mention any alternatives or when not to use it. With sibling names like nhtsa_search_recalls and nhtsa_get_safety_ratings, the differentiation is implied rather than stated, so it earns a solid 4.
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 ComplaintsASearch 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | 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 | Yes | Pagination offset used for this page |
| returned | Yes | Number of complaints in this page |
| complaints | Yes | Paginated slice of the most recent complaints, date-descending |
| totalCount | Yes | Total complaints matching criteria |
| effectiveQuery | Yes | "make model modelYear" with optional component filter applied, as the server used it. |
| componentBreakdown | Yes | Complaints grouped by component, sorted by frequency |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds valuable behavior context beyond this: it returns both an aggregate component breakdown and a paginated slice of complaints, and notes the slice is of the most recent complaints. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the primary purpose in the first sentence and usage guidance in the second. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with a rich schema and an existing output schema, fully covers the tool's purpose, key behaviors, and usage context. It explains the dual nature of the response (breakdown + paginated slice) and the intended use cases, leaving no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for all six parameters, so the description does not need to explain them individually. The description references pagination and component breakdown, but these concepts are already well-covered in the schema, so no additional meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches consumer safety complaints filed with NHTSA for a specific vehicle, explicitly distinguishing it from sibling tools like recalls and investigations. It also specifies what it returns: a component breakdown and a paginated slice of recent complaints, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use for common problems, failure patterns, or owner-reported issues.' However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of full exclusionary guidance.
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 InvestigationsASearch 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | 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 | Yes | Pagination offset used for this page |
| returned | Yes | Number of investigations in this page |
| totalCount | Yes | Total matching investigations |
| effectiveQuery | Yes | Applied filters as a readable string, e.g. make="Ford" status="O". |
| investigations | Yes | Matching investigations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=true annotation, the description discloses important behaviors: all filters are ANDed, make/model/component are structured vehicle-associated filters, nhtsaId is mutually exclusive with other filters, and investigations can link to recalls. These are non-obvious details that help an agent predict tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long and front-loads the main purpose before diving into filter semantics and special cases. Every sentence carries distinct information—coverage, filter behavior, nhtsaId usage, recall link—with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, a full schema, output schema present, and a readOnly annotation, the description covers all essential aspects: what the tool searches, how filters behave, the nhtsaId special case, and the recall relationship. The output schema handles return-value details, so the description is complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds meaning beyond the schema by clarifying that make/model/component are structured vehicle-association filters and that all filters are ANDed. It also explains the special semantic of nhtsaId (exact match, mutually exclusive, usable with the investigationId from nhtsa_search_recalls), which enriches the parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and resource ('NHTSA defect investigations'), names the data source (ODI flat file), and lists the investigation types covered. It clearly distinguishes this tool from siblings like nhtsa_search_recalls and nhtsa_search_complaints by focusing on defect investigations and mentioning the recall campaign link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains the AND behavior of filters, the special nhtsaId mode for fetching a specific investigation, and the relationship to recall campaigns via recallCampaign. It doesn't explicitly state 'when not to use' or name alternatives, but the context is sufficient for an agent to select this tool appropriately.
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 RecallsASearch recall campaigns by vehicle or campaign number. Use for specific recall lookups, recall history for a vehicle, or looking up a known campaign number.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no recalls are found — e.g. how to verify make/model/year spelling. |
| recalls | Yes | Matching recall campaigns |
| totalCount | Yes | Total recalls matching criteria |
| effectiveQuery | Yes | The search key used: campaign number, or "make model modelYear" for vehicle queries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safe read behavior, but the description adds no behavioral details beyond that. It does not mention rate limits, pagination, or any side effects. The description is purely functional and provides no new behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the verb 'Search', and every word earns its place. It avoids redundancy and clearly conveys purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema with 100% parameter coverage and an output schema, the description provides sufficient context for purpose and usage. It does not repeat existing schema details and is complete for a search tool, though it omits some edge-case constraints that are already in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter description coverage, so the baseline is 3. The tool description adds little beyond the schema's parameter docs, only broadly referring to 'by vehicle or campaign number' without specific syntax or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches recall campaigns by vehicle or campaign number, which is specific and distinguishes this from sibling tools like nhtsa_search_complaints and nhtsa_search_investigations. The use cases (specific recall lookups, recall history, known campaign number) further clarify the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use scenarios: 'specific recall lookups, recall history for a vehicle, or looking up a known campaign number.' However, it does not mention when not to use the tool or explicitly reference alternatives, so it falls short of the full 5 criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!