Skip to main content
Glama

Check aftermarket part fitment

check_part_fitment
Read-onlyIdempotent

Use this when the user asks whether an aftermarket part (wheel, coilover, muffler, brake pad, intake and so on) fits a specific car generation, or which parts are confirmed to fit it. Pass the model_id of that generation from search_vehicles. Returns {model, url, total, parts, next_offset}. parts lists only the products that a published fitment table, such as the maker's own, names as fit or conditional for this generation; products not tied to any vehicle and fitment guessed from bolt pattern or size are never included, and a size is left out at any position where the table notes it sticks out of the fender or needs bodywork. Each part has name, manufacturer, part_number, part_key, description, official_url and variants: the sizes or versions that fit, each with specification, status (fit or conditional), conditions (for conditional, the notes of the fitment table as written, such as positions, tires, production period or remarks; tell the user about them), list_price_yen (the maker's list price in yen, tax included, for one unit as the maker sells it, and the unit differs by part: one wheel for wheels, so a car takes four; the whole car's kit for suspension such as coilovers; one axle, left and right, for brake calipers and brake pads; for other parts the item as the maker lists it; null when not listed), wheel dimensions when the part is a wheel, and other attributes. url is this generation's page on car-gene.com to show the user; it is null when the generation has no confirmed fitment. The response has no seller prices and no purchase links. Narrow with part_key and query. Parts are cut to fit the response size; when next_offset is not null, call again with offset set to it. An empty parts list means nothing matched among the confirmed fitments; the part may not be researched yet for this generation, so never say it does not fit. Do not use this for the history, specs or developers of a car (use get_vehicle), or to find a garage that installs parts.

Input Schema

NameRequiredDescriptionDefault
queryNoPart number, product name or maker name, such as TE37, RAYS or a part number. Width, case and hyphens are normalized away; words separated by spaces must all match. Omit to list everything confirmed.
offsetNoWhere to start in the list; pass next_offset from the previous response. Omit to start from the beginning.
model_idYesGeneration (model) id, a UUID from search_vehicles (matched_models, or models of get_vehicle). A series id is not accepted: fitment is per generation.
part_keyNoOnly parts of this kind. For example wheel (ホイール), suspension (車高調・サスペンション), muffler (マフラー), brake (ブレーキパッド), brake_caliper (ブレーキキャリパー), intake (エアクリーナー・吸気), rear_spoiler (リアスポイラー). Omit for all kinds.

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 declare a safe read (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantial context beyond them: which products are included (published fitment tables only) and excluded (bolt-pattern/size guesses), the exclusion of sizes flagged as protruding or needing bodywork, the absence of seller prices and purchase links, the null url for unconfirmed generations, and the pagination/empty-result semantics.

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 use case and the return shape before the details, which is the right order. It is dense and long, with a heavily nested sentence about list_price_yen units per part category, but nearly every clause carries information an agent cannot get from the schema or annotations.

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?

No output schema exists, and the description compensates by enumerating the return payload (model, url, total, parts, next_offset) and the shape of each part including variants, status, conditions and unit semantics. Nothing needed to call it correctly or to interpret the response is missing.

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% so the baseline is 3, but the description adds operational meaning: it explains that the response is truncated to fit and how offset/next_offset drives the follow-up call, and that part_key and query are the narrowing levers. The detailed list_price_yen unit semantics also tie back to how variants should be interpreted for the caller.

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?

Opens with a specific verb and resource: answering whether an aftermarket part fits a specific car generation, plus the inverse lookup of what is confirmed to fit. It explicitly differentiates from siblings by naming get_vehicle (history/specs/developers) and search_shops (installers) as the wrong tools for those intents.

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?

States exactly when to invoke it, names the alternative tools for adjacent intents, and gives the pagination condition: 'when next_offset is not null, call again with offset set to it.' It also warns against the natural but wrong conclusion that an empty result means no fitment.

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