Loading ToolBench
OpenBin MCP server presents a complete inventory management interface with 32 tools across locations, areas, bins, items, tags, and activity tracking. However, quality is significantly hampered by incomplete schema definitions, minimal parameter descriptions, and missing output schema documentation. While tool names follow verb_noun convention (list_*, get_*, create_*, update_*, delete_*), the implementation lacks the rigor expected of production-grade MCP servers. Many parameters have descriptions that are generic or trivial (e.g., 'The ID of the X to retrieve'), and critical input validation constraints are absent. No tools exhibit tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic categories (READ_ONLY vs WRITE vs DESTRUCTIVE). Output schemas are undocumented, making it impossible for agents to plan downstream tool chains effectively. The server includes useful composition patterns (batch operations, checkout/checkin workflows) but lacks error handling guidance and recovery paths.
Create multiple items in a batch operation
Delete multiple items in a batch operation
Update multiple items in a batch operation
Check in an item to a bin
Checkout an item from a bin
Create a new area in a location
Create a new bin
Create a new item in a bin
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic categories. Tools like delete_bin, delete_item, batch_delete_items are marked as DESTRUCTIVE in the assessment but carry no machine-readable annotations. This forces LLMs to reason about safety from description text alone and prevents protective guardrails (confirmation prompts, dry-run modes).
Batch operation tools (batch_create_items, batch_update_items, batch_delete_items) lack explicit array item schemas. The 'items' parameter has description 'Array of items to create/update' but no itemSchema specifying the structure of each array element. This prevents LLMs from knowing what fields to populate for each item.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Create a new location
Create a new tag
Delete a bin
Delete an item from a bin
Delete a tag
Export a bin's data
Export location data in various formats
Get details of a specific activity entry
Get details of a specific area
Get details of a specific bin
Get details of a specific item
Get details of a specific location
Get details of a specific scan history entry
Get details of a specific tag
List activity logs
List all areas in a location
List all bins in a location or area
List checkout history
List all items in a bin
List all locations in the OpenBin system
List scan history entries
List all tags in the system
Update bin properties
Update item properties
No error handling or recovery guidance in any tool description. For example, create_location has no description of what happens if a name is empty, duplicate, or contains invalid characters. No tool documents retryability, timeout behavior, or what to do on failure. Per pattern:recovery-guide, error responses should tell agents what to do next.
Output schemas completely undocumented. No tool documents what fields are returned, their types, or structure. Example: list_locations returns some count of location objects, but agents cannot know if the response includes location.name, location.description, location.created_at, or location.area_count. This breaks tool chaining, create_area requires location_id, but agents cannot verify that list_locations returns it.
Parameter descriptions are generic and lack constraints. Example: create_location takes 'name' with description 'Name of the location', no mention of length limits, character restrictions, uniqueness, or example format. Many numeric parameters (limit, quantity) have no min/max bounds. Per the rubric, unconstrained parameters invite invalid LLM inputs.
Export tools (export_location, export_bin) accept a 'format' parameter with description 'Export format (csv, json, zip)' but do not declare format as an enum. This leaves LLMs free to pass invalid formats. Per pattern:constrained-input, enums are mandatory for closed-set parameters.
Many optional parameters lack clear defaults or conditionals. For example, list_scan_history and list_activity accept optional location_id and limit but do not specify defaults (e.g., 'Default limit: 50' or 'If omitted, returns all locations'). Agents cannot predict behavior without defaults.
No idempotency guarantees documented. Tools like create_item could be called multiple times with the same parameters, will it create duplicates or return the existing item? This is critical for agent retry logic. Per pattern:idempotent-operation, tools must declare idempotency.
No tool composition guidance. For example, checkout_item requires item_id, but list_items returns a list of items, agents cannot know if the returned items include item_id or a different identifier. Per pattern:tool-chain, each tool's output must contain the IDs needed for downstream tools.