Check for architectural changes in a workspace session without file generation. Returns status and remaining analysis time if ongoing.
轻量检查"有没有架构变更"——不生成文件、秒回。若 status=analyzing，看 remainingSec；不想等请直接调 av_session_report 或 av_guard（会取消防抖立即重算）。必须显式传当前工作区绝对路径 repo。
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | 必填。当前工作区根目录的绝对路径。 | |
| editDir | No | 可选。正在改代码的目录；与 repo 冲突时中止。 | |
| confirmRepo | No | 可选。确认检查 repo（当 cwd 是另一个 Git 根时）。 |
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 full burden and does disclose meaningful behavior: no files are generated, the call returns instantly, and the sibling tools cancel the debounce to force an immediate recompute. It does not explicitly state permission requirements or whether it mutates session state, which keeps it short of a 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?
A single dense paragraph, front-loaded with the purpose and its distinguishing traits. It is efficient, though the status/remainingSec and sibling-routing details make it slightly busier than strictly necessary.
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?
There is no output schema, so the description usefully references the returned status=analyzing field and remainingSec to guide interpretation of the result. For a lightweight read-only check, this is nearly complete, with only permissions/mutation semantics left unstated.
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 coverage is 100%, so the schema already documents all three parameters including the required absolute-path repo. The description's '必须显式传当前工作区绝对路径 repo' largely restates the schema, adding emphasis but no new semantic detail. Baseline 3 applies.
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?
States a specific verb+resource: a lightweight check for whether architecture changes exist, plus the key traits (no file generation, instant return). It also names the sibling tools it routes away from, though the purpose statement is intertwined with usage guidance rather than cleanly separated.
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?
Explicitly covers when to use it and what to do instead: if status=analyzing check remainingSec, and if you don't want to wait, call av_session_report or av_guard instead. Conditions and alternatives are both named, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.