Loading ToolBench
Model Context Protocol server for ConsignCloud API - manage inventory, sales, and accounts
The server defines 21 tools with generally consistent naming (verb_noun pattern) and adequate descriptions. However, critical gaps exist: (1) Output schemas are completely undocumented, no tool declares what fields it returns, forcing LLMs to guess at response structures and breaking downstream tool chaining; (2) Parameter descriptions are minimal and often lack validation constraints (e.g., 'Filter by status' without enumerating valid statuses); (3) Error handling guidance is absent, no tool describes what errors might occur or how to recover; (4) Several parameters lack type constraints (e.g., status, category, account are strings but should enumerate valid values); (5) No tool documents pagination behavior or result limits explicitly in descriptions. Naming is generally strong (list_items, get_item, create_item, update_item, delete_item follow clear verb-noun convention), but parameter naming could be more specific (e.g., 'category' could be 'category_id' for clarity). The server is functional but does not meet production-grade standards for LLM-agentic integration.
Create a new vendor/consignor account
Create a new item category
Create a new inventory item
Delete (soft delete) an inventory item
Get details of a specific account
Get statistics for a specific account (balance, items, sales)
Get details of a specific inventory item by ID
Output schemas completely undocumented. No tool describes what fields it returns or the structure of responses. This breaks tool chaining: if create_item returns a response, the next tool call must know what to extract from it. LLMs will hallucinate field names or fail to pass required IDs downstream.
Filter and status parameters lack enum constraints. Tools like list_items accept 'status' (string) with no enumeration of valid values (e.g., 'active', 'sold', 'draft'). This forces LLMs to guess valid values, leading to failed calls and token waste on retries.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Get overall inventory statistics
Get details of a specific sale
Get sales trends and analytics
List vendor/consignor accounts with optional filters
List batches of items
List item categories
List inventory items with optional filters. Supports filtering by price, category, account, status, location, and more.
List store locations
List sales with optional filters
Search across accounts and items using full-text search. Returns matching entities with their full details.
Get auto-complete suggestions for a specific field (brand, color, size, tags, etc.) based on existing data.
Update an existing account
Update an existing inventory item
Void a sale
Parameter descriptions lack validation details. Descriptions like 'Filter by category ID' or 'Filter by account ID' do not explain the format, whether IDs are UUIDs, alphanumeric strings, or how to discover valid IDs. Descriptions should include format hints (e.g., 'Category ID (UUID)') and suggest lookup tools ('Call list_categories first to find valid IDs').
No error handling guidance. Tools like delete_item and void_sale (destructive operations) do not document what errors can occur (e.g., 'Item not found', 'Sale already voided') or how to recover. Error responses should tell the LLM what to do next.
Pagination behavior undocumented. Tools like list_items accept 'limit' and 'cursor' but descriptions do not clarify: What is the default limit? What is the max? Is pagination required for large result sets? Will calling without a cursor return all items (context-window explosion risk)?
Missing chaining IDs in response documentation. Tools like create_item should return the created item_id so the LLM can immediately call update_item, get_item, or add_category. Without documented response fields, the LLM cannot chain operations reliably.
Destructive tools lack confirmation or dry-run support. delete_item and void_sale can permanently modify state but offer no confirmation step. Agents can trigger unwanted deletions; a dry_run parameter or confirmation flow would prevent catastrophic mistakes.
Parameter names could be more specific. 'category', 'account', 'location' are ambiguous, they could be names or IDs. Suffix with type (category_id, account_id, location_id) or accept both and document resolution strategy (e.g., 'Pass category_id if known; otherwise, pass category_name and the tool will resolve it').
get_item_stats and get_account_stats lack descriptions of what statistics are returned. Do they return counts, sums, averages? Without output schemas, LLMs cannot extract or use the data correctly.