django-chainsaw-mcp

Overview Schema Source Related Servers Score Discussions Admin

find_unscoped_queries

Read-onlyIdempotent

Detect Django querysets that fetch tenant-scoped data without ownership filters. Identifies potential IDOR vulnerabilities by analyzing model relationships and missing scoping conditions.

Instructions

Find querysets that read tenant-scoped data without scoping the query.

This is the shape behind most IDOR reports: a view loads an object by
primary key and never checks who owns it. Generic analysers struggle
because the defect is the absence of a filter, and absence has no syntax.
The model graph makes it tractable: it knows Order reaches the tenant root
through 'customer', so it can tell that filtering on pk alone is not enough.

Candidates, not verdicts. A filter in a base class, a mixin, a custom
manager or a get_queryset() override is invisible from here.

Args:
    tenant_root: the model that owns data, e.g. "auth.User" or "shop.Customer".
    search_path: directory to scan. Defaults to the project path.
    max_depth: how many relation hops still count as owned.
    include_exempt: also scan admin, management commands and tests.

Input Schema

TableJSON Schema

Name	Required	Default
`max_depth`	No
`search_path`	No
`tenant_root`	No	auth.User
`include_exempt`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.3Sep 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds substantial behavioral nuance beyond that: it warns that results are 'Candidates, not verdicts' and explicitly lists invisible sources of filters such as base classes, mixins, custom managers, and get_queryset() overrides. This helps an agent interpret results correctly.

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, then provides essential reasoning and limitations, and closes with a compact parameter list. Every section earns its place; there is no padding or repetition of schema/annotations.

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?

Given an output schema exists, the return format does not need to be spelled out here. The description covers what the tool does, why it is valuable, what it cannot detect, and what each argument means, making it complete for correct invocation and result interpretation.

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?

Schema description coverage is 0%, yet the description compensates fully by explaining every parameter with concrete meaning: tenant_root is the owning model with examples, search_path is the scan directory with default, max_depth defines relation-hop ownership limits, and include_exempt specifies which extra code areas to scan. This is exactly the semantic enrichment an agent needs.

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 opens with a specific verb and resource: 'Find querysets that read tenant-scoped data without scoping the query.' It further distinguishes itself by explaining this is the shape behind most IDOR reports and why generic analyzers struggle, making the tool's niche clear relative to 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 context for when this tool is appropriate: hunting IDOR-style defects where a view loads an object by primary key without ownership checking. It does not explicitly name sibling tools or state when not to use it, but it gives enough situational guidance for an agent to select it.

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