django-chainsaw-mcp

Overview Schema Source Related Servers Score Discussions Admin

datetime_audit

Read-onlyIdempotent

Scans Django projects for naive datetime creation and model fields with unsafe defaults, revealing timezone issues that appear during DST transitions.

Instructions

Naive datetimes in code, and ambiguous defaults on model fields.

With USE_TZ on, code that builds its own datetimes with datetime.now() or
from parts produces naive values, and mixing them with the aware ones the
ORM returns either raises or compares against the wrong instant. It is
invisible for ten months and shows up on the two nights the clock moves.

Also reports model fields whose default is naive, whose default was
evaluated once at import time, or that set auto_now and auto_now_add
together.

Args:
    search_path: directory to scan. Defaults to the project path.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`search_path`	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.5/5.0

Behavior4/5

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

Beyond the readOnly/idempotent annotations, the description discloses the exact categories of issues checked (naive datetimes, naive defaults, import-time defaults, auto_now/auto_now_add together). It explains the subtle behavior of the bug (invisible for ten months, surfacing during DST transitions), adding judgment context without contradicting any annotation.

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 organized into topic, why-it-matters, and an explicit Args section. Each sentence either defines scope or provides a decision-relevant detail; the length is justified, though the DST narrative is slightly more expansive than strictly necessary.

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?

For a single optional parameter and an output schema that likely describes results, the description covers the resource, the trigger conditions, the precise checks, and the parameter semantics. Nothing an agent needs to correctly select and call this tool is missing.

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?

With 0% schema description coverage, the description fully compensates: it names the search_path parameter, says it's a directory to scan, and gives its default ('the project path') – more specific than the schema's 'default: null'.

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 clear noun-phrase summary of the exact problem domain – naive datetimes in code and ambiguous model field defaults – and then elaborates with specifics: builds its own datetimes from datetime.now()/parts, naive defaults, import-time defaults, and auto_now with auto_now_add. This provides a specific verb ('reports') and resource scope that distinctively separates it from the many sibling audit 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?

It gives concrete context: 'With USE_TZ on' and the long-term invisibility of the bug, making clear when this audit is relevant. It does not name alternatives or exclusions, but the specificity of datetime/model field issues and the sibling list establish when to choose it.

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