JPYC (JPY stablecoin) EC platform MCP: product search, x402 gasless checkout, order status.
Scored across 9 tools
Most tools have clearly distinct resource/action boundaries: shop listing vs. shop detail, product search vs. shop inventory, and order history. The payment flow has some inherent overlap between quote_checkout, authorize_transfer, and submit_payment, but descriptions clarify when each is required. An agent must still track the selected payment method carefully, so it is not quite perfect.
All tool names use predictable snake_case and mostly follow a verb_noun pattern: list_shops, get_shop, list_products_in_shop, get_product, search_products, quote_checkout, submit_payment. The pattern is consistent throughout, with no mixed casing or vague naming.
Nine tools is well-scoped for a storefront plus checkout workflow. Each tool covers a distinct step: discovery, product lookup, quoting, authorization, payment submission, and order history. There are no obviously redundant tools.
The core buyer lifecycle is covered: browse shops, search/list products, inspect product details, quote checkout, authorize if needed, submit payment, and check orders. Minor gaps remain, such as retrieving a single order by ID or canceling an existing reservation, but agents can work around these.
erc20-transfer 方式だけで、JPYC を送金する前に必ず呼ぶ。quote_checkout の選択した accept にある extra.payerAuthorization.message をウォレットで personal_sign し、その署名と reservation_id を渡す。サーバは EOA / ERC-1271 / ERC-6492 を検証して予約へ固定する。このツール自体は送金も approve も行わない。成功を確認してから accepted.amount ぴったりを transfer すること。eip3009 方式では呼ばない。
| Name | Required | Description | Default |
|---|---|---|---|
| signature | Yes | payerAuthorization.message の personal_sign 署名 | |
| reservation_id | Yes | quote_checkout が返した reservation_id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden well: it discloses server-side verification of EOA/ERC-1271/ERC-6492 signatures and reservation fixation, and clarifies that the tool itself does not send or approve. It does not specify failure behavior or idempotency, but the key safety and side-effect context is present.
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 dense but front-loaded, starting with the method condition and the mandatory pre-transfer call. Every sentence carries operational information: signing procedure, server verification, non-transfer behavior, success condition, and eip3009 exclusion. There is 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 two-parameter signing/authorization tool without annotations or an output schema, the definition covers the critical prerequisites, the signature source, server verification behavior, the fact that funds are not moved, and the required follow-up transfer. Nothing essential for correct invocation appears to be missing.
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 description coverage is 100%, so the schema already documents both parameters. The description adds useful source context: the signature must be a personal_sign of extra.payerAuthorization.message from the selected accept in quote_checkout, and reservation_id comes from that quote. This meaningfully complements the schema.
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 action: pre-authorize a JPYC transfer by signing a payerAuthorization message and passing the signature with a reservation_id. It distinguishes the tool from execution by explicitly saying it does not send funds or approve, and it names the quote_checkout source. An agent can tell this is a signature-submission step, not the transfer itself.
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 explicitly says to call only for the erc20-transfer method and never for eip3009, and that it must be called before sending JPYC. It also gives the post-call flow: after success, transfer exactly accepted.amount. Both the when-to-use and when-not-to-use conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
購入履歴専用のSIWE署名で本人確認した注文履歴を最大50件返す。署名は一度だけ利用できる。
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| message | Yes | Purchase-history SIWE message; see the orders API authentication statement | |
| signature | Yes | ||
| customer_address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses a non-obvious constraint – the SIWE signature is single-use ('署名は一度だけ利用できる') – which is exactly the kind of behavior an agent cannot get elsewhere. It does not say what happens on signature reuse, whether the signature expires, or how errors/authorization failures surface.
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?
Two short sentences, zero filler, with the result scope front-loaded and the credential constraint immediately after. Every clause earns its place.
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?
With no annotations, no output schema, and 4 parameters at 25% schema coverage, the description should state more: pagination behavior relative to 'offset', what an order record contains, and failure modes. It covers authentication and result cardinality adequately but leaves the return shape and pagination implicit.
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 only 25%, so the description must compensate, and it partially does: it clarifies that the signature and message are a purchase-history-specific SIWE pair tied to identity verification, and that results cap at 50. However the 'offset' parameter is never mentioned and no format or limit semantics are given for 'signature'/'customer_address', leaving half the inputs unexplained.
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 names a specific verb and resource ('注文履歴を最大50件返す') and scopes the result set (max 50). It is clearly distinguishable from the product/shop/payment siblings, though it never names an alternative explicitly.
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?
Usage is only implied by the phrase '購入履歴専用のSIWE署名' – the agent can infer this is the read path for order history requiring purchase-history credentials, but there is no explicit when-to-use, when-not-to-use, or pointer to any sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
1 つの商品の詳細を product_id で取得する。価格（JPYC 建て）・在庫・SKU・バリエーション・配送要否・対応チェーンを返す。購入の前に必ず呼んで、requires_shipping（配送先が必要か）と has_variants（オプション選択が必要か）を確認すること。
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | 商品 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the returned data and two critical flags to inspect. It implies a read-only operation but could mention idempotency or absence of side effects.
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?
Two sentences, front-loaded with the action, and no wasted words. Perfectly concise for the information conveyed.
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 the tool's simplicity (1 param, no output schema), the description completely covers what the tool does and what it returns. It also provides actionable guidance for purchase flow.
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 one parameter described. The description adds usage context but no additional parameter semantics beyond the schema. 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 fetches details of a single product by product_id. It lists specific returned fields (price in JPYC, stock, SKU, variations, shipping requirement, supported chains), distinguishing it from sibling tools like list_products_in_shop.
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?
The description explicitly instructs to call this tool before purchase to check requires_shipping and has_variants. While it does not mention alternatives, the context is clear and helpful for the agent's decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
1 つのショップ（生産者・職人）の詳細を slug で取得する。ショップのストーリーや説明、対応ブロックチェーン、x402 決済が有効かどうかを返す。
| Name | Required | Description | Default |
|---|---|---|---|
| shop_slug | Yes | ショップの slug（URL 識別子） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It implies a read operation via '取得する' and specifies returned fields, but does not explicitly state that the tool is read-only, idempotent, or error handling behavior (e.g., if shop not found). This is sufficient for a simple GET but could be improved.
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 a single concise sentence that front-loads the action and lists key return data. No filler or redundant information, achieving high efficiency.
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 tool with one parameter and no output schema, the description covers the return data adequately. It could be enhanced by mentioning error cases or format details, but is mostly complete for operational use.
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 input schema has 100% coverage with parameter description 'ショップの slug（URL 識別子）'. The description adds 'slug で取得する' confirming the parameter role, but does not add substantial new meaning. Baseline score of 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 retrieves details of one shop by slug and lists the returned data (story, description, supported blockchains, x402 payment status). It effectively distinguishes from siblings like list_shops (which returns multiple shops) and get_product (which returns product details).
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?
The description implies when to use (when you need specific shop details by slug) but does not explicitly mention when not to use or suggest alternatives, such as using list_shops for browsing or get_product for product details. Guidance is adequate but could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
1 つのショップの公開中の商品をすべて返す。価格（JPYC 建て）・在庫・バリエーション・配送要否・対応チェーンを含む。list_shops でショップを見つけたあと、その品揃えを見るのに使う。
| Name | Required | Description | Default |
|---|---|---|---|
| shop_slug | Yes | ショップの slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description reveals some behavioral traits: it returns only published products and lists included fields. However, it does not disclose potential pagination, rate limits, authentication requirements, or what happens if the shop slug is invalid. The description provides moderate transparency but leaves gaps.
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 concise, consisting of two clear sentences. It front-loads the primary purpose and efficiently adds contextual usage guidance without wasted words.
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 the tool has one parameter and no output schema, the description adequately explains the return fields (price, stock, variations, etc.) and the intended workflow (after list_shops). It lacks error handling or edge-case behavior but is sufficient for the tool's simplicity.
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 description coverage is 100%, and the description adds marginal value by explaining the slug parameter contextually (used to identify which shop's products to fetch). It does not add new meaning beyond the schema, maintaining the baseline score.
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 it returns all published products in one specific shop, including details like price (JPYC), stock, variations, shipping, and corresponding chains. It explicitly differentiates from siblings like list_shops by indicating this tool is for viewing a shop's assortment after finding the shop.
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?
The description provides explicit guidance to use list_shops first, then this tool for assortment. It implies when to use but does not explicitly state when not to use (e.g., for searching across shops) or name alternative sibling tools directly, though context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JPYC EC Platform に出店している公開ショップの一覧を返す。減農薬の農産物・地酒・伝統工芸品など、生産者から直接買えるショップが中心。各ショップの name / slug / 説明 / 対応チェーン / 商品点数を含む。商品を探す起点として最初に呼ぶとよい。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes the full burden. It clearly indicates the tool is read-only (returns a list) and specifies the output fields. It does not mention pagination or potential errors, but for a zero-parameter list tool, this is adequate.
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 three sentences, front-loaded with the core purpose, then details and usage suggestion. Every sentence adds value with no redundancy.
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 the simplicity (no parameters, no output schema), the description covers the essential: what it does, what it returns, and when to call it. It could mention edge cases like empty lists, but is otherwise complete for effective use.
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 tool has no parameters, and the input schema has 100% coverage. The description does not need to add parameter details. The baseline for zero parameters is 4.
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 it returns a list of public shops on the JPYC EC Platform, specifies the types of shops (direct-from-producer, specific product categories), and lists the included fields. It differentiates from siblings like get_shop and list_products_in_shop by positioning itself as the entry point for product searching.
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?
The description explicitly advises calling this tool first as a starting point for product search, implying it should be used before more specific tools like get_shop or list_products_in_shop. However, it does not explicitly mention when to avoid using it or provide alternatives for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
カートの内容で x402 チェックアウトの 1 回目を実行する。在庫を仮押さえし（有効期限は返り値 expires_at_unix_ms）、小計・割引・送料・合計（JPYC）と reservation_id、および PAYMENT-REQUIRED チャレンジ（base64url、x402 accepts 配列）を返す。accepts の決済方式: 『eip3009』(既定。通常購入の EOA ウォレットはこちらを選び、EIP-712 TransferWithAuthorization に署名する) と『erc20-transfer』(ecrecover 非対応のスマートコントラクトウォレット専用。payer_address を渡した予約にだけ提示される。extra.payerAuthorization.message を personal_sign して authorize_transfer を呼び、その成功後に表示額ぴったりの通常 ERC-20 transfer を実行し、txHash 任意/payerAddress 必須で submit_payment に渡す)。0円デモは demo_signature_version=1 と payer_address を渡すと demo-signature を提示する。送金せず personal_sign だけで完了する。全 item は同一ショップである必要がある。配送が必要な商品があれば shipping を、贈答なら gift_recipient を必ず渡すこと。
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | 購入する商品 | |
| is_gift | No | 贈答かどうか | |
| shop_id | Yes | ショップ ID（全 item 共通） | |
| shipping | No | 配送先（配送が必要な商品がある場合は必須） | |
| coupon_code | No | ショップから受け取ったクーポンコード（任意。NFT割引との併用不可） | |
| customer_note | No | 注文メモ | |
| payer_address | No | 支払いに使うウォレットアドレス（任意・推奨）。指定すると settle 時に支払いに使うウォレットと照合され、別ウォレットからの支払いは拒否される。スマートコントラクトウォレットで erc20-transfer 方式を使う場合は必須（指定が無いと accepts に erc20-transfer が提示されない） | |
| customer_email | Yes | 注文確認メールの送信先（必須） | |
| gift_recipient | No | 贈り先（is_gift が true なら必須） | |
| idempotency_key | No | 同じ見積もりの再試行で必ず再利用する一意キー。クーポン利用時は必須（UUID推奨）。異なる購入内容に同じキーを使わないこと | |
| preferred_chain_id | No | 希望チェーン（任意。商品の対応チェーンから選ばれる） | |
| demo_signature_version | No | 0円デモのpersonal_signに対応する場合のみ指定 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses the inventory hold and its expiry (expires_at_unix_ms), the returned totals in JPYC plus reservation_id and the PAYMENT-REQUIRED challenge, the payer_address-to-wallet matching enforced at settle with rejection of a different wallet, and the 0-yen demo path that completes with personal_sign and no transfer. These are side effects and lifecycle facts an agent cannot infer from the schema.
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?
Length is justified by a 12-parameter, multi-step protocol, and the purpose is front-loaded before the payment-method branching. The middle section compresses several distinct concerns into dense parenthetical clauses, which slightly hurts scannability, but every sentence carries information.
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?
There is no output schema and the operation is complex, so the description must carry both behavior and return values – and it does, enumerating the quote fields, reservation_id, and the PAYMENT-REQUIRED challenge format (base64url, accepts array). An agent has enough to select the correct payment branch and invoke the tool correctly.
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 description coverage is already 100%, so the baseline is 3. The description nevertheless adds cross-parameter meaning the schema cannot express: payer_address changes the contents of the accepts array (erc20-transfer is only offered for reservations that pass it), demo_signature_version selects the demo-signature path, and shipping/gift_recipient become mandatory under stated conditions.
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?
States a specific verb and resource (executes the first round of x402 checkout for the cart contents) and immediately names the downstream siblings it hands off to (authorize_transfer, submit_payment). The agent can distinguish this reservation/quote step from payment submission without opening either schema.
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?
Gives explicit routing rules: EOA wallets choose 'eip3009', smart-contract wallets without ecrecover use 'erc20-transfer' only when payer_address was supplied, and demo mode uses demo_signature_version=1. It also states prerequisites (all items same shop, shipping required for shippable goods, gift_recipient for gifts). It stops short of naming an alternative to quote_checkout itself, but the conditional guidance is unusually strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JPYC EC Platform 上の公開商品を横断検索する。減農薬米・地酒・伝統工芸品など、生産者から直接 JPYC で購入できる商品が対象。text は自然言語のキーワード（例: 『丹波 米』）で、商品名と説明に部分一致する。category / tag（産地・認証種別など）、価格帯（min_price / max_price、JPYC）、shop_slug で絞り込める。売上順で最大 50 件返す。
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | 商品タグ（産地・認証種別など）の完全一致 | |
| text | No | 自然言語のキーワード（商品名・説明に部分一致） | |
| limit | No | 最大件数（1-50、既定 20） | |
| category | No | 商品カテゴリーの完全一致 | |
| max_price | No | 最高価格（JPYC） | |
| min_price | No | 最低価格（JPYC） | |
| shop_slug | No | 特定ショップに絞り込む |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses sorting by sales and a maximum of 50 results, but does not mention authentication, error behavior, or pagination. This is adequate but not comprehensive.
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 a single, well-structured paragraph that starts with the primary purpose, then lists examples, then details each parameter. Every sentence adds useful information with no redundancy.
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?
With 7 parameters and no output schema, the description covers purpose, parameters, sorting, and limit. It does not describe the return structure, but the agent can infer from sibling tools. Additional detail on default behavior (e.g., default limit of 20) would improve completeness.
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%, so baseline is 3. The description adds value by providing examples ('text' with '丹波 米'), clarifying 'tag' as region/certification, and noting that prices are in JPYC. This goes beyond the schema descriptions.
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 identifies the tool as a cross-search across public products on the JPYC EC Platform, with examples of product types (e.g., reduced-pesticide rice, sake, crafts). It distinguishes from sibling tools like list_products_in_shop (per-shop) and get_product (single product) by specifying cross-shop scope.
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?
The description implies usage for broad product discovery across multiple shops, with filtering options. It does not explicitly state when not to use or provide alternatives, but the sibling context and filtering parameters (e.g., shop_slug) guide appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote_checkout で得た reservation_id と、エージェントが用意した x402 PaymentPayload（base64url）を渡して決済を確定する。demo-signatureならextra.payerAuthorization.messageをpersonal_signし、{payerAddress,demoSignature}を渡す。送金やauthorize_transferは呼ばない。quote_checkout の accepts から選んだ方式に応じて payload の中身が変わる: 『eip3009』なら { signature, authorization } (EIP-712 TransferWithAuthorization の署名)、『erc20-transfer』なら { payerAddress, txHash? } (ウォレットが実行した通常の ERC-20 transferの送金元アドレス。txHash は分かれば渡す任意ヒント — 無くてもサーバがon-chain のログを検索して照合する)。erc20-transfer は送金前に必ず authorize_transfer を成功させる。eip3009 はサーバが facilitator 経由で on-chain settle し、erc20-transfer はユーザーが既に送金したものをサーバが検証するだけ。いずれも確定した注文（order_number / tx_hash）を返す。
| Name | Required | Description | Default |
|---|---|---|---|
| reservation_id | Yes | quote_checkout が返した reservation_id | |
| payment_signature | Yes | 署名済み x402 PaymentPayload（base64url JSON） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it explains the demo-signature path, the server's facilitator-based on-chain settlement for eip3009, the server's verification-only role for erc20-transfer, and the confirmed order fields returned. The only blemish is the ambiguous authorize_transfer instruction, but the behavioral model is otherwise explicit and useful.
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 text is dense and organized by method; the core invocation appears in the first sentence and each later sentence adds a distinct piece of information. It is longer than minimal, but the length is mostly functional given the method-specific complexity.
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 inputs, method-dependent payload construction, prerequisites, and return fields despite no output schema. Minor gaps are that 'demo-signature' and 'extra.payerAuthorization' are name-dropped without full definition, and failure cases are not addressed, but these are marginal for an agent that already has quote_checkout context.
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?
Even though schema coverage is 100%, the description adds critical structure for payment_signature by method: { signature, authorization } for eip3009, { payerAddress, txHash? } for erc20-transfer, and { payerAddress, demoSignature } for demo-signature. It also clarifies that txHash is optional, which is exactly the meaning an agent needs beyond the schema's generic 'base64url JSON' label.
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 names a precise action — confirm settlement with a reservation_id and x402 PaymentPayload — and positions it as the second step after quote_checkout. It also distinguishes itself from transfer/authorize_transfer and details the two payment methods, so an agent can tell it apart 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 gives clear flow context (after quote_checkout, with a prepared PaymentPayload) and method-specific requirements for eip3009 vs erc20-transfer, and it explicitly names alternatives. However, the instruction '送金やauthorize_transferは呼ばない' conflicts with the later requirement to succeed at authorize_transfer before an erc20-transfer, leaving some ambiguity about when to call the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_order_status5 fields changedInput schema / properties / customer_address / descriptionRemoved value: -"顧客のウォレットアドレス（0x...）"Input schema / properties / messageAdded value: +{
+ "description": "Purchase-history SIWE message; see the orders API authentication statement",
+ "maxLength": 8192,
+ "type": "string"
+}Input schema / properties / offsetAdded value: +{
+ "maximum": 10000,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / signatureAdded value: +{
+ "maxLength": 4096,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "customer_address"
-]New value: +[
+ "customer_address",
+ "message",
+ "signature"
+]quote_checkout1 field changedInput schema / properties / payer_address / descriptionPrevious value: -"支払いに使うウォレットアドレス（任意・推奨）。指定すると settle 時に支払い元と照合され、別ウォレットからの支払いは拒否される。スマートコントラクトウォレットで erc20-transfer 方式を使う場合は必須（指定が無いと accepts に erc20-transfer が提示されない）"New value: +"支払いに使うウォレットアドレス（任意・推奨）。指定すると settle 時に支払いに使うウォレットと照合され、別ウォレットからの支払いは拒否される。スマートコントラクトウォレットで erc20-transfer 方式を使う場合は必須（指定が無いと accepts に erc20-transfer が提示されない）"quote_checkout1 field changedInput schema / properties / demo_signature_versionAdded value: +{
+ "const": "1",
+ "description": "0円デモのpersonal_signに対応する場合のみ指定",
+ "type": "string"
+}quote_checkout2 fields changedInput schema / properties / coupon_codeAdded value: +{
+ "description": "ショップから受け取ったクーポンコード（任意。NFT割引との併用不可）",
+ "maxLength": 64,
+ "minLength": 1,
+ "pattern": "^[A-Za-z0-9][A-Za-z0-9_-]*$",
+ "type": "string"
+}Input schema / properties / idempotency_keyAdded value: +{
+ "description": "同じ見積もりの再試行で必ず再利用する一意キー。クーポン利用時は必須（UUID推奨）。異なる購入内容に同じキーを使わないこと",
+ "maxLength": 64,
+ "minLength": 16,
+ "pattern": "^[A-Za-z0-9_-]+$",
+ "type": "string"
+}authorize_transferquote_checkout1 field changedInput schema / properties / payer_addressAdded value: +{
+ "description": "支払いに使うウォレットアドレス（任意・推奨）。指定すると settle 時に支払い元と照合され、別ウォレットからの支払いは拒否される。スマートコントラクトウォレットで erc20-transfer 方式を使う場合は必須（指定が無いと accepts に erc20-transfer が提示されない）",
+ "pattern": "^0x[0-9a-fA-F]{40}$",
+ "type": "string"
+}get_order_statusget_productget_shoplist_products_in_shoplist_shopsquote_checkoutsearch_productssubmit_paymentOAuth-protected JPYC wallet, transfer, and contract workflows on Polygon.
Agentic commerce + trust MCP: discover, verify, and transact across droplinked's merchant network.
Discover and pay for APIs with USDC credits. No wallet, no gas, MCP-native marketplace.
Multi-seller shopping for AI agents. Settle via Stripe MPP or x402 USDC on Base. Hosted.
Add one secure layer between your agents and this server.
