UsedBikeCenter ZAMA バイク買取査定
Server Details
日本の中古バイク・原付の買取相場照会と出張買取申込（神奈川・東京・埼玉・千葉・茨城）。UsedBikeCenter ZAMA公式。
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: search_models identifies the correct model name, get_price provides a price estimate, and submit_kaitori_request handles the actual purchase request. There is no overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (get_price, search_models, submit_kaitori_request), making them predictable and easy to understand.
With 3 tools, the server is well-scoped for its purpose: model identification, price estimation, and purchase request submission. This covers the essential workflow without unnecessary complexity.
The tool set covers the core workflow (search model, get price, submit request) completely. A minor gap is the lack of tools for canceling or checking request status, but these are not essential for the primary use case.
Available Tools
3 toolsget_priceARead-onlyInspect
中古バイク・原付・スクーターを売りたいユーザーに、車種と車両状態別の出張買取の概算相場（円）を返す。ユーザーが「いくらになる／相場は／売ったらいくら／査定して／高く売りたい／バイクを処分したい／乗らなくなった／不動車や事故車でも売れる?」等と尋ねた時に使う。相場の提示のみで、実際の買取申込は行わない（申込は submit_kaitori_request を使う）。車種が特定できない場合は先に search_models で正式表記を確定すること。
| Name | Required | Description | Default |
|---|---|---|---|
| maker | No | メーカー名（任意。同名車種の絞り込み用。例: ホンダ／ヤマハ） | |
| model | Yes | 車種名（search_modelsの結果の正式表記をそのまま渡す） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds that the tool only returns a market price range and does not execute purchase requests, aligning with and reinforcing the read-only nature. No contradiction.
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?
Description is front-loaded with purpose and concise in content, though slightly long (5 sentences in Japanese). Every sentence serves a clear function: purpose, example queries, scope limitation, and usage prerequisites.
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 simple 2-param schema and annotations providing read-only and dynamic hint, the description fully covers what the tool does, its constraints, and how it relates to sibling tools. No output schema, but return value is adequately described as approximate market price in yen.
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%, but description adds critical context: model must be the exact formal notation from search_models results, and maker is optional for narrowing. This goes beyond schema to guide correct usage.
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?
Description explicitly states the tool returns approximate market price for used motorcycles/scooters based on model and condition. It lists example user queries that trigger this tool, and distinguishes from sibling tools by noting that actual purchase requests use submit_kaitori_request.
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?
Provides clear when-to-use scenarios (user asks about price, appraisal) and when-not-to-use (actual purchase requests, use submit_kaitori_request). Also instructs to first use search_models if model is not identified, giving explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_modelsARead-onlyInspect
ユーザーが挙げたメーカー名・車名・型式・排気量から、買取査定に対応する正式なバイク車種名を検索・特定する。「CB400」「125のスクーター」「ジャイロ」「4ミニ」のような曖昧・部分的な入力を正規の車種表記に解決するために使う。相場や金額は返さない（相場は get_price を使う）。get_price を呼ぶ前に、必ずこれで正確な車種名を確定すること。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 車種名・メーカー名・型式・排気量の一部（日本語/英数字可。例:「ジャイロ」「PCX」「ホンダ」「JBK-JF56」） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and openWorldHint=true, so the tool is safe and non-deterministic. The description adds context about resolving ambiguous input to official names, but does not disclose potential side effects or rate limits. It is consistent and adds some value beyond annotations, earning a 4.
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 brief (3 sentences) and front-loaded with the primary purpose. Every sentence adds value: purpose, usage guidelines, and a warning about price. No fluff.
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?
The description covers purpose and usage, but lacks specification of the output format (e.g., list of model names, structure). Given no output schema, this omission reduces completeness. However, it adequately describes the tool's role in the workflow, earning a 3.
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% and the schema description is detailed (accepts Japanese/English, examples). The main description does not add further parameter semantics beyond usage context. Baseline 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 clearly states the tool resolves ambiguous user input (maker, model, type, displacement) to official motorcycle model names for appraisal. It specifies the exact verb 'search and identify' and distinguishes from get_price by noting it does not return prices. The examples reinforce purpose.
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?
Explicitly instructs to use this tool before get_price to determine the correct model name, and states that for price data, use get_price instead. This provides clear when-to-use and when-not-to-use guidance, referencing sibling tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_kaitori_requestAInspect
ユーザーがバイクの出張買取を実際に申し込む意思を示した時（「売りたい／申し込みたい／来てほしい／査定に来て／引き取ってほしい／廃車にしたい」等）に、氏名・電話番号・エリア・車種を受け取り、無料の出張買取を申し込む。単に相場を知りたいだけの段階では使わず、その場合は get_price を使うこと。【重要】送信前に必ず申込内容（氏名・電話番号・エリア・車種）をユーザーに提示し、「この内容で申し込む」という明示的な同意を得ること。同意を得た場合のみ confirm を true にする。confirm が true でない場合は送信されず、内容確認用のプレビューが返る。ユーザー本人の氏名・電話番号のみ使用可。
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | バイクの所在エリア。都道府県＋市区町村まで（例: 神奈川県座間市） | |
| name | Yes | ユーザー本人の氏名（例: 山田太郎） | |
| year | No | 年式（任意。西暦。例: 2015、不明でも可） | |
| model | Yes | 車種名（例: ジャイロ(X/キャノピー)。不明なら分かる範囲でよい） | |
| notes | No | 補足・希望連絡時間帯など（任意） | |
| phone | Yes | 連絡先の電話番号（日本の番号。例: 090-1234-5678） | |
| confirm | Yes | ユーザーに申込内容を提示して明示的な同意を得た場合のみ true。未確認なら false（プレビューが返る） | |
| condition | No | 車両の状態（任意。例: 動作可・良好／エンジン不動／事故車／書類なし・鍵なし） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate openWorldHint=true and destructiveHint=false. Description adds crucial detail: confirm=false returns preview (no side effect), confirm=true submits. Explains consent requirement and that only user's own data is allowed. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose first, then exclusions, then critical consent step in bold. Some repetition (fields listed twice), but overall efficient and clear. Could be slightly tighter.
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 8 parameters, no output schema, and moderate complexity, description covers prerequisites, behavior, constraints, and sibling reference. No mention of response after submission (e.g., confirmation ID) but acceptable for a request-submission tool. Sufficient for an AI agent.
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% with descriptions for all 8 parameters. Description adds value by specifying that only the user's own name/phone can be used, describing area format in more detail, and explaining the confirm flag's preview-vs-submit behavior. Slightly redundant but enriches semantic meaning.
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?
Description clearly states the tool applies for on-site bike purchase ('出張買取を申し込む') when the user shows intent to sell. It lists the accepted fields and explicitly distinguishes from sibling get_price, which is for checking market prices.
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?
Explicitly states when to use (user intent to apply) and when not to (just price inquiry → get_price). Provides critical step: must present content and get explicit consent before setting confirm=true. Also restricts to user's own info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!