nhtsa-vehicle-safety-mcp-server
Server Details
Decode VINs, search recalls, complaints, crash ratings, and investigations.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/nhtsa-vehicle-safety-mcp-server
- GitHub Stars
- 0
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.
Tool Definition Quality
Average 4.3/5 across 7 of 7 tools scored.
Each tool targets a distinct NHTSA data category: VIN decoding, safety ratings, comprehensive safety profile, vehicle lookup, complaints, investigations, and recalls. No overlap in purpose, and descriptions clearly differentiate them.
All tools follow a consistent verb_noun pattern with the 'nhtsa_' prefix (e.g., nhtsa_decode_vin, nhtsa_search_recalls). The naming is uniform and predictable.
Seven tools is well-scoped for the domain of vehicle safety data. Each tool covers a key operation without being excessive, and the count aligns with typical API surface sizes.
The tool set covers core NHTSA functionalities: VIN decoding, safety ratings, recalls, complaints, investigations, and vehicle lookup. A minor gap is the lack of a tool for retrieving specific recall details beyond search, but the overall coverage is comprehensive for common use cases.
Available Tools
7 toolsnhtsa_decode_vinNhtsa Decode VinARead-onlyInspect
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.
| 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 | Helps resolve ambiguity for pre-1980 VINs or partial VINs. |
Output Schema
| 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint annotation, description adds behavioral traits: batch decoding limit of 50 VINs, acceptance of partial VINs with * wildcards. All consistent with read-only nature.
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, no extraneous information. First sentence states core function, second provides input parameter specifics. Efficient and 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?
Description adequately covers input variety (single, batch, partial) and output categories (make, model, year, etc.). Output schema exists to detail return structure, so completeness is high.
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 covers both parameters fully, but description enriches with practical details: batch limit ('up to 50'), wildcard usage ('* for unknown positions'), and modelYear purpose ('resolves ambiguity').
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?
Description uses specific verb 'Decode' and resource 'Vehicle Identification Number', listing exact outputs (make, model, year, etc.). Clearly distinct from sibling tools focused on safety ratings, recalls, etc.
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?
States when to use (to extract vehicle details from VIN) and details input types (single or batch up to 50, partial VINs with *). No explicit when-not-to-use or alternative tools, but context is clear.
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 RatingsARead-onlyInspect
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+.
| 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. 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
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a read-only operation. The description adds context about data coverage years (1990+, best 2011+), which is helpful but does not disclose any additional behavioral traits beyond 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 two sentences: first sentence states the core purpose, second provides usage guidance and data coverage. Every sentence earns its place, no redundancy, and the key information 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 that an output schema exists, the description does not need to explain return values. It covers purpose, usage context, and data availability. It does not mention error conditions or authentication, but the tool is simple and the annotations cover safety, so it is sufficiently 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%, so the schema already documents all parameters. The description adds value by noting the NCAP data coverage window (1990+ and best for 2011+), which provides meaningful context for the modelYear parameter, going beyond the schema's description.
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 'Get NCAP crash test ratings and ADAS feature availability for a vehicle', specifying verb and resource. It distinguishes from sibling tools like nhtsa_decode_vin and nhtsa_search_recalls by focusing on safety ratings and ADAS features.
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 says 'Use when the user specifically wants crash test stars, rollover risk, or wants to compare safety features across vehicles', providing clear context. It also notes data availability range (1990+, best 2011+), but does not explicitly mention when not to use or alternatives, though sibling tools are listed separately.
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 SafetyARead-onlyInspect
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.
| 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 (e.g., 2020). |
Output Schema
| Name | Required | Description |
|---|---|---|
| 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 |
| complaintSummary | No | Summary of consumer complaints |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true. The description adds that the tool combines multiple data sources (ratings, recalls, complaints), which provides context beyond annotations. However, it does not disclose other behavioral traits such as response format (covered by output schema), data freshness, or any potential limitations like partial data for uncommon vehicles.
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 long, front-loaded with the purpose, and includes a usage guideline. Every sentence provides value without redundancy or wasted words.
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?
For a tool that combines three data sources, the description is complete enough for selection and invocation. It states the purpose and when to use it. The presence of an output schema documents return values. It lacks mention of potential data availability or required parameter validity, but overall sufficient.
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 clear descriptions for make (case-insensitive), model (case-insensitive), and modelYear (number). The description adds no extra parameter meaning beyond the schema, so baseline score of 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 that the tool gets a 'comprehensive safety profile' combining NCAP crash test ratings, recalls, and complaint summary. It specifies the verb 'Get' and the resource 'safety profile', and distinguishes from siblings like nhtsa_get_safety_ratings and nhtsa_search_recalls by emphasizing the combined nature.
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 says 'Use as the default when asked about vehicle safety, reliability, or purchase decisions.' This gives clear context for when to prefer this tool over siblings. However, it does not provide explicit when-not-to-use guidance or mention alternative tools for specific queries like recalls only.
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 VehiclesARead-onlyInspect
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.
| 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. 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
| Name | Required | Description |
|---|---|---|
| limit | Yes | Pagination limit used for this response |
| makes | No | Results for "makes" operation |
| 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 |
| totalCount | Yes | Total results matching before pagination |
| 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". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds minor context (it's a lookup) but no depth on rate limits or response format. Adequate given annotation coverage.
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, front-loaded with purpose, no redundant or unnecessary words. Highly efficient.
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?
Parameters fully documented in schema, output schema exists, annotations provide safety, sibling tools listed. Description completes the picture with usage context.
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 baseline is 3. Description mentions partial match support, but that is already in the schema. No additional meaning beyond schema.
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 ('look up') and names the resources ('makes, models, and vehicle types'), clearly distinguishing from sibling tools like VIN decoding or safety ratings.
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?
Explicitly states use cases: resolving ambiguous names, correct spelling, discovering models. Does not contrast with alternative tools, but sibling list provides context.
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 ComplaintsARead-onlyInspect
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.
| 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 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | Pagination limit used for this page |
| notice | No | Guidance when no complaints are found — e.g. how to verify make/model/year spelling. |
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description adds behavioral details: returns a component breakdown from all matching complaints, paginated slice of recent complaints, and clarifies that offset and limit affect only the complaint list, not the breakdown. No contradictions.
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: first defines purpose and output, second gives usage guidance. No wasted words, highly efficient.
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 6 parameters, 100% schema coverage, and an output schema, the description fully covers the tool's behavior and context. It explains what the tool returns and when to use it, without needing to duplicate output schema details.
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%, so baseline is 3. The description adds meaning beyond schema: it clarifies that component breakdown always reflects all matching complaints (pagination unaffected), and provides formatting guidance for the 'component' parameter (uppercase, examples).
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 consumer safety complaints for a specific vehicle, and distinguishes from sibling tools like recalls or investigations by specifying 'complaints' and the return of a component breakdown plus paginated 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?
It explicitly says 'Use for common problems, failure patterns, or owner-reported issues', which provides clear context. It does not explicitly state when not to use or name alternatives, but the context is sufficient given sibling tool names.
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 InvestigationsARead-onlyInspect
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. 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 results to return. Default: 20. | |
| model | No | Structured filter — matches against the investigation's associated vehicle models. ANDed with other filters. | |
| query | No | Free-text search across investigation subject and summary. | |
| offset | No | Pagination offset. Default: 0. | |
| status | No | Filter by status: "O" (Open), "C" (Closed). | |
| 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
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no investigations match — e.g. suggestions for broadening the search. |
| totalCount | Yes | Total matching investigations |
| effectiveQuery | Yes | Applied filters as a readable string, e.g. make="Ford" status="O". |
| investigations | Yes | Matching investigations |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that investigations may link to resulting recall campaigns, adding value beyond the readOnlyHint annotation. It correctly identifies the tool as read-only (search), with no destructive or write behavior mentioned or implied.
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 concise (3 sentences) and front-loaded with the core purpose. Every sentence adds value: purpose, filter logic, and recall campaign link. No unnecessary words.
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 8 parameters, no required fields, and an output schema, the description covers the main aspects: types, filters, and links. It could mention pagination details (limit/offset) but those are covered in the schema. Overall, it provides enough for an agent to use effectively.
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%, so parameters are well-documented. The description adds context by explaining the AND logic for structured filters, listing named types for investigationType, and noting that filters are against vehicle associations. This goes beyond the schema descriptions.
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 NHTSA defect investigations, lists specific investigation types (PE, EA, DP, RQ, AQ, etc.), and describes the structured filters. It distinguishes itself from sibling tools like complaints and recalls by focusing on investigations.
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 explains that make, model, and component are structured filters ANDed together, and mentions linking to recall campaigns. It implies usage for searching investigations but does not explicitly state when not to use or list alternative tools. Sibling context helps, but explicit guidance would improve.
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 RecallsARead-onlyInspect
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.
| 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. Required with make and model. | |
| campaignNumber | No | NHTSA campaign number (e.g., "20V682000"). When provided, returns campaign details. Other params ignored. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that it searches by vehicle or campaign number but does not disclose additional behavioral traits like rate limits or authentication requirements. No contradiction 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?
Two concise sentences with no wasted words. The first sentence states the core function, and the second adds usage context. Front-loaded and efficient.
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 detailed schema (100% parameter descriptions) and existence of an output schema, the description adequately covers the tool's purpose and usage. The override behavior of campaignNumber is documented in the schema, so the description does not need to repeat it.
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, with each parameter already well-documented. The description does not add significant new information about parameters beyond the schema, which is the baseline expectation.
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 'Search recall campaigns by vehicle or campaign number' and provides specific use cases ('specific recall lookups, recall history for a vehicle, or looking up a known campaign number'). This distinguishes it from sibling tools like nhtsa_decode_vin or nhtsa_search_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 explicitly says when to use the tool (specific recall lookups, recall history, known campaign number). However, it does not mention when not to use it or provide explicit alternatives, though the context of siblings implies other tools for different purposes.
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.
Discussions
No comments yet. Be the first to start the discussion!