Original factory window stickers (Monroney labels) by VIN for 20 makes, plus an NHTSA spec decode.
Scored across 3 tools
Each tool serves a clearly distinct intent: one performs a VIN lookup, one enumerates covered makes/model years, and one explains a negative result. There is no realistic scenario where an agent would confuse which tool to call.
All names use consistent snake_case, which is good. The verb styles vary slightly (imperative get_ vs. interrogative which_/why_), but the semantics are transparent and readable, so this is a minor deviation rather than a real inconsistency.
Three tools is on the thin side, but the server's scope is a single narrow lookup service, so each tool earns its place. Two of the three are meta/explanation tools rather than core operations, which is justified by the domain but keeps it from being a perfect fit.
For a read-only lookup service, the surface covers the main query, the coverage map, and the failure explanation, leaving no obvious dead end. Minor gaps exist (no batch lookup or VIN validation helper), but agents can work around these easily.
Look up the original factory window sticker (Monroney label) for a 17-character VIN, with an NHTSA specification decode. Returns links, never the PDF itself: page is the result page to give a person, and pdf is the label when one exists. For Toyota, Lexus, Nissan and Infiniti it returns only labels we already hold. Free, no key.
| Name | Required | Description | Default |
|---|---|---|---|
| vin | Yes | 17-character VIN. VINs never contain I, O or Q. |
| Name | Required | Description |
|---|---|---|
| vin | Yes | |
| vehicle | Yes | NHTSA vPIC decode. Null when vPIC did not recognise the VIN. |
| warning | Yes | |
| windowSticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses that only links are returned (not the PDF), explains the meaning of the two fields (page vs pdf), names the makes with restricted coverage, and states it is free with no key. This is rich, non-obvious 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?
Two dense sentences, front-loaded with the core lookup, then the return contract (links not PDF, page vs pdf), then the make restriction and cost. No 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?
For a one-parameter read-only lookup with an output schema and full schema coverage, the description covers purpose, return contract, and coverage caveats. It doesn't reference the sibling routing tools, which would make it fully complete for an agent choosing among the three.
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 vin parameter is already documented with the 17-character constraint and the I/O/Q exclusion. The description restates the 17-character requirement but adds no format or validation detail 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?
States a specific verb (look up) and resource (original factory window sticker / Monroney label) tied to a 17-character VIN, and adds an NHTSA spec decode. The special-case coverage note for Toyota/Lexus/Nissan/Infiniti further sharpens what the tool returns, distinguishing it from siblings.
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 Toyota/Lexus/Nissan/Infiniti caveat and the 'returns links, never the PDF' behavior give clear context about when this tool applies and what to expect. It doesn't explicitly route to the sibling tools (which_makes_are_covered, why_no_sticker), so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 20 makes that return an original factory window sticker, by source, with the model years each answers for and the last day it returned a label. Every other make gets a specification decode only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| asOf | Yes | |
| notes | Yes | |
| sources | Yes | |
| coverageUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavioral context beyond the annotations: it explains the coverage boundary (only 20 makes) and what happens for every other make (specification decode only), which shapes how an agent interprets results.
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 tight sentences, front-loaded with the core content ('the 20 makes that return...') and the scope/fallback constraint placed last. No filler or redundant restatement of the title.
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 an output schema present, return-value structure need not be explained, and annotations cover safety. The description supplies the coverage semantics that the schema cannot convey, leaving only minor gaps (e.g., no explicit pointer to the sibling lookup flow).
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 tool takes zero parameters, so there are no parameter semantics to document; baseline 4 applies. The description correctly focuses on output scope instead of inventing parameter detail.
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 concretely what the tool returns: the list of 20 makes eligible for an original factory window sticker, including per-source, model years, and last-eligible date. It implicitly contrasts with the other make-universe tools (only 20 makes qualify), but does not name the siblings get_window_sticker or why_no_sticker explicitly.
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?
Usage is implied rather than stated: an agent can infer this is the coverage-lookup step before calling get_window_sticker, and the closing sentence clarifies the fallback for non-covered makes. There is no explicit when-to-use/when-not or named alternative, so it stays at the implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Why a make, or a make and model year, has no window sticker here, and where to get one instead. Covers makes we get labels for (Ford only while a car is new, Toyota from 2025) and makes we don’t (Honda, Mazda, Tesla).
| Name | Required | Description | Default |
|---|---|---|---|
| make | Yes | Make name, such as Ford, Chevrolet or Honda. | |
| model_year | No | Model year, such as 2019. Optional; the Toyota and Lexus answer depends on it. |
| Name | Required | Description |
|---|---|---|
| make | Yes | |
| steps | Yes | |
| reason | Yes | |
| source | Yes | |
| moreUrl | Yes | |
| warning | Yes | |
| headline | Yes | |
| modelYear | Yes | |
| supported | Yes | We have a source of original labels for this make. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already signal read-only and open-world behavior. The description adds useful behavioral context beyond that: coverage varies by make, Ford stickers exist only while a car is new, Toyota coverage starts in 2025, and the tool also points to where a sticker can be obtained instead. No contradiction with the 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 sentences, front-loaded with the exact question the tool answers, followed by concrete coverage examples. No filler or redundant restatement of the tool name or schema.
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 a simple read-only explanation tool with two parameters, full schema coverage, and an output schema, the description covers purpose, scope, caveats, and fallback guidance. It could have explicitly referenced sibling tools, but nothing essential for invoking 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?
The schema already documents both parameters fully, with make described by example and model_year marked optional with the Toyota/Lexus dependency. The description adds extra examples (Ford, Toyota, Honda, Mazda, Tesla) and confirms model-year relevance, but does not need to add more because schema coverage is complete.
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 clear purpose: explaining why a make or make/model-year has no window sticker and where to get one instead. It differentiates from get_window_sticker by focusing on absence rather than retrieval, and although it never names sibling tools, the scope is specific enough for an agent to identify the tool's role.
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 context for when the tool applies: when a window sticker is missing, with coverage details by make and model-year. It does not explicitly exclude cases or name alternatives like which_makes_are_covered, but the intended usage is strongly implied and not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_window_sticker2 fields changedOutput schema / properties / windowSticker / properties / paintAdded value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "code": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "color": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Exterior color as printed on the label, with its paint code where the label carries one (Toyota; Hyundai and Genesis when paint is a priced option). Null when there is no label or it names no color."
+}Output schema / properties / windowSticker / requiredPrevious value: -[
- "supported",
- "available",
- "pdf",
- "page",
- "note"
-]New value: +[
+ "supported",
+ "available",
+ "pdf",
+ "page",
+ "note",
+ "paint"
+]which_makes_are_covered2 fields changedOutput schema / properties / sources / items / properties / heldCopiesOnlyRemoved value: -{
- "description": "get_window_sticker returns only labels we already hold.",
- "type": "boolean"
-}Output schema / properties / sources / items / requiredPrevious value: -[
- "source",
- "makes",
- "modelYears",
- "lastConfirmed",
- "note",
- "heldCopiesOnly",
- "paused"
-]New value: +[
+ "source",
+ "makes",
+ "modelYears",
+ "lastConfirmed",
+ "note",
+ "paused"
+]get_window_stickerwhich_makes_are_coveredwhy_no_stickerDecode any VIN and check open NHTSA safety recalls. Free official US government data, no auth.
Vehicle specs, VIN decoding, NHTSA recalls and safety ratings by year, make, model or VIN.
Decode VINs, search recalls, complaints, crash ratings, and investigations.
US vehicle recalls, complaints, EPA figures, VIN decode and trouble codes, with sources.
Add one secure layer between your agents and this server.
