Loading ToolBench
Inventory management MCP server that provides stock level queries and stock transfer operations across stores
The server provides 2 tools with explicit definitions, reasonable naming, and documented parameters. Naming follows verb-noun convention (get_, transfer_). Tool descriptions exceed the 20-char minimum and reference key behaviors (CRITICAL SAFETY RULE for transfer_stock). Input schemas are visible with types and descriptions. However, there are notable gaps: output schemas are not formally documented; error handling lacks guidance for recovery paths; no parameter enums where they would help (e.g., is_online boolean filter); missing details on result structure and pagination for inventory lists. The transfer_stock tool mentions a safety rule but does not embed it as a schema constraint (e.g., confirmation mechanism via MCP patterns). Per-tool analysis shows both tools score 60 - 65 on average.
Get stock levels for a product by product ID across all stores. **USAGE:** Use this to check availability. This tool returns `store_id`s which are REQUIRED if you need to perform a `transfer_stock` operation later.
Transfer stock from one store to another. **This tool alters the database.** **CRITICAL SAFETY RULE:** Before calling this tool, you must explicitly ask the user for confirmation summarizing the transfer (e.g., "Please confirm: Transfer 10 units of 'ProSeries Hammer Drill' from Seattle to Redmond?"). Use product name, not product ID, in the confirmation message.
Output schema not formally documented. The get_stock_level_by_product_id tool returns list[dict] with inline field names (store_id, product_id, stock_level, store_name, is_online, product_name, sku) mentioned only in the docstring, not as a JSON Schema. LLMs cannot reliably extract or plan downstream operations on undocumented response structures.
transfer_stock safety rule is documented in plain text but not enforced via schema or confirmation pattern. The description states 'CRITICAL SAFETY RULE: Before calling this tool, you must explicitly ask the user for confirmation' but there is no mechanism (e.g., MCP result input_required or tool annotation) to enforce this. An LLM may skip the confirmation step.
Error handling lacks recovery guidance. The transfer_stock function returns error dicts like {"success": false, "message": "..."}. These are not categorized (retryable vs. user-fixable vs. fatal), and messages do not guide the LLM to next steps. E.g., 'Cannot transfer stock to the same store' is clear, but missing errors (source inventory not found) lack suggestions for alternatives.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
is_online parameter allows boolean | null but lacks clarity on the semantic difference. The description says 'True for online stores only, False for physical stores only, or omit for all stores', but 'omit' implies the parameter should be optional (non-required), not just null. Docstring vs. schema semantics mismatch.
No pagination or result limiting documented. get_stock_level_by_product_id returns all inventory rows without page/limit parameters or mention of result caps. A product with 500 stores would bloat the response and waste context.
Tool annotations missing. Neither tool declares readOnlyHint, destructiveHint, or idempotentHint. The transfer_stock tool is destructive (alters database) but provides no annotation. This prevents agents from reasoning about side effects or retrying safely.