Skip to main content
Glama
syrian963

django-chainsaw-mcp

by syrian963

dangling_references

Read-onlyIdempotent

Find URL names and template references that will fail at runtime. Scans Django projects to catch NoReverseMatch and TemplateDoesNotExist errors before users hit them.

Instructions

URL names and template names that nothing will resolve.

    return redirect("order-detial")
    return render(request, "shop/order_detial.html", context)
    {% url 'shop:order-detial' order.pk %}

Each of these is resolved while serving a request and checked by nothing
before then. Rename a URL pattern or move a template and they keep
importing, keep passing every test that does not walk that branch, and
raise NoReverseMatch or TemplateDoesNotExist the first time a real person
opens the page - on the path nobody was watching.

Both sides use the project's own machinery: names come from every URLconf
in the project walked through each include(), so namespaces are real and a
second URLconf served by host is not mistaken for a missing one; templates
go through get_template(), so the project's loaders decide.

`by_name` groups the findings, because one missing name used in
thirty-five places is one problem.

Args:
    search_path: directory to scan. Defaults to the configured project.
    include_templates: also read `{% url %}`, `{% include %}` and
        `{% extends %}` out of the templates.
    include_tests: also scan test modules. Off by default: tests run under
        their own settings, so a name missing from these ones may be
        registered under theirs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
search_pathNo
include_testsNo
include_templatesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4.3/5.0
Behavior5/5

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

The description goes well beyond the read-only/idempotent annotations by explaining how resolution is performed: URLconfs are walked through include() with real namespace handling, templates go through get_template() with project loaders, and findings are grouped by name via by_name. This is valuable behavioral detail beyond what the annotations state.

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 purpose is front-loaded in the first sentence, and the examples and grouping rationale each add value. The description is a bit longer than strictly necessary, but its paragraph structure keeps it digestible and focused.

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

Completeness5/5

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

The description covers purpose, usage context, behavioral details, parameter semantics, and grouping behavior. With an output schema present and annotations already declaring safety properties, nothing essential is missing for an agent to select and invoke the tool 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%, but the description compensates by documenting all three parameters with meaningful details, especially search_path defaulting to the current working directory and the include_tests/include_templates toggles. The parameter descriptions are terse and somewhat predictable from their names, but they fill the schema gap.

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 phrase 'URL names and template names that nothing will resolve' states the resource and what condition the tool identifies, and the examples clarify that it finds references that will raise NoReverseMatch or TemplateDoesNotExist. It is clear but does not explicitly differentiate itself from sibling tools such as scan_templates.

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 gives a strong usage context: after renaming a URL pattern or moving a template, these references keep passing tests until a real request hits that branch. It implies when to use the tool, but it does not explicitly name alternatives or state when not to use it.

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