Skip to main content
Glama
syrian963

django-chainsaw-mcp

by syrian963

queries_in_loops

Read-onlyIdempotent

Detect database queries executed inside loops in Django code, identifying N+1 patterns and suggesting fixes like prefetching or moving constants.

Instructions

Database work written inside a loop, split by what the fix is.

The template and serializer checks here find the N+1 a framework causes.
This finds the one somebody wrote by hand, which is where it lives in a
codebase whose views build their responses themselves.

Three shapes share one appearance and need three different fixes:

    Customer.objects.get(pk=order.customer_id)   uses the loop variable:
                                                 once per row, needs a bulk
                                                 fetch or a prefetch
    Config.objects.get(key="vat")                does not: the same
                                                 question N times for the
                                                 same answer, move it above
                                                 the loop
    order.save()                                 N round trips; bulk_update
                                                 fixes it and skips signals

django-check does static N+1 for relation access in a loop and is the
closest existing tool; nplusone and the debug toolbar find it at runtime.
The separation is what is added here.

Args:
    search_path: directory to scan. Defaults to the configured project.
    include_writes: also report save()/delete() inside a loop.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
search_pathNo
include_writesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already indicate a read-only, idempotent, non-destructive operation, so the description doesn't need to restate safety. It adds useful behavioral detail about the three code shapes it detects, the three different fixes, and how include_writes extends reporting to save()/delete() calls.

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 front-loaded with the core purpose and then expands with concrete code examples and routing guidance. The three-shape example block earns its place by clarifying what counts as a loop query, and the Args section is clean and minimal.

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 exists and annotations cover safety, the description is largely complete: it explains the pattern detected, the categories of fixes, the alternative tools, and the parameters. A small gap is that it never maps the mentioned template/serializer checks to specific sibling names, though the context makes this recoverable.

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 coverage is 0%, so the parameter descriptions in the Args section carry the weight. They explain search_path as a directory with a default of the configured project and describe include_writes' effect on reporting writes in loops. This is enough for an agent to understand both parameters, though it remains brief.

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 the tool finds hand-written database work inside loops and splits it by the fix required, which is a specific behavior rather than a restatement of the name. It also distinguishes this tool from framework-caused N+1 checks in templates and serializers, helping differentiate it from nearby siblings.

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

Usage Guidelines5/5

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

The description explicitly says this tool is for hand-written loop queries, while template/serializer checks cover framework-caused N+1, django-check covers static relation access, and nplusone/debug toolbar target runtime detection. This gives clear when-to-use and when-not-to-use guidance with named alternatives.

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