Loading ToolBench
ReplenishRadar MCP server - connects Claude Desktop and other MCP clients to the ReplenishRadar REST API
ReplenishRadar MCP server has 12 well-named, read-only tools with consistent verb_noun naming (rr_get_*, rr_list_*). All tools have descriptions (avg ~120 chars) and input schemas with typed properties. However, critical gaps reduce quality: (1) Most parameters lack descriptions, only ~40% of parameters have non-empty descriptions; (2) No enum constraints on filter parameters (risk_level, status, alert_type, severity, kind) that accept known values; (3) No documented output schemas, LLMs cannot predict response structure; (4) Missing required field declarations in most schemas; (5) No error handling guidance or recovery patterns; (6) Descriptions lack WHEN-to-use context and dependency hints. Tool names are clear and action-oriented, but parameter documentation is sparse, forcing LLMs to guess intent.
Get inventory alerts (stockout warnings, sync failures, reorder points). Supports filtering by type, severity, status, and SKU.
Get demand forecast statistics (mu/sigma) for a SKU or item. Returns active forecast windows.
Get stock-by-location breakdown for a single item. Returns on-hand quantities across all warehouses and stores.
Get a single purchase order with full details including line items and vendor info.
Get one replenishment action with child item provenance, immutable snapshots, linked execution records, and event history.
List canonical buyer work across supplier PO, transfer, combined, and no-action replenishment outcomes. Prefer this over suggested purchase orders or alerts for deciding what action to take next.
Missing parameter descriptions on ~60% of parameters. Parameters like 'risk_level', 'status', 'kind', 'severity', 'alert_type' lack descriptions explaining valid values or constraints. LLMs cannot infer meaning from names alone.
No enum constraints on filter parameters. 'risk_level' accepts 'critical|high|medium|low', 'status' accepts multiple values, 'kind' accepts 'supplier_po|transfer|combined|no_action', all should be declared as enums in inputSchema, not just in descriptions.
No documented output schemas. Tool descriptions do not specify what fields are returned, their types, or structure. LLMs cannot plan downstream tool calls or extract required IDs (e.g., action_id, po_id) without seeing response examples.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Get items at risk of stocking out, sorted by days to stockout. Filter by risk level, SKU, or store.
Get system-generated purchase order suggestions based on demand forecasts and stockout risk.
Get recent data sync runs and optionally monitor one durable manual-sync receipt, including its retry attempts.
List catalog items with optional search, vendor filtering, pagination, and opt-in exact listing identity. Returns SKU, display name, lead time, supplier info, and optional Amazon ASIN/FNSKU evidence.
List purchase orders with filtering by status, vendor, and search. Supports pagination.
List all suppliers/vendors for the organization. Optionally include vendor SKU mappings.
Missing required field declarations. Most schemas lack 'required' arrays. E.g., rr_get_inventory_position accepts 'item_id' OR 'sku' but neither is marked required, unclear to LLM which is mandatory.
No error handling or recovery guidance. Tool descriptions do not explain what errors can occur, how to interpret them, or what to do next. E.g., if rr_get_inventory_position fails with 'item not found', should the LLM retry with rr_list_items?