Loading ToolBench

Reading the current corpus…

django-rest-mcp MCP server · F · ToolBench

← Browse

django-rest-mcp

github.com/pescheckit/django-rest-mcp

MCP server for Django REST Framework — auto-discovers DRF views and exposes them as MCP tools

<=2025-11-25STREAMABLE_HTTP6 tools

48/100

Definition Quality40

Protocol Readiness69

SupportabilityNot measured-

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Dynamic Client Registration

Deprecated protocol patterns detected

Summary

django-rest-mcp exposes DRF ViewSets as MCP tools via auto-discovery. Tool names follow verb_noun convention (list_, retrieve_, create_, update_, partial_update_, destroy_) and are clear. However, descriptions are minimal (e.g., 'list via CheckViewSet'), parameter descriptions are sparse or missing, and input schemas are inferred from serializers rather than explicitly visible in the code. The server lacks error handling guidance, output schema documentation, and security annotations. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite clear risk levels (READ_ONLY, WRITE, DESTRUCTIVE). Parameter validation and LLM-friendly error messages are not evident.

Tools (6)

create_<basename>writeauth50/100

create via <ViewSetClass>

destroy_<basename>destructiveauth48/100

destroy via <ViewSetClass>

list_<basename>read onlyauth48/100

list via <ViewSetClass>

partial_update_<basename>writeauth50/100

partial_update via <ViewSetClass>

retrieve_<basename>read onlyauth50/100

retrieve via <ViewSetClass>

update_<basename>writeauth50/100

update via <ViewSetClass>

Issues (5)

CRITICALtool-description ↗

Tool descriptions are generic placeholders (e.g., 'list via CheckViewSet'). They do not explain WHAT the tool does, WHEN to use it, or what it returns. LLMs cannot determine tool selection intent from these descriptions.

list_<basename>retrieve_<basename>create_<basename>update_<basename>partial_update_<basename>destroy_<basename>

HIGHconstrained-input ↗

Input schemas are derived from DRF serializers at runtime but not explicitly visible in source code. For create/update/partial_update, the 'data' parameter is documented as 'object|pydantic_model' with no field-level schema details. LLMs cannot infer which fields are required, optional, or constrained.

create_<basename>update_<basename>partial_update_<basename>

HIGHtool-annotations ↗

No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. destroy_<basename> is marked DESTRUCTIVE but the tool definition lacks a destructiveHint annotation. LLMs cannot reason about side effects or retry safety.

Recommendations

Enhance tool descriptions to 50 - 200 characters, following the pattern: 'ACTION WHAT on RESOURCE. Returns RESULT. Use when USER_INTENT.' Example: 'List all checks. Returns paginated check objects with id, name, status. Use to discover available checks before retrieving details.'
Add field-level schema documentation for create/update/partial_update. Generate a JSON Schema snippet in the tool description or docstring showing required fields, types, and constraints. Example: '{"name": "string (required, 1-100 chars)", "status": "enum: active|inactive", "priority": "integer (1-5, optional)}'.
Implement tool annotations: mark list_ and retrieve_ with readOnlyHint=true; mark create_, update_, partial_update_ with idempotentHint=false (or true if DRF serializers are idempotent); mark destroy_ with destructiveHint=true.
Document output schemas in tool descriptions or via a separate schema registry. Example: 'Returns: {id: string, name: string, created_at: ISO8601, status: enum}'. Include pagination info (total_count, next_cursor) for list_ tools.
Wrap DRF error responses with actionable guidance. Catch validation errors and return: 'Invalid input: field "name" is required (string, 1-100 chars). Received: <value>.' Catch 404 and return: 'Check not found. Available checks: [list]. Try search_checks() first.'

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Dynamic Client Registration (deprecated) - use Client ID Metadata Documents (CIMD)

Score history

Overall score trend

First recorded score · v2 rubric

48/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	48	<=2025-11-25	v2