Analyze a repository snapshot offline to detect layering violations and structural issues. Counts violations, lists inventory of dependencies and orphan entities, and returns source summary.
检查当前仓库快照（不使用基线，包含历史存量，不能归因于本轮变更）。分层违规、其他结构问题、分析提示分别计数；现有依赖/体量/孤立实体另列 inventory，不算分层违规。不执行本轮变更专用规则。日常验收用 av_guard / av_session_report。返回实际运行包及分析源码摘要。完全离线。必须显式传当前工作区绝对路径 repo。
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | 必填。当前工作区根目录的绝对路径。 |
Changes observed during successful MCP inspections.
v0.12.2-rc.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does so well: it discloses the no-baseline/whole-snapshot semantics, that results are not attributable to the current change, that change-specific rules are skipped, that it is fully offline, and that it returns the actual execution bundle plus an analyzed source summary. It stops short of permission/rate-limit or failure-mode details, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the snapshot semantics before the routing and return notes, and every clause carries information. It is dense and somewhat run-on, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema or annotations, the description is nearly complete: it covers scope, attribution caveat, excluded rules, offline behavior, return summary, and the required absolute-path argument. Minor gaps around failure behavior keep it from 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single required param, so the schema already documents 'repo'. The description only reinforces that the workspace absolute path must be passed explicitly, adding marginal meaning beyond the schema — the baseline 3 for high-coverage cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource matrix: it checks the current repository snapshot for layering violations, other structural issues, and analysis hints, and explicitly distinguishes what does not count as a violation (dependencies/size/orphan entities, listed separately in inventory). It also names siblings (av_guard / av_session_report) so an agent can tell it apart from the daily-acceptance tools without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is scoped explicitly: it does not use a baseline, includes historical backlog, and cannot be attributed to this round of changes, and it does not run change-specific rules. The description routes the agent to av_guard / av_session_report for daily acceptance, giving an explicit alternative and the condition that selects it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.