Loading ToolBench
A PHP-based server providing AI-powered inventory and retail data endpoints with eWeb SOAP integration
This PHP MCP server exposes 14 inventory/AI-related tools via HTTP. Most tools have clear names following verb_noun conventions (back-in-stock, fast-movers, low-stock) and descriptions in the 30-200 character range, meeting baseline expectations. Input parameters are typed with min/max bounds where appropriate. However, output schemas are entirely undocumented, no schema definitions visible in the source code for any tool's response structure. Parameter descriptions vary in quality: some are detailed (e.g., back-in-stock's 'days' param), others are generic or missing context (e.g., chat.php has only a single 'message' param with minimal guidance on capabilities). No error handling guidance is evident. The 'chat' tool is a notable composition issue: it combines OpenAI integration, tool invocation, and response formatting into a single opaque endpoint, violating single-responsibility and making debugging difficult. Overall, the server is functional but lacks production-grade refinement in output documentation and error recovery.
Returns items that transitioned from out-of-stock (QOH <= 0) to in-stock (QOH > 0) between the latest two SUCCESS sync runs within the last N days
Returns list of brands with SKU counts and total QOH, optionally including brand names and active status if eweb_brands table exists
Returns list of categories with SKU counts and total QOH, optionally including category names, active status, and parent IDs if eweb_categories table exists
OpenAI-powered chat interface for inventory queries with tool integration to fetch sales data and return conversational responses
Returns the maximum timestamps for inventory deltas, active items updates, and daily movement aggregates to indicate data freshness
Returns top-selling SKUs (highest inferred sales by units and value) over a specified period from daily movement aggregates
Output schemas completely undocumented. No response structure definitions visible for any tool. LLMs cannot predict what fields will be returned, forcing them to call tools blindly and parse unstructured responses.
No error handling guidance. When tools fail, there is no indication of error classification (retryable vs fatal), recovery steps, or what the LLM should do next. Causes agents to get stuck or retry indefinitely.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
Returns aggregated inventory changes per SKU across sync runs in a time window, supporting multiple modes (changes, decreases, sales) and scopes (today, hours)
Returns inventory changes (deltas) for today, optionally filtered by direction (up, down, or all)
Returns inventory decreases (deltas < 0) for today; wraps inventory-changes-today with direction=down
Returns comprehensive summary statistics of inventory deltas including row-level and SKU-level aggregations for a time window
Returns net inventory changes per SKU between two dates using daily movement aggregates
Returns detailed information for a single SKU including core item data, ISDs (Item Specific Details), and images
Returns items with low stock levels (0 < QOH <= threshold)
Returns items added since a specified date, ordered by creation timestamp descending
chat tool violates single-responsibility principle. Combines OpenAI integration, multi-turn LLM invocation, inventory tool calling, and response formatting into one opaque endpoint. This makes it impossible to debug, test, or reuse components. Should split into separate tools: inventory_query_intent (parse intent), fetch_inventory_data (retrieve), and format_response (render).
Parameter descriptions lack context for LLM reasoning. For example, 'limit' params say 'Maximum number of items to return' but do not explain when to use low vs high limits or what side effects high limits cause (context window exhaustion, performance). inventory-changes 'min_abs_delta' has no guidance on what values are typical or how to choose them.
Date parameters use regex patterns (YYYY-MM-DD) but descriptions do not specify timezone handling. inventory-net-change says dates are in 'local timezone', but which timezone? Server timezone? User timezone? UTC? Ambiguity will cause date-off-by-one errors.
item tool accepts only 'sku' param but no fallback (item ID, code, or name lookup). Description does not explain what happens if SKU is invalid or how to discover valid SKUs. Agents cannot discover items without already knowing their SKU.