UK Data: US vehicle safety (NHTSA)

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely non-structural context: the data source (NHTSA ODI), the caveat that the account is the owner's own and unverified by NHTSA, and a 1-credit cost. It does not cover behaviour on an invalid or missing ODI number, which keeps it off a 5.

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 purpose and lookup key are front-loaded, the returned fields follow, and the audience/source/cost notes are appended as short fragments. There is no redundant or filler wording.

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 no output schema, the description compensates by enumerating the returned fields (vehicle, components, crash/fire, injuries and deaths, dates, partial VIN, owner narrative). For a single-parameter read tool this is nearly complete; only error behaviour on unknown ODI numbers is unaddressed.

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 the single odinumber parameter is fully documented in the schema, including an example. The description adds only the restatement 'by its ODI number' and no format or range detail beyond what the schema supplies, so the baseline of 3 applies.

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?

States a specific verb and resource ('Read one NHTSA owner safety complaint') plus the lookup key ('by its ODI number') and enumerates the returned fields. It also names the sibling tool vehicle_complaints as the discovery path, so an agent can distinguish it immediately.

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 phrase 'following up a complaint found with vehicle_complaints' establishes the order of operations and the intended audience. It stops short of stating when not to use it or what to do if the ODI number is unknown, so it is clear context without explicit exclusions.

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

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

Annotations already cover read-only, idempotent, non-destructive and open-world traits, so the bar is lower; the description still adds useful non-structured context: the NHTSA Recalls API as source, a stated cost of 1 credit, and a scope limitation about vehicle-specific repair status. It doesn't address behavior on an unknown or malformed campaign number, which is the main remaining gap.

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?

Front-loaded with the core action and return payload, then constraints. The audience list ('For owners, journalists, lawyers and fleet managers') is the least load-bearing sentence but is short enough not to hurt.

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 no output schema, the description carries the return-value burden and does so by enumerating the fields returned, plus source, credit cost and one scope caveat. Only error/not-found behavior and confirmation of whether coverage is US-only are left unaddressed.

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 the schema already supplies both example formats ('20V314000 or 20V-314'), so the description's 'as printed on a US recall letter' adds only marginal provenance context. Baseline 3 applies when the schema does the heavy lifting on a single documented parameter.

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?

States a specific verb and resource ('Look up one recall by its NHTSA campaign number') plus the exact payload returned (defect, risk, remedy, affected count, makes/models/years), which distinguishes it from the sibling list-style tools vehicle_recalls and product_recalls. The example campaign number anchors the identifier format immediately.

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?

Clear context: single-record lookup keyed by a campaign number from a US recall letter, aimed at owners, journalists, lawyers and fleet managers, with an explicit exclusion ('It does not say whether a specific vehicle has been repaired'). It stops short of naming a sibling like vehicle_recalls as the search/browse alternative, so the routing is implied rather than spelled out.

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

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

The annotations already declare this as a read-only, idempotent, non-destructive open-world lookup. The description adds information the annotations do not supply: the data source (NHTSA ODI), a 1-credit cost, and important caveats that complaints are unverified owner reports, not proven defects, and that counts are confounded by sales volume. Those caveats matter for interpretation, but nothing is said about pagination or response shape.

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?

It is well front-loaded: a question frames the use case, then the scope, then the outputs, then caveats, source and cost. The rhetorical opening costs a few words, and the output enumeration is long, but every clause carries real information.

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?

There is no output schema, so the description has to describe the response, and it does so thoroughly: totals, crashes, fires, injuries, deaths, most-complained components and latest complaint text. It also states the source and the credit cost. Nothing an agent needs to call it correctly 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 coverage is 100%, so the schema already documents make, model, modelYear and limit. The description mentions the make/model/year triple and that 'latest complaints with their text' are returned, which hints at what limit controls, but adds no format or constraint detail beyond the 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 names a specific resource (NHTSA owner-filed safety complaints) and the exact scope (make, model, model year), and it lists the outputs: totals, crashes, fires, injuries, deaths, top components and latest complaint text. That is enough for an agent to tell it apart from vehicle_recalls, vehicle_problem_counts and complaint_by_odi_number without opening a schema.

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 names an audience ('used-car buyers, owners and researchers'), which implies when the tool is useful. However, it never says when to choose it over sibling tools that cover the same vehicle domain, such as vehicle_recalls for recall campaigns or complaint_by_odi_number for a single complaint. The 1-credit cost note is useful but not routing guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's value-add is the disclosure that results are one entry per body style or drivetrain (multi-row output from a single call), the exact rating components returned, the authoritative source (NHTSA), and a 1-credit cost. Missing only edge behavior (no-data years, invalid make/model handling), which keeps it from a 5.

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?

