Loading ToolBench
Agent-first storage for physical inventories. A memory for the things around you.
Quilombo demonstrates solid definition quality with consistent naming conventions, comprehensive parameter descriptions, and structured schemas. All 16 tools follow verb_noun patterns (search_, get_, list_, create_, move_, bulk_, update_, delete_, audit_). Every tool has a meaningful description (34-242 chars, well within 10-1024 baseline). All parameters include type definitions and descriptions. However, output schemas are not explicitly documented in the provided source, limiting confidence in downstream chaining support. Error handling descriptions are present but lack actionable recovery guidance (e.g., no suggestions for alternative lookups). Tool compositions are well-designed with clear single responsibilities and good parameter naming (holding_id, item_id, location_id, etc. are consistent). Risk annotations (READ_ONLY, WRITE, REVERSIBLE, DESTRUCTIVE) are present, supporting error classification. The schema baseline (avg 4 params/tool) is met. No secrets in parameters detected. Idempotency keys present on write operations align with pattern:idempotent-operation.
Record an audit observation of inventory holdings at a location
Bulk create or update multiple inventory holdings in a single atomic operation
Create a new item in the inventory
Create a new location in the inventory
Delete an item and all its associated holdings from the inventory
Get detailed information about a book item, including Open Library metadata if available
Get detailed information about a specific holding including location, quantity, and verification status
Output schemas not explicitly documented in source code. Tool descriptions state what is returned (e.g., 'Get detailed information'), but structured response field definitions are missing. This prevents verification of downstream chaining support and forces LLMs to infer response structure.
Error handling descriptions lack actionable recovery guidance. Risk classifications (READ_ONLY, WRITE, REVERSIBLE, DESTRUCTIVE) are present, but tool descriptions do not explain what to do when operations fail (e.g., 'If search returns empty, try broadening the query'). This violates pattern:recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | 2025-06-18+ | v2 |
Get detailed information about an item including name, category, tracking mode, and all holdings
Get detailed information about a location including its parent, children, and all holdings stored there
Get a snapshot of stock status for items, showing quantities at locations and verification freshness
List all items in the current workspace with optional filtering by category or tracking mode
List all locations in the current workspace with optional filtering and hierarchical display
Look up multiple books by ISBN from Open Library catalog
Record the movement of inventory from one location to another
Search inventory holdings by item name, location, or category
Update an item's metadata including name, category, and attributes
Pagination support exists (limit parameters on list_* and search_* tools) but no documentation of page offsets, cursors, or total counts. Tools like list_locations and list_items accept 'limit' but descriptions do not specify how to retrieve next batch or total result count. This risks context window exhaustion on large datasets.
Parameter constraints not fully expressed in descriptions. Example: 'limit' parameters lack min/max bounds (e.g., 1-100). 'kind' and 'tracking_mode' parameters accept enums but enums are not documented in parameter descriptions, only mentioned casually ('e.g., room, container'). This invites LLMs to hallucinate invalid values.
create_location and create_item accept a 'key' parameter (unique identifier) but descriptions do not specify format constraints (e.g., allowed characters, length limits, case sensitivity). This is error-prone for LLMs attempting to construct unique keys.