Skip to main content
Glama
xTanTHaix

ait-mcp

by xTanTHaix
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ait_review

Audit Python files or directories using a 13-rule AST catalog to return machine-readable findings with severity, location, confidence, causation traces, repro witnesses, and unified diffs.

Instructions

Run the 13-rule AST catalog over a Python file or directory and return machine-readable findings: rule_id, severity (DEFECT/WARNING/ADVICE), location, symbol, confidence, causation trace, and where available a repro witness and a unified diff. USE WHEN: the user asks to review, audit, lint, or hunt bugs, race conditions, null dereferences, or swallowed errors in .py code, or before proposing a patch. DO NOT USE: to inspect one known symbol (use ait_slice_context) or to test a patch you already wrote (use ait_verify_fix). Note: use_cache=true (the default) writes /.ait_cache; findings are bounded by max_findings and severity_min.

Input Schema

NameRequiredDescriptionDefault
pathYesFile or directory to analyse, e.g. src/ait/mcp.py or src/ait.
exitfirstNoStop at the first file carrying a DEFECT.
use_cacheNoReuse the BLAKE2b cache; set false for one-shot scans that must not write into the tree.
max_findingsNoCap the returned findings (sorted by path,line); the tally still counts every finding.
severity_minNoDrop findings below this severity, e.g. DEFECT to return only defects.ADVICE

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description does real work: it discloses the cache side effect (use_cache=true writes <target>/.ait_cache), that findings are bounded by max_findings and severity_min, and enumerates returned fields including a causation trace and repro witness. It stops short of confirming whether the emitted unified diff is applied or merely shown, which leaves one behavioral question open.

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?

Front-loaded with the action and return shape, then cleanly sectioned into USE WHEN / DO NOT USE / NOTE. Dense but every clause carries information; the output-field enumeration is the only part that could be trimmed if an output schema existed.

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?

No output schema exists, but the description enumerates the returned fields (rule_id, severity, location, symbol, confidence, causation trace, repro witness, diff) and covers the cache side effect and result caps. An agent has everything needed to decide, invoke, and interpret the result.

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 coverage is 100% so the baseline is 3, and the description adds genuine context on top by explaining the default-on cache write and the interaction between max_findings bounding the returned list and severity_min filtering. It does not add anything beyond the schema for path or exitfirst, but that is acceptable given full coverage.

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?

States a specific verb+resource (run the 13-rule AST catalog over a Python file or directory) plus the exact output shape. The scope boundary ('a Python file or directory') makes it immediately distinguishable from the symbol-level and patch-level siblings.

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?

Explicit USE WHEN list enumerates the triggering tasks (review, audit, lint, bug hunt, before proposing a patch). Explicit DO NOT USE clause routes to the correct alternatives, ait_slice_context for one known symbol and ait_verify_fix for testing an already-written patch.

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

Deploy Server

Other Tools