Front-loaded with the user-facing question, then the payload, then the caveat and cost — good ordering with no redundancy. The 'For family car buyers' audience line and rhetorical opener are slightly promotional rather than operational, costing it a point.

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?

There is no output schema, and the description compensates by enumerating the fields returned and their granularity, plus the credit cost and a comparability caveat. For a three-parameter read-only lookup, nothing an agent needs in order to call it or interpret the response 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 make/model/modelYear are already documented, including the 'US model name' nuance and the year example. The description adds only that one query can yield several rows across body styles/drivetrains; it adds no format or normalization guidance beyond the schema, so baseline 3 applies.

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?

Names a specific resource (US NCAP 5-Star Safety Ratings) and the exact inputs (make, model, model year), and enumerates the returned crash dimensions: overall, frontal driver/passenger, side barrier, side pole, rollover plus risk percentage. It also distinguishes itself from the adjacent nl_vehicle / Euro NCAP domain, so an agent can separate it from the other vehicle_* siblings without opening a schema.

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?

Supplies a clear usage frame (comparing models for family car buyers) and an explicit scope/exclusion: these are US tests, and Euro NCAP scores for UK-market cars are not comparable star for star. It stops short of naming a sibling to use instead when the request is non-US, so the exclusion is stated but not routed to an alternative.

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

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

Annotations already declare readOnly/lazy-idempotent/openWorld, and the description adds genuinely new context: the NHTSA NCAP data source, the strict coverage boundary, and a stated cost of 1 credit. It does not describe error behavior or how partial matches are handled, which keeps it below the top mark.

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?

Front-loaded and efficiently structured with scope limits and cost flagged. The opening question duplicates the more precise sentence that follows, which is a small amount of waste but does serve as buyer-oriented framing.

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 no output schema, the description carries the burden of explaining the return values and does so ('standard, optional or not available, per body style'), plus source, scope limits, and credit cost. An agent has everything needed to decide and call 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?

Schema coverage is 100%, so the descriptions of make, model, and modelYear are already documented. The description adds only the 'per body style' output dimension and the year/make/model framing, no format or matching guidance beyond the 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 names the exact resource (electronic stability control, forward collision warning, lane departure warning status per body style) and the exact query key (make, model, model year). It is clearly distinguishable from siblings such as vehicle_crash_ratings and vehicle_recalls, which cover different NHTSA datasets.

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 gives audience framing ('For buyers comparing trims and insurers') and states explicit exclusions (only these three technologies, only NCAP-programme cars, no AEB), which implicitly routes other feature questions elsewhere. It stops short of naming a specific alternative tool for those cases.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the description correctly spends its words elsewhere: partial matching that surfaces related firms such as dealers, deliberate omission of personal contact emails, and a stated cost of 1 credit. The remaining gap is pagination/truncation behavior beyond the limit parameter, which is minor here.

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?

Front-loaded with a scoping question, then the return payload, then caveats and cost — a sensible order with no filler sentences. It is dense and list-like, but every clause carries distinct information rather than restating the name.

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 no output schema, the description compensates by enumerating the returned fields (legal/common name, trading names, address and country, manufacturer type, vehicle types and weight classes, principal, last update), plus source attribution, known false-positive behavior, privacy exclusion, and credit cost. An agent has enough to call it and interpret the result without further digging.

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 the baseline would be 3, but the description adds real meaning beyond the schema's 'partial match, e.g. honda' by explaining the consequence: related firms such as dealers will appear in results. It also reinforces that the identifier may be either a name or a numeric NHTSA manufacturer ID.

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?

Opens with a specific framing question and states a concrete verb+resource: returns NHTSA registration details for manufacturers matching a name or manufacturer ID, then enumerates exactly which fields come back. It is clearly distinguishable from data-heavy siblings like vin_decode or vehicle_recalls, but it never explicitly distinguishes itself from wmi_manufacturer_lookup, which an agent could plausibly confuse it with.

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?

Provides use contexts ('supplier research, KYB and procurement checks'), which implies when to reach for it. However, it gives no when-not guidance and does not route the agent away from the closely related wmi_manufacturer_lookup or vin_decode siblings, leaving the choice to inference.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds real context beyond that: the data source (NHTSA vPIC), result ordering (A to Z), that all vehicle types (cars, motorcycles, trucks) are included, and a cost of 1 credit.

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?

Front-loaded with the core question, then scope, then audience, then caveats and cost. Information density is high, though the 'For dealers, form-filling and data cleaning' clause is the weakest sentence and could be trimmed without loss.

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 no output schema, the description carries the burden of describing returns and does so: a A-to-Z list of model names covering all vehicle types, explicitly excluding trims and specifications. Combined with source attribution and credit cost, an agent has everything needed to call 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?

