Skip to main content
Glama
syrian963

django-chainsaw-mcp

by syrian963

race_conditions

Read-onlyIdempotent

Detects read-modify-write races, unsafe get_or_create, and select_for_update outside transactions in Django projects. Scans code to flag concurrency issues causing lost updates.

Instructions

Read-modify-save races, and row locks taken outside any transaction.

    product = Product.objects.get(pk=pk)
    product.stock -= quantity
    product.save()

Two requests read 10, both subtract 3, both write 7; one sale is gone. A
transaction does not help, since neither sees the other's uncommitted
write. The fix is F("stock") - quantity so the database does the maths,
or select_for_update() inside atomic() to hold the row - and both of
those are silent here. Counters, balances, stock, retry counts: the
fields where off-by-one costs money.

Also: get_or_create() on a lookup no unique field, unique_together or
UniqueConstraint covers - two requests miss the get together, both
create, and the next call raises MultipleObjectsReturned. And
select_for_update() with no atomic() around it, which is not a race
but a TransactionManagementError the first time the line is reached.
Whether a transaction is open is judged with the call graph, so a caller's
atomic(), a decorator and ATOMIC_REQUESTS on a view all count.

Args:
    search_path: directory to scan. Defaults to the project root.
    include_parameters: also report mutations of an instance passed in
        as a parameter, at medium confidence (the caller may hold a lock).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
search_pathNo
include_parametersNo

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
Behavior5/5

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

Annotations already signal read-only, idempotent, and non-destructive behavior, and the description adds substantial beyond-schema context: that correct fixes are 'silent', that whether a transaction is open is judged via the call graph, and that get_or_create misuse can raise MultipleObjectsReturned. This richly discloses behavior without contradicting the annotations.

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?

Although lengthy, the description is dense and well-structured: it front-loads the core race pattern, uses a concrete code example, then systematically covers additional edge cases, and ends with parameter docs. Every sentence adds meaningful guidance; there is no filler.

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 the presence of an output schema, the description does not need to describe return values. It fully covers scan scope, parameter behavior, transaction-context inference, and the specific Django patterns reported, making it complete for an agent to decide whether and how to invoke the tool.

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 coverage is 0%, so the description carries the full burden, and it succeeds. It explains search_path's default and meaning, and it explains include_parameters' effect, including the medium-confidence reasoning about the caller possibly holding a lock.

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 description clearly identifies the tool's domain: it reports read-modify-save races, row locks outside transactions, get_or_create races, and select_for_update misuse. It distinguishes itself from the sibling list by focusing on concurrency/race patterns, though it never uses an explicit verb like 'scan' or 'find' in the opening sentence, relying instead on a noun-phrase heading.

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 explains the inputs (search_path, include_parameters) and gives practical guidance about where the tool matters ('Counters, balances, stock, retry counts: the fields where off-by-one costs money'). It does not explicitly name alternative tools or state when not to use it, so it falls short of full when/when-not guidance.

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