Loading ToolBench
A Django REST Framework application providing MCP (Model Context Protocol) server for restaurant order management
This Django REST Framework server exposes 6 order-management tools via STDIO. Tool names follow verb_noun convention (list_orders, create_order, etc.), which is positive. However, descriptions are minimal (10-30 chars), parameter descriptions are absent or trivial, and critical semantic information is missing. The codebase shows a Django REST API, not an MCP server implementation, there is no visible MCP protocol integration (no tool registration, no MCP SDK usage, no resources/prompts handling). Tools are inferred from Django viewset methods rather than explicitly registered with MCP schemas. Output schemas are undocumented. Error handling is not visible. No security declarations, rate limiting, or idempotency markers present. The server reads as a standard Django app retrofitted as an MCP tool listing, not a production-grade agent-ready service.
Create a new order
Delete an order
List all orders
Get recent orders within a specified number of hours
Retrieve a specific order by ID
Update an existing order
Tool descriptions are all trivial (10-30 characters). 'List all orders', 'Create a new order', etc. do not explain WHEN to use each tool, what distinguishes them from peers, or what the response structure is. Descriptions must be 50-200 chars and answer: What does it do? When should the LLM call it? What does it return?
No parameter descriptions. 'item_name' and 'status' parameters have inline types but no natural-language description explaining what value the LLM should pass. LLMs cannot infer from names alone, 'status' could mean HTTP status, order fulfillment status, or payment status.
No output schemas documented. It is unknown what fields the LLM receives when calling these tools. For example, list_orders response structure, field names, and types are invisible, the LLM cannot plan downstream calls or extract the order IDs needed by update_order or delete_order.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 29 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No visible error handling or recovery guidance. If create_order fails due to invalid status or duplicate item, the tool returns a generic HTTP error, the LLM receives no actionable error message explaining what to do next (retry, validate input, etc.).
No destructive operation safeguards. delete_order is marked DESTRUCTIVE risk but has no confirmation step, no dry-run option, and no rollback mechanism. An LLM could permanently delete all orders with a single call.
Tools are inferred from Django viewset methods, not explicitly registered with MCP. The source code shows no MCP server implementation, no SDK usage, no protocol handlers, no tool registration logic. This means tool definitions are not actually being served via MCP; they appear to be annotations in the evaluation itself.
'status' parameter uses an enum (success|failed) but the description does not explain what these values mean or when to use each. Does 'success' mean the order was already fulfilled? Does 'failed' mean it was rejected? The LLM must guess.
No security declarations. Tools lack permission scope information (read:orders, write:orders, delete:orders). No audit logging visible. No rate limits. The LLM cannot know what permissions it needs, and there is no trace of who called what tool.
No idempotency markers. If an LLM retries create_order after a timeout, it could create a duplicate order. Tool descriptions should declare idempotency (or lack thereof) so the LLM knows whether retries are safe.