Loading ToolBench
MCP (Model Context Protocol) adapter for django-admin-rest-api. A wire-protocol-only layer that lets agents reach the existing REST API — no new functionality, permissions, or validation.
Strong schema coverage with consistent patterns across 18 tools. All tools have descriptions (avg ~150 chars) and input schemas with type definitions and regex constraints. Naming follows verb_noun convention (admin.list, admin.create, admin.destroy). However, parameter descriptions lack actionable guidance on constraints, error recovery, and dependencies. Output schemas are undocumented, LLMs cannot predict response structure. Error handling is absent from tool definitions. No tool annotations (readOnlyHint, destructiveHint) despite clear risk stratification (READ_ONLY, WRITE, DESTRUCTIVE). Composition is sound: tools chain via app_label+model_name+pk, but no guidance on multi-step workflows.
Run one of the model's admin actions (anything registered via ModelAdmin.actions) against the given pks. The action callable is executed by django-admin-rest-api; this layer just forwards. Each action carries a `target` of either `batch` or `detail`, derived by rest-api from the action callable's signature and surfaced on the action descriptor (visible via admin.registry / admin.list / admin.retrieve): - target=`batch` (the stock Django shape): the action receives the user-narrowed queryset; pass one or more pks. - target=`detail`: the action receives a single object id; pass exactly one entry in `pks` or rest-api returns 400. The same wire endpoint serves both shapes; the dispatch happens inside rest-api. Mirrors POST /api/v1/<app_label>/<model_name>/actions/<action_name>/.
Return the create-page field descriptors for a new object: which fields are writable, their widgets, initial values, choices, and validators. Mirrors GET /api/v1/<app_label>/<model_name>/add/.
Return autocomplete suggestions for a model the consumer's ModelAdmin marks as autocomplete-enabled. Mirrors GET /api/v1/<app_label>/<model_name>/autocomplete/.
Update multiple objects at once.
Output schemas undocumented. Tool descriptions state what is returned (e.g. 'Return the JSON Schema for a model's fields') but do not specify the response structure. LLMs cannot predict field names, types, or nesting, forcing them to guess or make wasteful follow-up calls.
No tool annotations despite clear risk stratification. Tools are marked READ_ONLY, WRITE, or DESTRUCTIVE in metadata, but MCP tool definitions lack readOnlyHint, destructiveHint, or idempotentHint. Agents cannot infer safety properties from the schema alone.
Parameter descriptions lack actionable constraint guidance. E.g., 'page_size' has minItems=1 in schema but description does not state the upper bound or default. 'filters' is described as 'Filter parameters as key-value pairs' without explaining valid filter field names or operators.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2025-06-18+ | v2 |
Create a new object with the given field values.
Preview what will be deleted when deleting an object.
Delete an object by primary key.
Return the change-page field descriptors for an existing object.
Submit a form for a new or existing object.
Return the change history for an object.
List objects of a given model, with optional filtering, sorting, and pagination.
Return the admin panel data.
Return the admin's recent action log.
List all registered models in the admin site.
Retrieve a single object by primary key.
Return the JSON Schema for a model's fields.
Set the password for a user object.
Update an existing object with the given field values.
No error recovery guidance in tool descriptions. Tools do not document what errors are possible, when to retry, or what the LLM should do if a call fails. E.g., admin.create does not mention validation errors, permission denials, or how to inspect the form_spec first.
admin.action description is verbose (>400 chars) and buries the key distinction between batch and detail targets. The explanation of 'target' is clear but could be moved to a separate parameter annotation or example.