Loading ToolBench
yampi-mcp demonstrates solid tool design with consistent naming patterns (verb_noun), comprehensive parameter descriptions, and clear enum constraints. All 15 tools have descriptions (avg 156 chars) and typed schemas. However, output schemas are not explicitly documented in the source, parameter relationships lack cross-references, and error handling guidance is minimal. Tool composition is strong, tools chain well (e.g., describe_store → search_orders) and accept both IDs and natural identifiers (store aliases). Security is well-handled: credentials injected server-side via Grant props, never exposed as parameters. Pagination is properly implemented (limit, page, defaults). Main gaps: no documented return types, missing error recovery hints, and no confirmation pattern for destructive operations.
Carts that never became an order, with items and customer. The basis for recovery.
Creates a discount coupon. Reversible: it can be deactivated from the dashboard.
Registers a product with its SKUs. Reversible: it can be deactivated or deleted from the dashboard.
One customer and their orders, in a single response. Use it to check repeat purchases or handle support.
Map of the store: stores available on this credential, order statuses (with alias), categories and brands. Call this before filtering by status or category instead of guessing identifiers.
Gets one discount coupon by ID, including customer, product, category, collection, brand and payment restrictions.
Output schemas not documented. Tools return data but LLMs cannot see field structure, forcing them to infer response shape and risking downstream tool call failures.
Error handling lacks recovery guidance. No tool description explains what to do if a call fails (e.g., 'If store not found, call describe_store first'). Agents cannot self-correct.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
One full order, with items, customer, payments, address and status history.
One full product: SKUs, prices, stock, variations, images, brand and categories.
Lists, creates or updates the store's offers: cashback, order bump, upsell and freebie. Always start with `list` to see the shape of the fields before creating.
Creates a new SKU or updates price and stock of existing SKUs. Use get_product first to find the `sku_id`.
Lists discount coupons and their usage, validity and restrictions. Filter by code/text or status.
Lists customers with addresses. Route limit: 60 requests per minute.
Lists orders filtered by status, date range and free text. Already brings items, customer, transactions and status in the same call. Route limit: 120 requests per minute.
Lists catalog products with SKUs, prices and images. Route limit: 30 requests per minute — prefer filtering over paginating.
Changes fields of an existing product. Send only what changes.
Destructive operations (create_product, update_product, manage_sku, create_coupon, manage_offers with create/update) lack confirmation or dry-run pattern. Agents can accidentally modify store data without safeguards.
Parameter relationships undocumented. E.g., manage_offers requires 'type' enum to determine valid 'data' fields, but descriptions do not cross-reference this dependency. LLMs may pass invalid field combinations.
Rate limits mentioned in descriptions (search_orders: 120/min, search_products: 30/min, search_customers: 60/min) but no server-side enforcement or backoff guidance. Agents may hit limits without knowing.