Skip to main content
Glama

webaz_quote_order

Read-only

Server-authoritative buyer QUOTE (safe scope price_quote; OAuth grant). Integer line items + a single-use time-limited quote_token bound to your account. QUOTE ONLY: no order, no payment, no funds locked, no stock reserved (availability re-checked at real order creation). Uses your SAVED default address server-side (never returned); no default → DEFAULT_ADDRESS_REQUIRED (never paste an address into chat). Amounts are INTEGER base-units (exp 6) — never sum lines yourself. payment_rail: direct_p2p (live; you pay the seller directly, WebAZ holds no funds) | usdc_escrow (on-chain escrow, channel-gated). The compatibility-only escrow input is rejected. Ineligible rails FAIL — never auto-switched. payment_options = price per method; pick lowest payable_units: direct_p2p → account_id as direct_receive_account_id; usdc_escrow → payment_rail. Variants: if the product has variants and the user has not chosen one, show the options with prices and ask first; never pick one yourself. quote_token: 10-min single-use, bound to you+product+quantity+address+rail+amounts. Next: webaz_order_draft → webaz_submit_order_request → the human approves on webaz.xyz.

Input Schema

NameRequiredDescriptionDefault
optionsNoInstead of variant_id: {dimension: value} per variant_dimensions
offer_idNoRFC-032 negotiated offer (off_…) for your human: prices the quote at min(offer, listing), answers price_basis:"offer" + list_price_units_at_offer + offer_expires_at, expires no later than the offer, and carries it through draft → approval → order. Consumes nothing. See place_order's offer_id for the full rule.
quantityNoPositive safe integer (default 1). Strings/decimals rejected — no implicit conversion.
product_idYesActive listing id (server re-reads product + seller state)
variant_idNoRequired when the product has variants
donation_bpsNoInteger basis points (0/0.5%/1%/2%/5%), charged IN ADDITION to total. Never auto-set.
payment_railNodirect_p2p (live) | usdc_escrow (on-chain, channel-gated). The compatibility-only escrow input is rejected. Ineligible rails fail — never auto-switched.
address_sourceNoOnly 'default' in v1 — your saved default address, resolved server-side, never shown.
idempotency_keyNoOptional client key: same subject+key+payload within TTL returns the SAME quote; same key with a different payload → IDEMPOTENCY_CONFLICT.
anonymous_recipientNoEscrow only (direct_p2p v1 rejects it).
direct_receive_account_idNodirect_p2p only: a known ACTIVE receiving account of this seller (no free-text payment instructions).

Output Schema

NameRequiredDescriptionDefault
typeNo
errorNopresent ONLY on failure (with error_code + structured recovery fields)
priceNoproduct price: amount_minor / currency USDC / display (display line only; fx table gives display-only local conversions)
statusNov2 status {code,label,label_en}; code canonical (never from label)
amountsNominor breakdown {item,shipping,other,payment_discount?}
optionsNoVARIANT_REQUIRED only: bounded active in-stock SKU choices {variant_id,sku?,options,price,stock_status}; choose explicitly, never guess
productNo{id, title}
quantityNopositive integer, or null when invalid (see quantity_valid); display-only (amount=price.amount_minor)
quote_idNo
shippingNo
rail_noteNoper-rail honesty note: escrow(WAZ)=simulated; usdc_escrow=real USDC in the Base contract; direct_p2p=no principal held
error_codeNo
expires_atNo
destinationNoregion tag + masked summary only
disclosuresNo
quote_tokenNosingle-use, 10-min TTL — pass to webaz_order_draft
return_daysNo
payment_railNo
fiat_estimateNodisplay-only ≈local-fiat {currency,display,rate,as_of,stale}; never a settlement amount; omitted when unavailable
warranty_daysNo
quantity_errorNoinvalid-quantity code: missing|empty|zero|negative|not_integer|overflow|non_numeric
quantity_validNofalse only when quantity is invalid data (card shows 数量数据异常, buttons disabled)
schema_versionNo
stock_reservedNo
payment_optionsNo[{rail,account_id?,method_label,payable_units,discount_units,protection}]; usdc_escrow last
available_actionsNo
selection_requiredNoVARIANT_REQUIRED only: the buyer must choose a variant before retrying
variant_options_totalNoVARIANT_REQUIRED only: total active in-stock SKU choices
economic_action_executedNo
variant_options_truncatedNoVARIANT_REQUIRED only: true when the bounded options array omits additional choices

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Despite annotations already marking it read-only and non-destructive, the description adds critical behavioral context: the quote token is '10-min single-use, bound to you+product+quantity+address+rail+amounts,' no funds are locked, no stock is reserved, and ineligible rails 'FAIL — never auto-switched.' It also discloses the server-side default address behavior and the DEFAULT_ADDRESS_REQUIRED failure mode.

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?

The description is dense but front-loads the quote-only scope and the next-tool path, and nearly every sentence carries operational value. There is some duplication with the schema, especially around payment_rail eligibility and the rejected 'escrow' input, but it remains well organized.

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?

Given 11 parameters, an output schema, and complex payment-rail behavior, the description is complete: it covers error cases like DEFAULT_ADDRESS_REQUIRED, token lifetime and binding, lifecycle handoff to draft and submit, and user-approval requirements. No critical agent decision is left ambiguous.

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%, so the baseline is 3, but the description adds meaningful cross-parameter semantics: payment_options give price per method, the agent should pick the lowest payable_units, direct_p2p maps to account_id as direct_receive_account_id, and variant options should be surfaced to the user rather than chosen automatically.

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 opens with a specific verb and resource: 'Server-authoritative buyer QUOTE' and explicitly scopes it as 'QUOTE ONLY: no order, no payment, no funds locked, no stock reserved.' This clearly distinguishes it from siblings like webaz_order_draft, webaz_place_order, webaz_buy, and webaz_pay_order.

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?

It gives explicit routing: 'Next: webaz_order_draft → webaz_submit_order_request → the human approves on webaz.xyz.' It also provides decision rules for variants ('show the options with prices and ask first; never pick one yourself') and payment options ('pick lowest payable_units').

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