Loading ToolBench
A Model Context Protocol (MCP) server for Django integration with LLM assistants. Provides comprehensive project introspection, stateful code execution, and development tools including management commands, shell execution, URL routing inspection, and access to the Django packages ecosystem.
Django MCP has 13 well-defined tools with consistent naming, comprehensive descriptions, and detailed parameter documentation. Most tools follow verb-noun conventions and include rich descriptions with usage examples. However, there are gaps in output schema documentation, error handling guidance, and a few parameter description quality issues. The server demonstrates solid foundational quality but lacks the polish and completeness of production-grade tools.
Clear the Django shell session history. Use this when you want to start with a clean history for the next export, or when the history has become cluttered with exploratory code. This is similar to the old reset() but only clears the execution history, not the execution state (which is already fresh for each call).
Execute Python code in a stateless Django shell session. Django is pre-configured and ready to use with your project. You can import and use any Django models, utilities, or Python libraries as needed. Each execution uses fresh state, so code changes always take effect immediately. Useful exploration commands: - To explore available models, use `django.apps.apps.get_models()`. - For configuration details, use `django.conf.settings`. **NOTE**: that only synchronous Django ORM operations are supported - use standard methods like `.filter()` and `.get()` rather than their async counterparts (`.afilter()`, `.aget()`).
Execute a Django management command. Calls Django's call_command() to run management commands. Arguments and options are passed directly to the command. Command output (stdout/stderr) is captured and returned. Examples: - Check for issues: command="check" - Show migrations: command="showmigrations", args=["myapp"] - Migrate with options: command="migrate", options={"verbosity": 2} - Check with tag: command="check", options={"tag": "security"} Note: Management commands can modify your database and project state. Use with caution, especially commands like migrate, flush, loaddata, etc.
Export shell session history as a Python script. Returns a Python script containing all successfully executed code from the current session. Failed execution attempts are excluded. Useful for saving debugging sessions or creating reproducible scripts from interactive exploration. The exported script will deduplicate import statements at the top of the script. Execution results and output are not included in the export. If filename is provided, the script is saved to a file in the project directory. If no filename is provided, the script content is returned as a string.
Output schemas not documented for any tool. While input schemas are present and well-typed, return types are referenced by class names (e.g., ManagementCommandOutput) but their structure is not visible in code samples or documentation. LLMs cannot infer what fields to expect, breaking downstream tool chaining and forcing wasteful exploration calls.
Error handling and recovery guidance missing. Tool descriptions do not explain what errors are possible, whether they are retryable, or what the LLM should do next. For example, 'get_setting' states it 'Raises AttributeError if the setting does not exist' but provides no guidance on recovery or alternative actions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Get a specific comparison grid with all its packages. Returns detailed information about a grid including all packages that belong to it, allowing for easy comparison of similar tools.
Get detailed information about a specific Django package. Provides comprehensive package metadata including repository stats, PyPI information, documentation links, and grid memberships.
Get comprehensive project information including Python environment and Django configuration. Use this to understand the project's runtime environment, installed apps, and database configuration.
Get a Django setting by key. Returns the setting value along with type information. Raises AttributeError if the setting does not exist.
Get a list of all installed Django applications with their models. Use this to explore the project structure and available models without executing code.
List all available Django management commands. Returns a list of all management commands available in the current Django project, including built-in Django commands and custom commands from installed apps. Each command includes its name and the app that provides it. Useful for discovering what commands are available before executing them with the execute_command tool.
Get detailed information about Django models with optional filtering. By default returns only models from your project directory. Use include for specific apps or scope='all' for everything including Django and third-party packages. When include is provided, it overrides the scope parameter. Use this for quick model introspection without shell access.
List all Django URL routes with optional filtering. Returns comprehensive route information including URL patterns, view details, HTTP methods, namespaces, and URL parameters. All filters use contains matching and are AND'd together.
Search djangopackages.org for third-party packages. Use this when you need packages for common Django tasks like authentication, admin interfaces, REST APIs, forms, caching, testing, deployment, etc.
No pagination support documented or implemented. Tools returning lists (list_commands, list_apps, list_models, list_routes, search) lack limit, offset/page, and cursor parameters. Large result sets risk context window exhaustion. Descriptions do not mention result limits or pagination availability.
Destructive operations lack confirmation or dry-run safeguards. 'execute_command' and 'execute' can modify database state (migrate, flush, loaddata) and execute arbitrary code. Descriptions warn of risks but provide no mechanism for confirmation, dry-run, or reversibility. An LLM could accidentally issue 'migrate --fake' or 'DROP TABLE' via execute().
get_setting parameter lacks format constraint. Description mentions examples (DEBUG, DATABASES, INSTALLED_APPS) as enum-like, but parameter is unconstrained string. LLMs can pass typos or invalid keys, triggering AttributeError. Should document allowed keys or provide a 'list_settings' discovery tool.
execute_command options parameter accepts dict[str, str | int | bool] but lacks documentation on underscore-to-dash conversion or which commands accept which options. Description mentions converting 'run_syncdb' to '--run-syncdb' but doesn't specify if all options follow this or if validation occurs.
list_models scope parameter has enum [project, all] but description is inconsistent. Mentions 'only models from your project directory' (implies scope=project) but then says 'include overrides scope'. Relationship between include and scope could confuse LLMs about which takes precedence.