django-chainsaw-mcp

Overview Schema Source Related Servers Discussions Admin

serializer_exposure

Read-onlyIdempotent

Detect DRF serializers exposing unintended fields, such as fields = "__all__" that silently include new model columns. Audit API exposure to prevent sensitive data leaks.

Instructions

What each DRF ModelSerializer exposes, and what looks unintended.

`fields = "__all__"` is a decision made once and then re-made silently by
every migration after it. Add a token column to the model and the API starts
returning it, with no diff on the serializer for anyone to review.

Args:
    include_safe: also list serializers with an explicit, clean field list.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "serializer_exposure"
  }
}

Input Schema

Name	Required	Description	Default
`include_safe`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.3Sep 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already mark it read-only, idempotent, and non-destructive, so the bar is lower. The description adds meaningful behavioral context: it explains what counts as 'unintended' (fields='__all__' silently exposing new columns) and that include_safe broadens the listing. No contradiction with 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?

Decisively front-loaded with the purpose, then a concrete motivating example, then the single argument. Every sentence earns its place — no fluff, no adjactives, and the structure is easy to scan.

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 with an output schema, this is nearly complete: purpose, trigger scenario, and parameter semantics are all covered. The only gap is a precise statement of what the default (non-include_safe) output contains, which is left to inference.

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 description coverage is 0%, so the description must carry the meaning. The Args block clearly defines include_safe: 'also list serializers with an explicit, clean field list.' This goes beyond the bare boolean schema. It doesn't spell out the default output, though 'also' strongly implies it.

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?

States specific resource (DRF ModelSerializer exposure) and intent (surface unintended fields). Mentions DRF explicitly, distinguishing from fastapi_exposure, and the fields='__all__' scenario shows what it detects. However, it lacks an explicit action verb like 'list' or 'report', and doesn't directly name 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 Guidelines3/5

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

The example about a token column silently appearing in the API implies when this tool is valuable — reviewing serializer exposure after model changes. But it doesn't explicitly say when to use it vs alternatives like serializer_nplusone or api_contract, and gives no exclusions.

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