Skip to main content
Glama
syrian963

django-chainsaw-mcp

by syrian963

endpoint_cost

Read-onlyIdempotent

Estimate the number of database queries each endpoint request costs, using page size and nested-fan-out assumptions, to spot N+1 query risks before running tests.

Instructions

How many queries one request to each endpoint will cost.

Every tool that answers this runs the application and tells you afterwards:
the debug toolbar, silk, assertNumQueries. The number is derivable before
anything runs. One query for the page, plus one per object for every
serializer field crossing a relation the view did not prefetch, plus that
again per level of nesting.

On the demo project the same serializer measured 2852 queries behind an
unoptimised queryset and 2 behind an optimised one. The ratio is the
reliable part; the absolute number is only as good as nested_fan_out.

Args:
    page_size: objects a list response returns.
    nested_fan_out: assumed children per parent one level down. A property
        of your data that reading the code cannot reveal.
    list_only: skip views that only ever return a single object.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
list_onlyNo
page_sizeNo
nested_fan_outNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark it read-only and idempotent, and the description adds substantial behavioral context: the estimation formula, dependency on nested_fan_out, and the caveat that the ratio is reliable while absolute numbers are only as good as the assumption. This gives the agent a clear picture of accuracy and limitations.

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 purpose is front-loaded, and every paragraph earns its place: alternative tools, static derivability, the estimation model, a compact calibration example, and parameter docs. The example is illustrative rather than padding.

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 3-parameter estimation tool with an output schema, the description covers what it computes, how it computes it, parameter meanings, and limitations. The output schema handles return-value details, so no critical gap remains.

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%, but the Args section fully documents all three parameters with meaningful semantics: page_size as list response size, nested_fan_out as an external data property, and list_only as a filter for single-object views. This fully compensates for the bare schema.

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 states a precise metric (query count per request) and resource (each endpoint), and makes clear this is a static, pre-execution estimate. It distinguishes itself from runtime-measurement tools like the debug toolbar, silk, and assertNumQueries.

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 explicitly contrasts with tools that answer the same question by running the application, implying this tool is for when a pre-execution estimate is wanted. It stops short of enumerating sibling analysis tools or giving an explicit when-not-to-use list.

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