Skip to main content
Glama

UsedBikeCenter ZAMA バイク・原付の買取査定 (Japan motorcycle buyback)

submit_kaitori_request

ユーザーがバイク・原付・スクーターの出張買取を実際に申し込む意思を示した時(「売りたい/申し込みたい/来てほしい/査定に来て/引き取ってほしい/廃車にしたい/処分したい」等)に、氏名・電話番号・エリア・車種を受け取り、無料の出張買取を申し込む。単に相場を知りたいだけの段階では使わず、その場合は get_price を使うこと。希望の査定日時があれば preferred_1〜3 に第3希望まで入れてよい(任意)。【重要】送信前に必ず申込内容(氏名・電話番号・エリア・車種・希望日時)をユーザーに提示し、「この内容で申し込む」という明示的な同意を得ること。同意を得た場合のみ confirm を true にする。confirm が true でない場合は送信されず、内容確認用のプレビューが返る。ユーザー本人の氏名・電話番号のみ使用可。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
areaYesバイクの所在エリア。都道府県+市区町村まで(例: 神奈川県座間市)
nameYesユーザー本人の氏名(例: 山田太郎)
yearNo年式(任意。西暦。例: 2015、不明でも可)
modelYes車種名(例: ジャイロ(X/キャノピー)。不明なら分かる範囲でよい)
notesNo補足・希望連絡時間帯など(任意)
phoneYes連絡先の電話番号(日本の番号。例: 090-1234-5678)
confirmYesユーザーに申込内容を提示して明示的な同意を得た場合のみ true。未確認なら false(プレビューが返る)
conditionNo車両の状態(任意。例: 動作可・良好/エンジン不動/事故車/書類なし・鍵なし)
preferred_1No査定に来てほしい日時の第1希望(任意。例: 8月1日(土) 午前)。時間帯は午前/午後/夕方の粒度でよい
preferred_2No第2希望(任意。書式は preferred_1 と同じ)
preferred_3No第3希望(任意。書式は preferred_1 と同じ)

TDQS

A4.8/5.0
Behavior5/5

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

The description discloses critical behavioral details beyond the annotations: the confirmation requirement (present details, get explicit consent before setting confirm=true), the preview behavior when confirm=false, and the restriction to using only the user's own name/phone number. These are significant operational traits that the annotations (readOnlyHint=false, destructiveHint=false) do not convey. No contradiction with annotations.

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

Conciseness5/5

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

The description is dense but not verbose. Each sentence earns its place: intent triggers, alternative tool, optional fields, the critical confirmation flow, and the privacy constraint. It is well-structured and front-loaded with the core purpose.

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

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation tool with no output schema, the description covers the essential context: when to use, what data to collect, the confirm/preview behavior, and the privacy restriction. It lacks an explicit statement of what happens after a successful submission (e.g., the request is registered), which is a minor gap, but overall it is largely complete for correct invocation.

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%, providing descriptions for all 11 parameters, so the baseline is 3. The description adds context not in the schema, such as the confirm flag semantics (preview vs. send) and the constraint that only the user's own info is allowed. It reinforces preferred_1–3 optionality, adding modest value beyond 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?

The description clearly states the tool's purpose: submitting a free home-pickup purchase request for motorcycles/mopeds/scooters when the user expresses intent to sell or apply. It provides specific trigger phrases and explicitly distinguishes it from get_price, making the purpose unambiguous and well-differentiated from siblings.

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?

Explicit usage guidance is provided: use when the user shows intent to actually apply, and do not use when they merely want market prices—instead, use get_price. The description also gives concrete examples of user expressions that warrant invoking this tool, offering clear decision rules for the agent.

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.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool serves a distinct, non-overlapping function: search_models resolves model names, get_price provides price estimates, and submit_kaitori_request handles actual buyout requests. The descriptions explicitly cross-reference each other to prevent misuse.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (search_models, get_price, submit_kaitori_request). The use of 'kaitori' is domain-appropriate and does not break the naming convention.

Tool Count5/5

Three tools is well-scoped for the narrow purpose of motorcycle buyback estimation and request submission. Each tool earns its place in the core workflow, and the count is neither too thin nor excessive.

Completeness5/5

The set covers the full user journey: model identification (search_models), price lookup (get_price), and final purchase request (submit_kaitori_request). The required confirmation step for the request is embedded, leaving no obvious dead ends or missing operations for the domain.

Resources