Skip to main content
Glama
syrian963

django-chainsaw-mcp

by syrian963

blocking_in_async

Read-onlyIdempotent

Find blocking sync calls inside async Django endpoints that stall the event loop, including database calls and calls reached through project functions. Get the call path to fix the bottleneck.

Instructions

Synchronous calls that run on the event loop.

FastAPI runs an `async def` endpoint on the loop itself and a `def`
endpoint in a threadpool. So a blocking call inside `async def` does not
slow one request, it stops every request in the process - invisible at one
request a second, an outage at two hundred.

ruff's ASYNC rules cover open, time.sleep and subprocess inside an async
function. This adds the two that matter more: a synchronous database call,
which is the common one, and a blocking call reached through another
project function, where nothing at the call site looks blocking. The second
comes back with the path that reaches it.

Needs no Django. A `def` endpoint is never reported, because blocking in a
threadpool is fine and telling somebody to make it async causes the outage.

Args:
    search_path: directory to scan. Defaults to the configured project.
    follow_calls: also report blocking reached through a project function.
    max_depth: how many calls deep to follow.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_depthNo
search_pathNo
follow_callsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A5/5.0
Behavior5/5

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

Well beyond the readOnly/idempotent annotations, the description explains why blocking matters (it stalls every request in the process), what analysis behavior to expect (following calls through project functions and returning the path that reaches a blocking call), and constraints such as no Django requirement. There is 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?

The text is dense but organized: a summary sentence, a brief rationale, a coverage contrast, and an Args block. Each sentence contributes either selection guidance, behavioral expectations, or parameter semantics, with 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 that an output schema exists and annotations already convey the safety profile, the description covers purpose, usage conditions, behavioral edge cases, and all three parameters. Nothing needed to invoke or interpret the tool correctly 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?

Schema description coverage is 0%, so the description carries param documentation, and the Args block succeeds: search_path defines the directory and its project default, follow_calls defines the indirect-call coverage, and max_depth defines call-depth. This adds meaning well beyond the schema's types and defaults.

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 immediately scopes the tool to synchronous/blocking calls executed on the event loop, and then specifies the exact patterns it detects: synchronous database calls and blocking calls reached through project functions. It further clarifies what is out of scope (`def` endpoints), giving an agent a precise resource+verb pair that is distinct from sibling static-analysis tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

It gives concrete conditions: FastAPI async endpoints versus threadpool `def` endpoints, and explicitly says `def` endpoints are never reported because blocking there is acceptable. It also contrasts the tool with ruff's ASYNC rules, stating what coverage this tool adds, so an agent can decide when this tool rather than related checks applies.

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