Skip to main content
Glama

チェックアウト見積もり(x402 1回目)

quote_checkout

カートの内容で 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 を必ず渡すこと。

Input Schema

NameRequiredDescriptionDefault
itemsYes購入する商品
is_giftNo贈答かどうか
shop_idYesショップ ID(全 item 共通)
shippingNo配送先(配送が必要な商品がある場合は必須)
coupon_codeNoショップから受け取ったクーポンコード(任意。NFT割引との併用不可)
customer_noteNo注文メモ
payer_addressNo支払いに使うウォレットアドレス(任意・推奨)。指定すると settle 時に支払いに使うウォレットと照合され、別ウォレットからの支払いは拒否される。スマートコントラクトウォレットで erc20-transfer 方式を使う場合は必須(指定が無いと accepts に erc20-transfer が提示されない)
customer_emailYes注文確認メールの送信先(必須)
gift_recipientNo贈り先(is_gift が true なら必須)
idempotency_keyNo同じ見積もりの再試行で必ず再利用する一意キー。クーポン利用時は必須(UUID推奨)。異なる購入内容に同じキーを使わないこと
preferred_chain_idNo希望チェーン(任意。商品の対応チェーンから選ばれる)
demo_signature_versionNo0円デモのpersonal_signに対応する場合のみ指定

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / payer_address / description
      Previous value: -"支払いに使うウォレットアドレス(任意・推奨)。指定すると settle 時に支払い元と照合され、別ウォレットからの支払いは拒否される。スマートコントラクトウォレットで erc20-transfer 方式を使う場合は必須(指定が無いと accepts に erc20-transfer が提示されない)"New value: +"支払いに使うウォレットアドレス(任意・推奨)。指定すると settle 時に支払いに使うウォレットと照合され、別ウォレットからの支払いは拒否される。スマートコントラクトウォレットで erc20-transfer 方式を使う場合は必須(指定が無いと accepts に erc20-transfer が提示されない)"
  2. Changed1 schema field changed
    • addedInput schema / properties / demo_signature_version
      Added value: +{
      +  "const": "1",
      +  "description": "0円デモのpersonal_signに対応する場合のみ指定",
      +  "type": "string"
      +}
  3. Changed2 schema fields changed
    • addedInput schema / properties / coupon_code
      Added value: +{
      +  "description": "ショップから受け取ったクーポンコード(任意。NFT割引との併用不可)",
      +  "maxLength": 64,
      +  "minLength": 1,
      +  "pattern": "^[A-Za-z0-9][A-Za-z0-9_-]*$",
      +  "type": "string"
      +}
    • addedInput schema / properties / idempotency_key
      Added value: +{
      +  "description": "同じ見積もりの再試行で必ず再利用する一意キー。クーポン利用時は必須(UUID推奨)。異なる購入内容に同じキーを使わないこと",
      +  "maxLength": 64,
      +  "minLength": 16,
      +  "pattern": "^[A-Za-z0-9_-]+$",
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • addedInput schema / properties / payer_address
      Added value: +{
      +  "description": "支払いに使うウォレットアドレス(任意・推奨)。指定すると settle 時に支払い元と照合され、別ウォレットからの支払いは拒否される。スマートコントラクトウォレットで erc20-transfer 方式を使う場合は必須(指定が無いと accepts に erc20-transfer が提示されない)",
      +  "pattern": "^0x[0-9a-fA-F]{40}$",
      +  "type": "string"
      +}
  5. First observed

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources