Loading ToolBench
MCP server for managing orders stored in PostgreSQL with CRUD operations
Five tools with clear verb-noun naming (list_, get_, create_, update_, delete_) and complete input schemas. Descriptions are present and actionable (avg 120 chars), exceeding the 10-char minimum. All parameters have type definitions and descriptions. However, output schemas are not documented in the source, and error handling lacks recovery guidance. Tool composition is sound, each tool has one responsibility, and IDs chain correctly (list_orders returns order_id, which get_order and update_order accept). Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are present but not formally declared in the MCP schema. Missing: documented return types, pagination metadata, and error classification.
Create and persist a new order with client_id, amount, and address_delivery. Confirm the supplied data with the user before calling.
Permanently delete an order. Call only after explicit user confirmation and set confirm=true.
Retrieve one order by its UUID order_id.
List orders stored in PostgreSQL, optionally filtered by exact client_id. Use this before asking for an order when its order_id is unknown.
Modify one or more fields of an existing order. Only supplied fields are changed. Confirm the requested changes with the user before calling.
Output schemas not documented. LLMs cannot infer what fields list_orders, get_order, create_order, update_order, and delete_order return. This forces agents to guess field names and risks failed downstream tool calls.
Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are present in the tool definitions but not formally declared in the MCP schema. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) should be added to the tool registration to signal to clients which tools are safe to retry.
Error handling lacks recovery guidance. When a tool fails (e.g., order not found, invalid amount format), the response should tell the LLM what to do next (e.g., 'Order not found. Try list_orders() to find the correct order_id'). Currently, errors are likely raw database errors.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 83 | <=2025-11-25 | v2 |
list_orders accepts a limit parameter (1-100) but does not document pagination metadata in the response (e.g., total_count, next_cursor). Without this, agents cannot determine if more results exist or how to fetch them.
create_order and update_order descriptions mention 'Confirm the supplied data with the user before calling' and 'Confirm the requested changes with the user before calling', but there is no formal confirmation mechanism (e.g., dry-run, MRTR input_required). This relies on LLM behavior rather than protocol guarantees.