Loading ToolBench
MCP server for managing inventory, users, and billing in an inventory management system. Provides tools for user management, inventory item operations, and bill/invoice management.
Server has 15 tools with generally clear naming and present descriptions, but significant gaps in schema completeness, parameter documentation, and error handling. Tool names follow verb_noun convention well (fetch_, add_, update_, create_, delete_, issue_, discard_). Descriptions range from 50-300+ characters and explain what each tool does, but parameter descriptions vary in quality. Input schemas are visible for all tools, but several lack proper type constraints (enums for categorical fields like user 'type' and payment methods). Output schemas are not documented. Error handling is minimal, most tools return generic JSON errors without recovery guidance. Schema compliance is mixed: some tools have well-formed nested objects (create_draft_bill), while others use plain integer/string types without validation constraints. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in the metadata.
Adds a new inventory item to the inventory management system. Args: name: The name of the inventory item. price: The price of the inventory item. stock: The new_stock quantity of the inventory item. description: A description of the inventory item. Returns: A confirmation message or an error message in json format if the request fails.
Adds an item to the bill with the provided invoice_no. Args: invoice_no: prod_id: quantity: Returns: A confirmation message or an error message in json format if the request fails.
Adds a new user to the inventory management system. Args: username: The username of the new user. password: The password for the new user. email: The email address of the new user. phone: The phone number of the new user. address: The address of the new user. type: The type of user (e.g., Admin, Stocker, Cashier). Returns: A confirmation message or an error message in json format if the request fails.
Creates a draft bill and adds the provided products to it. Args: products: A list of products, each element of this list should be a python dictionary of the format: - prod_id: int, a unique identifier for the product (must be a positive value) - quantity: int, quantity of the product (must be a positive value and cannot be zero) Example Usage for LLM: User: "Create a bill for 2 units of product 101 and 5 units of product 102" LLM Input: { "products": [ {"prod_id": 101, "quantity": 2}, {"prod_id": 102, "quantity": 5} ] } Returns: A confirmation message or an error message in json format if the request fails.
Missing enum constraints for categorical parameters. 'type' parameter in add_user accepts 'Admin', 'Stocker', 'Cashier' but is defined as free-form string. 'pay_method' in issue_bill similarly lacks enum constraint. LLMs will hallucinate invalid values without explicit enums.
Output schemas not documented for any tool. Tool descriptions state 'Returns: A list/confirmation in json format' but do not describe what fields are in that JSON, what types they have, or what IDs are included for chaining. LLMs cannot plan downstream calls or extract data reliably.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Deletes an existing item from an unpaid/unissued bill. Args: invoice_no: Invoice Number of the bill prod_id: Id of the product (must be a positive value) Returns: A confirmation message or an error message in json format if the request fails.
Discards a draft bill (deletes an unpaid/unissued bill).
Updates the quantity of an existing unpaid/unissued bill item in the inventory management system. Args: invoice_no: Invoice Number of the bill prod_id: int, a unique identifier for the product (must be a positive value) quantity: int, quantity of the product (must be a positive value and cannot be zero) Returns: A confirmation message or an error message in json format if the request fails.
Fetches the list of all bill records from the inventory management system server in json format. Each bill record contains it invoice_no, Date, total_price and paymethod. If total_price and paymethod are NULL then that bill is not issued (Products inside the bill are not sold). Returns: A list of bill records in json format, or an error message if the request fails.
Fetches the list of all bill records from the inventory management system server in json format. Args: cashier_id: Unique id of the cashier. Returns: A list of bill records created by this cashier in json format, or an error message if the request fails.
Fetches the list of all inventory items from the inventory management system server in json format. Returns: A list of inventory items in json format, or an error message if the request fails.
Gets the list of all users from the inventory management system server in json format. There are three types of users: Admin, Stocker and Cashier. Returns: A list of users in json format, or an error message if the request fails.
Issues a draft bill i.e. The bill is finalised and considered paid. After calling this tool, the bill cannot be edited or deleted. Args: invoice_no: Invoice Number of the bill pay_method: Payment Method in uppercase letters (e.g. Cash, Card, UPI) Returns: A confirmation message or an error message in json format if the request fails.
Reads the products inside a bill with the provided invoice_no. Args: invoice_no: The Invoice No of the bill Returns: A list of products inside a bill with the provided invoice_no in a json format.
Updates an existing inventory item in the inventory management system. Args: prod_id: The ID of the inventory item to update. name: The new name of the inventory item. price: The new price of the inventory item. stock: The new new_stock quantity of the inventory item. description: The new description of the inventory item. Returns: A confirmation message or an error message in json format if the request fails.
Updates the new_stock quantity of an existing inventory item in the inventory management system. Args: prod_id: The ID of the inventory item to update. stock: The new new_stock quantity of the inventory item. Returns: A confirmation message or an error message in json format if the request fails.
Error handling returns generic JSON error objects without recovery guidance. Example: 'add_user' catches ValueError and returns {"error": "ValueError occurred: ..."}. No mention of what the LLM should do next, retry? Call a different tool? Ask the user? No error categorization (retryable vs fatal vs user-fixable).
Tool annotations missing. Tools are marked with Risk classifications in metadata (READ_ONLY, WRITE, IRREVERSIBLE, DESTRUCTIVE) but MCP tool definitions do not include readOnlyHint, destructiveHint, or idempotentHint annotations. The MCP spec allows these hints via tool annotations, they should be applied to guide LLM behavior and prevent accidental destructive calls.
Incomplete parameter descriptions. 'discard_bill' has only one parameter with a minimal description ('Invoice number of the bill to discard'). 'add_item_to_bill' parameters lack depth, 'Invoice number', 'Product ID', 'Quantity' are placeholder names without context on format, range, or constraints. Parameters under 20 chars in description violate the rubric baseline.
No pagination support. fetch_users, fetch_inventory_items, and fetch_bill_records have no limit or page parameters. If the inventory system has hundreds or thousands of items, these tools will return unbounded lists, blowing the context window. No mention of result caps in descriptions.
Missing confirmation or dry-run for irreversible operations. 'issue_bill' finalizes a bill and makes it immutable; 'discard_bill' permanently deletes a draft bill. No confirmation step, no dry-run option, no undo tool. Agents can permanently destroy billing records without review.
Parameter naming inconsistency. 'type' is vague, the description says 'e.g., Admin, Stocker, Cashier' but the parameter name alone could mean many things (user type, resource type, etc.). Similarly, 'stock' appears in multiple tools but 'new_stock' appears in the description, the actual parameter name in the code should match the docstring. Schema shows 'stock' but code variable is 'new_stock', causing confusion.