Skip to main content
Glama
syrian963

django-chainsaw-mcp

by syrian963

suggest_fixes

Read-onlyIdempotent

Categorize Django code analysis findings into mechanical, generated, and advisory fixes, clarifying which changes are safe to apply and which need human decision.

Instructions

Findings turned into code, grouped by how safe each one is to apply.

Three classes, and the distinction is the point:

- **mechanical**: one correct answer derivable from the code alone, such as
  datetime.now() becoming timezone.now(). No judgement in it.
- **generated**: a machine can write the artefact, a human decides whether
  it should exist. An index migration is exactly right as text and entirely
  wrong if that table is write-heavy.
- **advisory**: real code with the right names resolved, but the decision
  belongs to somebody who knows the domain. Which user owns a row is not a
  question the AST can answer.

Nothing is applied. The CLI `fix --write` applies the mechanical class only.

Args:
    tenant_root: the model that owns data, for the ownership suggestions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tenant_rootNoauth.User

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already mark the tool as read-only, idempotent, and non-destructive; the description adds 'Nothing is applied' and the important nuance that the CLI fix --write applies only the mechanical class. This clearly conveys that the tool only returns grouped suggestions and does not mutate anything itself.

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

Conciseness5/5

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

The description is longer than average but every sentence earns its place: purpose, the three safety classes with concrete examples, and the critical no-apply/CLI caveat. The structure makes the safety taxonomy immediately readable and front-loads the core purpose.

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 output schema and annotations, the description does not need to spell out the return shape. It covers purpose, safety taxonomy, non-mutation, CLI behavior, and parameter meaning; only the relationship to sibling diagnostic tools is left implicit.

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?

The schema provides only the parameter name, type, and default, while the description adds that tenant_root is 'the model that owns data' and that it exists 'for the ownership suggestions.' This compensates well for the 0% schema coverage, though the phrase 'owns data' could be more precise.

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

Purpose4/5

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

The opening 'Findings turned into code' plus the three safety classes clearly defines suggest_fixes as a code-fix suggester grouped by safety. It distinguishes itself from the diagnostic sibling tools by producing actionable code rather than analysis, but it never explicitly names any sibling tool.

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

Usage Guidelines3/5

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

The description explains what the tool does and adds a CLI caveat about how fixes are applied, but it never states when to choose this tool over the many sibling diagnostic tools. There is no explicit when-to-use or when-not-to-use guidance.

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