Django admin MCP integration - expose Django admin models to MCP clients
Django Admin MCP has 13 tools with mostly complete parameter schemas and reasonable descriptions. Naming is clear and action-oriented (find_, describe_, list_, get_, create_, update_, delete_, etc.). However, several issues limit the score: (1) Output schemas are not documented, we can see input schemas but tool responses are not formally specified, making it hard for LLMs to plan downstream calls; (2) Descriptions are present but vary in quality and length, most are brief (50-100 chars) but lack WHEN/WHY guidance and consequence clarity for write operations; (3) Error handling and recovery guidance is absent, no indication of what errors are retryable, what to do on validation failures, or how to handle cascade deletes; (4) Security considerations for destructive operations (delete, update, bulk) lack confirmation/dry-run patterns; (5) Parameter descriptions sometimes lack constraint details (e.g., 'limit' capped by MCP_MAX_LIST_LIMIT is mentioned in list description but not formally enforced or bounded). The tools are well-organized and cover a reasonable domain (Django admin CRUD + relations + history + actions + bulk ops), but production readiness is hampered by incomplete schemas and missing operational guidance.
Execute an admin action on selected model instances
List available admin actions for a Django model
Autocomplete foreign key and many-to-many field values
Perform bulk operations on multiple model instances
Create a new Django model instance with validation
Delete a Django model instance with cascade handling and audit logging
Get detailed schema and metadata for a Django model
Output schemas not documented. Tool input schemas are present but response structures are not formally specified. LLMs cannot know what fields to expect in responses (e.g., what does list() return? Is it {items: [...], total: int, next_cursor: string} or {results: [...], count: int}?). This forces LLMs to guess field names when chaining tools.
Destructive operations (delete, update, bulk) lack confirmation/dry-run patterns and do not document irreversible consequences clearly. The delete description says 'with cascade handling and audit logging' but does not explain that the operation is destructive or offer a confirmation step. Agents may accidentally delete data.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 59 | - | v1 |
Find and list exposed Django models available via MCP
Retrieve a single Django model instance by ID with related objects
Get the change history of a Django model instance from admin LogEntry
List instances of a Django model with filtering, searching, and pagination
Get related objects for a foreign key or many-to-many field
Update an existing Django model instance with validation and logging
Error handling and recovery guidance missing. No documentation of what errors are possible (e.g., validation failures, cascade delete blocked by constraints), what they mean, or how the agent should recover. Tool descriptions do not include error classification (retryable vs user-fixable vs fatal).
Parameter constraints not fully specified. 'limit' is described as 'capped by MCP_MAX_LIST_LIMIT' but the actual cap is not stated (is it 100? 1000?). 'offset' has no documented bounds. 'filters' accepts 'safe lookups only' but does not enumerate them. LLMs cannot validate inputs without explicit constraints.
Tool descriptions lack WHEN/WHY guidance. Descriptions state WHAT the tool does but not when an LLM should use it or what the expected outcome is. E.g., 'List instances of a Django model with filtering, searching, and pagination' does not explain: 'Use this to find existing records before update/delete' or 'Returns paginated results; use offset/limit for large datasets.'
Tool composition gaps. 'action' and 'bulk' overlap in responsibility (both modify multiple instances). The distinction is unclear: does 'action' run Django admin actions, and 'bulk' run custom operations? Tool descriptions do not clarify when to use each.
Security: No permission gates or scope declarations documented. Tools like delete, update, create, and action do not document what permissions are required (e.g., 'requires admin:write'). No audit trail design mentioned. Agents should not have unfettered access to destructive operations.
Parameter descriptions sometimes lack type guidance. 'filters' is described as 'Field filters with safe lookups only' but does not specify format (is it {field: value} or {field__lookup: value}?). 'ordering' is an array but does not document field name format (plain names? __reverse for descending?).
find_models has no input schema defined. The tool accepts no parameters but the schema is not formally documented (empty input vs null). Response structure is unknown (array of model names? objects with metadata?).