Skip to main content
Glama
syrian963

django-chainsaw-mcp

by syrian963

unused_eager_loading

Read-onlyIdempotent

Detect unused select_related and prefetch_related calls in Django serializers to eliminate unnecessary database queries and optimize performance.

Instructions

select_related and prefetch_related the serializer never reads.

Every tool in this space looks the other way: a relation the serializer
touches that the queryset did not prefetch, which is the N+1. This is the
opposite, and it costs on every request. An unused select_related is a
JOIN on every row; an unused prefetch_related is a whole extra query plus
the objects it returns.

It is invisible because it looks like an optimisation, and it usually was
one - the field it was added for was removed and nobody takes the line out,
because removing one feels riskier than leaving it in.

nplusone finds this at runtime by watching which loaded objects go
untouched, so it covers the paths the tests exercise. Both halves are in
the source: the queryset says what it loads, the serializer what it reads.

Args:
    include_low_confidence: also report views whose serializer has a
        SerializerMethodField or which override list/retrieve/
        to_representation, where the relation may be read out of sight.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
include_low_confidenceNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description does not contradict them. It adds useful behavioral context: it reports views, optionally includes low-confidence cases, and infers from source that 'the queryset says what it loads, the serializer what it reads.' The mention of nplusone runtime detection introduces slight ambiguity, but the overall behavior is transparent.

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 front-loaded with the core purpose and then builds context efficiently. It is longer than strictly necessary, but the background about cost, invisibility, and the contrast with N+1 tools earns its place. The Args section is clearly separated and readable.

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?

For a one-parameter, read-only analysis tool, the description covers what it detects, why it matters, how it relates to siblings, and the meaning of the only parameter. An output schema exists, so return details need not be described. The only minor gap is that the runtime versus source-based approach could be stated more directly.

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

Parameters5/5

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

The schema provides only a boolean with a default, but the description explains exactly what include_low_confidence means: report views with SerializerMethodField or overridden list/retrieve/to_representation where the relation may be read indirectly. This goes well beyond the schema and is essential for correct invocation.

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 opening line, 'select_related and prefetch_related the serializer never reads,' identifies the exact resource and issue with a specific verb implied by the tool's name and the surrounding explanation. It also explicitly distinguishes itself from the common N+1 family: 'This is the opposite,' so an agent cannot confuse it with sqlalchemy_nplusone or serializer_nplusone.

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 clear context for when the tool is relevant: unused eager loading costs on every request and looks like an optimization. It contrasts this with N+1 tools, implying use this when the queryset over-loads relations the serializer never reads, though it never explicitly names an alternative tool or states a direct 'use this instead of X' rule.

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