Loading ToolBench
MCP server that provides tools for CRUD operations on PostgreSQL databases, including employee management, customer/product/order management in a star schema (dimensions and facts), and AWS Bedrock knowledge base integration
This server has significant definition quality gaps across multiple dimensions. Tool names are generally adequate (verb_noun format), but descriptions are inconsistent in quality and detail. Parameter schemas are present but many lack proper constraints (enums, ranges, format specs). Output structures are not documented. Most critically, the server hardcodes database credentials in plain text (DB_CONFIG), creating a critical security vulnerability that disqualifies it from production use. Error handling is minimal and provides no recovery guidance. The average tool score is pulled down by tools with incomplete parameter documentation, missing output schema documentation, and weak descriptions that don't explain WHEN to use each tool versus alternatives.
Insert a new customer into dim_customer.
Insert a new employee record into PostgreSQL.
Insert a new order into fact_orders.
Insert a new order item into fact_order_items.
Insert a new product into dim_product.
Delete an employee record by ID.
Fetch employee details from PostgreSQL by employee_id.
Critical: Database credentials hardcoded in source code (DB_CONFIG dict with username, password, RDS endpoint visible in mcpserver.py). Credentials must never appear in code; use environment variables or secure vault injection.
Error handling is minimal and provides no recovery guidance. Functions return plain strings like 'No employee found with ID 123' with no instructions on what the LLM should do next. Should include actionable guidance: 'Employee not found. Try list_employees() to see available IDs.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
List customers (default limit 20).
Fetch all employees from the employee table.
List products, optionally filtered by category.
List all stores.
Get line items for a specific order (products, qty, prices).
Get all orders for a specific customer, with totals.
Update an existing employee record (only provided fields).
Output schemas are not documented. Tools return unstructured strings (e.g., 'ID: 1, Name: John, Dept: Sales, Salary: 50000'). LLMs cannot parse these reliably or chain subsequent tool calls. Should return structured JSON with typed fields.
No pagination support on list tools (list_employees, list_customers, list_products, list_stores). These can return unbounded results. Should implement limit/offset parameters with result count and next_cursor.
Parameter descriptions lack format constraints. Example: add_customer's 'created_at' says 'ISO format' in the description but has no JSON Schema format field. Should specify: type string, format date-time. Similarly, price and salary lack min/max constraints.
Destructive operations (delete_employee) lack confirmation/dry-run pattern. Agents can irreversibly delete records without safeguards. Should implement a confirmation step or require explicit approval before execution.
Descriptions do not explain WHEN to use each tool vs. alternatives. Example: What's the difference between list_employees and get_employee_details? When should the LLM call each? Descriptions should include dependency hints.
List tools (list_employees, list_customers, list_products) accept limit parameter but no mention of default, minimum, or maximum values in descriptions. Should state: 'limit (integer, 1-100, default 20)'.
Foreign key parameters (customer_id, product_id, store_id, order_id) lack guidance on how to obtain valid IDs. Descriptions should hint: 'Get customer_id from list_customers() or add_customer().'
No logging/audit trail visible. Tool calls have no user attribution, timestamps, or audit trail. For a system managing employee and customer data, compliance requires logging who called what and when.