Loading ToolBench
A WebMCP tool set for an electronics storefront demo (Rigsmith) that enables AI agents to search products, compare builds, manage shopping carts, and interact with a custom PC builder interface.
Rigsmith WebMCP demonstrates solid tool design with complete schemas, clear descriptions, and thoughtful composition. All 20 tools have explicit input schemas with proper JSON Schema structure and type definitions. Descriptions average ~120 chars, meeting the 10 - 1024 char baseline. Tool names follow verb_noun convention (search_products, get_product, pick_part). Error handling via fail() and ok() functions with hints is present. Key strengths: parameter enums constrain input (category, sort, resolution), output budgets prevent context bloat (1.5K - 18K chars), and tools chain well (search → get_product → pick_part → get_build_report). Weaknesses: some parameter descriptions are terse (e.g., 'Product ID' for productId lacks context on format/source); no explicit idempotency or dry-run patterns for irreversible operations (submit_order); output schemas documented in code but not in tool definitions themselves.
Add a product or the current build to the cart.
Simulated FPS for a game on the current build at a chosen resolution.
Compare up to three products side-by-side: price, stock, specs, and compatibility with the current build.
Batch compatibility check: up to ten candidate products for each of nine build slots, filtered by budget and compatibility.
Performance and power metrics for the current build: FPS at three resolutions, power draw, noise estimate, and bottleneck analysis.
Snapshot of the current PC build: all nine slots with stock, price, and compatibility; totals; power draw; and any issues.
Multi-section snapshot of the current build: all slots, metrics, compatibility, and cart status. Replaces several separate calls.
submit_order lacks confirmation/dry-run pattern for irreversible operation. No explicit warning that this is destructive, and no confirmation step to prevent accidental order submission.
Parameter descriptions are often minimal (e.g., 'Product ID', 'Line item index'). Should explain format, source, and how to obtain the value (e.g., 'Product ID from search_products or get_product results').
Output schemas are documented in toolResult.ts (ok/fail functions with budgets) but not exposed in tool definitions themselves. LLMs cannot see what fields to expect from each tool's response.
No explicit error classification or recovery guidance in tool descriptions. Errors are returned via fail() but descriptions don't explain which errors are retryable vs user-fixable.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Current shopping cart: line items, quantities, prices, and totals including tax and shipping.
Available filters (facets) for a category: brands, price ranges, specs, and current selections.
Checkout form state: current values, validation errors, and the next step.
Fetch full details for a product by ID: name, brand, price, availability, specifications, compatibility facts, and a direct link.
Customer reviews and rating for a product.
Add a product to a PC build slot. Validates compatibility and stock before confirming.
Remove a line item from the cart by index.
Search the catalog by text, category, brand, price range, and availability. Optionally compare up to three distinct models from results.
Apply or clear a filter in the current category view.
Fill a checkout form field (name, email, address, etc.). Validates and reports errors.
Navigate the storefront to a product, category, or brand. The shopper sees the page change; the agent reads the result to confirm.
Submit the order. Returns a demo order ID if successful.
Change the quantity of a line item in the cart.
Tools like set_checkout_field accept arbitrary field names as strings. Should use enums or document valid field names to prevent hallucinated field names.