Skip to main content
Glama
syrian963

django-chainsaw-mcp

by syrian963

request_impact

Read-onlyIdempotent

Identify the impact of code findings by mapping them to entry points such as HTTP routes, Celery tasks, and signals, enabling prioritized fixes based on actual reachability.

Instructions

Every finding, grouped by the entry points that actually reach it.

The other checks answer "where is this defect". A few hundred correct
entries sorted by severity still does not say where to start, because risk
is severity times how often the code runs and nothing in the list says
whether a line is on the path of an endpoint served ten thousand times an
hour or of a command last run in 2023.

This runs the checks, maps each finding to the function containing it, and
walks the call graph backwards to the HTTP routes, Celery tasks, signal
receivers and management commands that reach it. Each finding carries the
path taken to it.

`unattributed` means no entry point this can see reaches the finding. It
does not mean unreachable and it does not mean safe - a plain Django
function view carries no decorator and belongs to no view class.

Args:
    search_path: directory to scan. Defaults to the configured project.
    max_depth: how many callers to walk back through.
    tenant_root: passed to the ownership check when this runs the checks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_depthNo
search_pathNo
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.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context beyond annotations: it walks the call graph backwards, explains the meaning and limitations of 'unattributed', and notes that a plain Django function view can be a false negative. No contradiction with 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 organized with a lead summary, a rationale paragraph, an algorithm explanation, an 'unattributed' clarification, and an Args section. It is somewhat long but every section earns its place by adding context needed to interpret results correctly. The main idea is front-loaded in the first line.

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 complexity of walking a call graph and the presence of an output schema, the description covers the essential semantics: what the tool produces, how entry points are found, and how to interpret 'unattributed' results. It does not mention potential performance costs or prerequisites like a configured project, but the default search_path implies that. Overall, enough for an agent to invoke and understand output correctly.

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?

Schema description coverage is 0%, so the description carries the full burden for parameters. It has a dedicated Args section explaining each parameter: search_path (directory to scan), max_depth (how many callers to walk back), and tenant_root (passed to ownership check). While max_depth is brief, all three parameters receive functional meaning beyond the raw schema.

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 clearly states the tool's specific function: 'runs the checks, maps each finding to the function containing it, and walks the call graph backwards to the HTTP routes, Celery tasks, signal receivers and management commands that reach it.' It distinguishes itself from sibling checks by explicitly contrasting with 'other checks' that answer 'where is this defect', making it easy to select among the many sibling tools.

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 description provides clear usage context by explaining that risk is 'severity times how often the code runs' and that the tool helps decide where to start fixing. It implicitly names 'other checks' as alternatives but does not list specific sibling tool names. This gives sufficient guidance for when to use this tool without leaving the agent guessing.

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