Loading ToolBench
Merchant-side agentic commerce infrastructure with dual MCP faces: buyer-facing storefront and merchant-facing confirmation queue
Strong domain-specific design with clear, detailed descriptions and well-structured schemas. All 14 tools have descriptions (194 - 450 chars, well above baseline 194 avg). Parameters consistently typed and described. Mandate-chain architecture (Intent→Cart→Payment) is well-documented. Key weakness: no tool annotations (readOnlyHint/destructiveHint/idempotentHint), missing output schema documentation, and no explicit error recovery guidance in descriptions. Composition is excellent, tools chain naturally (e.g., declare_intent→create_cart→submit_payment). Security model (agentToken, merchantToken, Ed25519 signatures) is explicit but not surfaced in tool descriptions as permission requirements.
Supply the missing values and publish. The D2 overlay: send only what changed. A Variant you do not mention keeps its stored values, and nothing is ever deleted from here. The merchant supplies the missing numbers, never guesses them. Publishes the Product immediately for buyer agents.
Step 2 of buying: turn an Intent into a priced, immutable Cart mandate. One shot — there is no cart editing; to change items, just call create_cart again (earlier carts stay valid and unpaid, nothing is invalidated). Pins the current catalog prices and is signed by the merchant key, plus your custodial key (custodial Agents) — client-custody Agents sign the returned payload locally and hand that signature to submit_payment as cartSignature. Returns the cartHash to pass to submit_payment. Requires the agentToken from register_agent.
Step 1 of buying: declare WHAT you want and the most you authorize spending on it. Custodial Agents: the merchant signs the Intent mandate with your custodial key. Client-custody Agents: mint createdAt, sign the canonical payload {agentId, merchantId, want, budgetPaise, createdAt} locally, and pass createdAt + signature. Returns the intentHash — pass that to create_cart next. Requires the agentToken from register_agent. budgetPaise is integer paise: 300000 means ₹3,000.00.
One Product in full, by productId — its Variants, its holds, and the extraction record showing what the model read from the caption and how confident it was. Works for any Product of this store, whatever its status.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared. LLMs cannot distinguish read-only tools from destructive ones without explicit hints. Tools like get_product, get_order_status, list_held_products should be marked readOnly; submit_payment, confirm_product should be marked destructive.
Output schemas not documented in tool descriptions. Descriptions explain input parameters but omit what fields/structure the response contains. LLMs cannot plan downstream tool calls without knowing response structure. E.g., get_product should document it returns {variantId, price, stock}; submit_payment should document it returns {paymentLink, orderId}.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Replay one Order's whole audit chain.
Poll this until the Order is paid. Returns the current status (created, awaiting_payment, paid, cancelled, refunded) and, once paid, the merchant-signed Receipt proving your mandate chain led to exactly this charge. If the gateway declined the payment, status is 'cancelled' with a structured 'decline' explaining why. If stock ran out between verification and fulfilment, status is 'refunded' with a structured 'oversell' and a refund receipt. Requires the agentToken from register_agent.
List what this merchant currently has published for sale. Returns Variants — the sellable unit — with their variantId, price in integer paise, and stock.
The confirmation queue: every Product held in needs-confirmation because extraction could not confidently read a field from the caption. Each entry lists its holds (the fields the merchant must answer) and its Variants, whose pricePaise or stock is null exactly where the value is still unknown.
Show what is currently published and buyable. A published Product is live immediately for buyer agents.
List the latest Orders.
Register as an Agent with this merchant and declare your Cap — the maximum total you authorize spending here, in integer paise (e.g. 500000 = ₹5,000.00). Returns an agentToken; pass it on every checkout and get_order_status call. By default the merchant holds your Ed25519 keypair in custody and signs on your behalf; supply your own publicKey instead to keep the private key client-side and sign your mandates locally. Registering again creates a brand-new Agent with a fresh Cap — the Cap of an existing registration can never be changed.
Answer 'how is the shop doing' in one call: catalog and order counts, revenue in paise today and in total, low stock, sold out, and the demand that was refused.
Add a NEW Product from the merchant's own post: send the caption VERBATIM (never your description of the photo) and optionally a public photo link — the server reads it, and every call creates another Product, so never call it to correct one.
Step 3 of buying: hand the Cart to the payment gateway and get a link. Verifies the whole mandate chain (Intent → Cart → Payment) before touching the gateway. Client-custody Agents must sign the Payment payload locally and pass cartSignature. Returns a Razorpay-hosted payment link; the human approves it there, and money moves only on their approval. Idempotent: the same idempotencyKey always returns the same link, even if called again after the human paid. Requires the agentToken from register_agent.
Error recovery guidance missing. Descriptions state what tools do but not what to do if they fail. E.g., declare_intent should document 'If budget is exceeded, reduce budgetPaise and retry'; submit_payment should document 'If payment declined, check decline reason and retry with different payment method or contact merchant'.
Idempotency not explicitly declared. submit_payment accepts idempotencyKey and is idempotent, but description does not state 'Idempotent: same idempotencyKey always returns same link'. register_agent creates new Agent on each call (non-idempotent) but this is not warned. Agents need explicit idempotency hints to decide retry strategy.
Permission/scope requirements not declared in tool descriptions. Tools require agentToken or merchantToken but descriptions do not state 'Requires: agentToken with spend authorization up to Cap' or 'Requires: merchantToken with catalog edit permission'. This prevents least-privilege agent configuration and audit clarity.