Loading ToolBench
WooCommerce MCP server for retrieving orders and order information from WooCommerce stores
This WooCommerce MCP server has clear tool naming (verb_noun pattern) and basic input schemas using Zod, but falls short on several critical fronts: parameter descriptions are present but generic, output schemas are not formally documented, error handling is minimal without recovery guidance, and there is no result pagination despite potentially unbounded result sets. The server registers 2 read-only tools with reasonable structure but lacks the polish and safety guardrails expected of production code. Average per-tool score is 54, reflecting fair but incomplete definitions.
Retrieve a specific order from WooCommerce by its ID
Retrieve recent orders from WooCommerce with optional filtering by status, date range, and limit
No output schema documentation for either tool. LLMs cannot determine what fields the returned order object contains, which breaks downstream tool composition and forces agents to guess field names.
getRecentOrders accepts 'limit' parameter but does not enforce pagination or document result count limits. Unbounded result sets can exhaust context windows. No 'total_count' or 'next_cursor' returned.
Parameter 'status' in getRecentOrders lacks enum constraint. Description mentions examples ('processing, completed, on-hold') in natural language, but LLMs frequently hallucinate status values not in the API. Should be enum: ['processing', 'completed', 'on-hold', 'pending', 'cancelled', ...].
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Error handling in both tools is weak. On failure, errors are returned as plain text strings in the response content. No recovery guidance provided, LLMs cannot determine if an error is retryable, user-fixable, or fatal. For example, 'Error fetching order #123: 404 Not Found' does not tell the LLM what to do next.
Date format parameter descriptions lack precision. 'after' and 'before' parameters state format 'YYYY-MM-DD' but code converts to ISO 8601 datetime. Description should clarify: 'ISO 8601 date string (YYYY-MM-DD). Times at 00:00:00 UTC.' And add validation to reject invalid formats with actionable error message.
getOrderById lacks input validation constraints. No min/max on 'id' parameter. What if LLM passes id=0 or id=999999999? Code will attempt API call and return cryptic error. Should validate: 'id must be a positive integer' in both description and code.