Original factory window stickers (Monroney labels) by VIN for 20 makes, plus an NHTSA spec decode.
Scored across 3 tools
Each tool has a clearly distinct purpose: fetching a sticker by VIN, listing coverage, and explaining gaps. Although which_makes_are_covered and why_no_sticker both touch coverage, their outputs and intents are clearly separated.
The names are readable and descriptive, but they mix conventions: get_window_sticker uses a verb_noun pattern while which_makes_are_covered and why_no_sticker use question-style phrasing. A more uniform list_/get_/explain_ style would be more consistent.
Three tools is well-scoped for this narrow domain: one primary lookup action and two supporting informational tools. Each tool earns its place and there is no redundancy.
The tool surface covers the full workflow: retrieve a sticker, understand current coverage, and learn why a sticker is unavailable with alternatives. Even unsupported VINs still get a specification decode, so there is no obvious dead end.
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?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses that it returns only links (never the PDF), explains the page/pdf key semantics, reveals the 'only labels we already hold' constraint for Toyota, Lexus, Nissan and Infiniti, and states that no API key is needed. This is rich behavioral context that the annotations alone do not provide, and nothing contradicts 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?
The description is four sentences and front-loaded: core purpose first, then return format, then coverage caveat, then auth. Each sentence adds distinct value; the only minor redundancy is restating '17-character VIN' from the schema, and the 'Free, no key' tag is efficient and useful.
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 tool with an output schema present, the description covers purpose, return semantics, make-specific coverage limits, and auth requirements. It does not specify behavior when no sticker is found, but the sibling why_no_sticker plausibly covers that case, and the output schema documents the return structure.
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% — the schema already documents the 17-character VIN, the forbidden letters I/O/Q, and requiredness. The description mostly restates the 17-character constraint and adds a modest extra: the 'NHTSA specification decode,' which implies validation of the input. Since the schema carries the full parameter burden, the baseline 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 states a specific verb and resource: 'Look up the original factory window sticker (Monroney label) for a 17-character VIN.' It goes beyond the title by naming the Monroney label, the NHTSA decode, and the key return behavior (links, not PDFs), which distinguishes it from siblings like which_makes_are_covered and why_no_sticker.
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 (free, no key, coverage limits for four makes) but never explicitly routes the agent to alternatives. It implies usage — use this tool to fetch a sticker — yet does not say 'use which_makes_are_covered to check coverage' or 'use why_no_sticker when no label exists,' so when/when-not guidance is only implicit.
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 indicate read-only and open-world hints. The description adds behavioral detail: the specific output fields (model years, last day) and the fallback behavior for other makes. It does not contradict annotations and provides useful context beyond what structured fields convey.
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 wasted words. The core output is front-loaded, and the fallback is stated concisely. Every sentence earns its place.
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 parameters and an existing output schema, the description fully covers what the tool does, its scope, and its fallback. Nothing an agent needs to decide on usage 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?
There are zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and the schema is empty, so nothing is missing.
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's function: it returns the 20 makes that have an original factory window sticker, along with model years and last coverage date. It also distinguishes itself from siblings by focusing on the list of covered makes rather than individual sticker retrieval or reasons for non-coverage.
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 implies when to use this tool (to get coverage information) and explicitly states what happens for non-covered makes, serving as an exclusion. However, it doesn't directly name alternatives or provide explicit when/not conditions, though the sibling names make the distinction obvious.
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_stickerwhich_makes_are_coveredwhy_no_stickerDecode any VIN and check open NHTSA safety recalls. Free official US government data, no auth.
Decode VINs, search recalls, complaints, crash ratings, and investigations.
US vehicle recalls, complaints, EPA figures, VIN decode and trouble codes, with sources.
Vehicle data for AI: VIN decoder, automotive specs, stolen checks, valuation and way more.
Add one secure layer between your agents and this server.
