django-chainsaw-mcp

Overview Schema Source Related Servers Discussions Admin

deploy_safety

Read-onlyIdempotent

Scan source code for references to fields, models, indexes, or constraints that pending destructive migrations remove or rename, and determine if each reference blocks deployment.

Instructions

Is a pending destructive migration safe to deploy yet?

A migration linter says RemoveField is backward incompatible, always. This
answers the question that actually decides the deploy: has the code caught
up? For every unapplied migration that removes or renames a field, model,
index or constraint, the source tree is searched for code that still refers
to it, and each one comes back either "blocking" with file and line numbers,
or "clear".

Args:
    search_path: directory to scan. Defaults to the configured project path.
    max_hits_per_symbol: stop after this many references per symbol.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "deploy_safety"
  }
}

Input Schema

Name	Required	Description	Default
`search_path`	No
`max_hits_per_symbol`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.3Sep 9, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already mark the tool as read-only and idempotent, and the description adds what actually happens: for every unapplied destructive migration, the source tree is searched and each reference is reported as 'blocking' with file/line details or 'clear'. It also clarifies that a null search_path effectively defaults to the configured project path. No contradiction exists between description and annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately sized and front-loaded with the core question, then the value proposition, then parameter docs. The prose about the migration linter adds context and earns its place, but it could be tightened without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple two-optional-parameter schema, the annotations, and the existing output schema, the description covers the decision context, scan scope, and result categories. It does not discuss edge cases like no pending migrations or performance implications, but these are not essential for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description fully compensates by explaining both parameters: search_path is the directory to scan with a project-path default, and max_hits_per_symbol bounds how many references are checked per symbol. This gives meaning to otherwise bare schema properties, though 'symbol' could be more explicitly defined.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific decision question and mechanism: it checks whether pending destructive migrations are safe by scanning the source tree for code references to removed/renamed fields, models, indexes, or constraints. This clearly distinguishes it from a generic migration linter by focusing on code readiness. The verb ('search'), resource ('source tree'), and outcome ('blocking'/'clear') are concrete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening question 'Is a pending destructive migration safe to deploy yet?' plus the contrast with a migration linter that always flags RemoveField tells the user when this tool is the right choice. It does not explicitly name sibling alternatives like migration_risk or list exclusion conditions, but the intended context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.