Schema description coverage is 100%, so make, modelYear, and limit are already documented, and the baseline is 3. The description reinforces that results are keyed to a make and a model year but adds no format, matching, or pagination detail for the limit parameter.

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?

States a specific verb and resource ('Lists the model names NHTSA holds for a make and year') and frames it as a question an agent would actually ask. It also delimits scope ('does not give trims or specifications'), which separates it from spec-oriented siblings like vehicle_driver_assist_features or vin_decode.

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?

Gives a concrete when-to-use: resolve the exact model name before a recall, complaint, or crash-rating lookup, which implicitly routes to vehicle_recalls, vehicle_complaints, and vehicle_crash_ratings. It also names audiences (dealers, form-filling, data cleaning) and an exclusion (no trims/specs), but never explicitly contrasts with wmi_manufacturer_lookup or vehicle_manufacturer_details.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description still adds real behavioral context the annotations do not: the NCAP source, the sales-volume caveat, the coverage restriction to NCAP-programme models, and the 1-credit cost. It does not describe the return shape beyond 'three counts', but the added caveats are substantive.

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?

Front-loads the core question, then layers scope, caveats, alternatives, and cost in a logical order with no filler. The rhetorical opening sentence is slightly indirect compared with a declarative statement, but nothing is wasted.

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?

There is no output schema, and the description compensates by naming the three returned counts. It also closes the two gaps an agent would otherwise hit: sales-volume skew and NCAP-only coverage, plus the sibling routing.

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 each parameter already documents itself with an example, so the description need not restate syntax. The description only implies that make, model, and model year jointly scope the counts, which is baseline for full schema coverage.

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?

States a specific resource and verb set: returns complaint, recall, and federal defect investigation counts for a make/model/model year. It explicitly names what it is not (the detail-level tools vehicle_recalls and vehicle_complaints), so an agent can separate it from its nearest siblings without opening a schema.

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?

Gives a concrete use case ('quick screen when comparing cars') and names the alternatives for drill-down ('Use vehicle_recalls and vehicle_complaints for the detail'), which is an explicit when-to-use and when-to-switch-away instruction.

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

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

Annotations already cover read-only, idempotent and open-world hints, yet the description still adds real value: newest-first ordering, the four data elements returned (component, risk, remedy, do-not-drive/park-outside warnings), the data source, and the 1-credit cost. The main behavioral gap left is pagination/truncation behavior when limit is hit.

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 core purpose is front-loaded in a single question, and the caveats are grouped at the end in parentheses. The middle sentence is dense and carries several clauses at once, which slightly hurts scanability but no sentence is wasted.

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 no output schema, the description usefully enumerates the returned fields and discloses source, ordering and cost. Combined with the schema it is nearly complete; only edge-case behavior such as invalid or ambiguous model names is unaddressed.

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 each parameter is documented in the schema itself. The description only restates that make, model and model year drive the query and says nothing about the limit parameter or acceptable formats, so it adds no meaning beyond the 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 opening question plus 'Lists every US safety recall NHTSA holds for a make, model and model year' names the exact verb, resource and scope, and the NHTSA/US framing separates it from UK DVSA or VIN-level siblings such as recall_campaign_details or vin_decode.

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 clearly states the audience (owners, used-car buyers, fleet managers) and, more usefully, the exclusions: it is not a per-vehicle repair-status check (use VIN) and does not cover UK DVSA recalls. It stops short of naming a sibling tool like recall_campaign_details for drill-down, so routing among siblings relies partly on inference.

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

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

The annotations already establish that this is a safe, idempotent, open-world read operation. The description adds useful behavioral context beyond them: the NHTSA vPIC source, the limitation to maker identification, and a cost of 1 credit. It does not discuss error behavior or lookup latency, which keeps it from a 5.

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 front-loaded with a direct question and the core action, then adds scope, use cases, source and cost without redundant restatement. Every sentence contributes either selection guidance or invocation context.

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 single-parameter lookup with no output schema, the definition covers purpose, input interpretation, limitations, alternatives, provider and cost. Nothing material for correct invocation 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 coverage is 100%, so the input format is already documented, but the description adds real meaning by explaining why six characters are accepted for small manufacturers whose third character is 9, and by confirming that a full 17-character VIN is read only for its prefix.

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 precise verb and resource: it decodes a WMI/VIN prefix to manufacturer, make, vehicle type and region. It explicitly distinguishes itself from a full VIN decoder, so an agent can separate it from sibling tools such as vin_decode and vehicle_manufacturer_details.

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 names concrete use cases (fleet, import, parts, used-car checks) and explicitly says to use a full VIN decoder when model or specification is needed. This gives both when-to-use guidance and a clear alternative for the case this tool does not cover.

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