Skip to main content
Glama

Get US import eligibility under the 25-year rule

get_us_import_eligibility
Read-onlyIdempotent

Use this when the user asks when a Japanese car can be imported into the United States under the twenty-five-year rule, for example whether a Skyline GT-R of a given generation is legal to import yet. First find the car with search_vehicles, then pass its model_id (or series_id for each generation of the series). Returns {series, rule, calendar_url, models}, plus model when a model_id is given. Each entry in models has id, name, chassis_code, start_year, end_year, url (its page, in English when there is one) and us_import: first_cars_eligible and last_cars_eligible (the year and month when the first and the last cars of that generation turn twenty-five; month null means the sources give only the year, never January), in_production (true when the generation is still on sale, so the last cars have not been built; last_cars_eligible is then null) and based_on (minor_changes when counted from the dated revisions of the generation, generation_years when only the years the generation was sold are known). An empty models list or a null first_cars_eligible means the dates are not researched yet, never that the car cannot be imported. rule states how the rule counts: from each car's month and year of manufacture, while these dates come from sale dates, so tell the user that the build plate of the actual car decides. Compare the dates with today yourself; the response does not say whether a date has passed. calendar_url lists the generations reaching twenty-five years in each year. Do not use this for import paperwork, costs or emission rules, which it does not cover.

Input Schema

NameRequiredDescriptionDefault
model_idNoGeneration (model) id (a UUID from search_vehicles). Takes precedence over series_id when both are given.
series_idNoSeries id (a UUID from search_vehicles).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, but the description adds substantial non-structured context: an empty models list or null first_cars_eligible means 'not researched', never 'cannot import'; the rule counts from manufacture date while the provided dates come from sale dates; and the caller must compare dates to today themselves. These are exactly the caveats an agent needs to avoid a wrong answer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the trigger and the prerequisite call, and every clause about null semantics and the build-plate caveat is load-bearing. The middle section is a very dense run-on enumerating return fields, which makes it heavier to parse than ideal, though no output schema exists to absorb that detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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 full burden and does so: it documents the response shape ({series, rule, calendar_url, models}), every field of a model entry, and the null/empty-value interpretations. An agent can call it and interpret the result correctly without further information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already explains model_id precedence and the exactly-one-of constraint. The description still adds value by explaining when to use series_id (to get every generation of a series) and that passing model_id also returns a 'model' field, information not present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: retrieving US import eligibility under the twenty-five-year rule for Japanese cars, with a concrete example (Skyline GT-R legality). It is clearly distinct from siblings like get_vehicle or search_used_cars because it names search_vehicles as the required lookup step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with an explicit trigger ('Use this when the user asks when a Japanese car can be imported...'), gives the prerequisite workflow (find the car with search_vehicles first), and closes with an explicit exclusion ('Do not use this for import paperwork, costs or emission rules'). The when/when-not/alternative structure is complete.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources