ユーザーが挙げたメーカー名・車名・型式・排気量から、買取査定に対応する正式なバイク車種名を検索・特定する。「CB400」「125のスクーター」「ジャイロ」「4ミニ」「原付」のような曖昧・部分的な入力を正規の車種表記に解決するために使う。相場や金額は返さない（相場は get_price を使う）。get_price を呼ぶ前に、必ずこれで正確な車種名を確定すること。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 車種名・メーカー名・型式・排気量の一部（日本語/英数字可。例:「ジャイロ」「PCX」「ホンダ」「JBK-JF56」） |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No contradiction with readOnlyHint/openWorldHint/destructiveHint. Beyond those annotations, the description discloses that the tool normalizes fuzzy input to canonical model names, returns no price data, and is a mandatory pre-step for get_price. It does not detail return cardinality, but the added workflow/scoping context is substantial.
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 compact and front-loaded: purpose, acceptable input examples, exclusion, and prerequisite each get one sentence. There is minimal redundancy and 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 simple read-only search tool with one parameter and no output schema, the description covers what, why, when, and how it relates to get_price. It could be more explicit about whether the result is a single canonical name or a list of candidates, but the overall flow is clear.
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 the single query parameter with 100% coverage, but the description adds meaning by explicitly inviting ambiguous and partial inputs and supplying additional examples ('125のスクーター', '4ミニ', '原付'). This tells the agent it does not need a canonical model name to call the tool.
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 operation: search and identify formal motorcycle model names from user-provided manufacturer/model/type/displacement. It also disambiguates from the price tool by explicitly saying it does not return market prices (use get_price), so an agent can distinguish 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?
It says when to use it (to resolve ambiguous/partial input like 'CB400', '125のスクーター', '原付' into official model notation) and gives an explicit prerequisite: call it before get_price. It also tells the agent what not to use it for by pointing price-related needs to get_price.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.