Check architecture session status: baseline location, watcher activity, monitored repository, report cache freshness, and real-time fingerprint changes. Requires workspace path.
给使用者看的会话状态：基线在哪、watcher 是否在跑、监听哪个仓、报告是缓存还是过期、实时指纹有没有变。必须显式传当前工作区绝对路径 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?
No annotations are provided, so the description carries the full burden. It helpfully discloses the content of the report (baseline, watcher state, fingerprint change), which substitutes for the missing output schema, but never states that this is a non-mutating read or mentions permissions, repo-validation failure modes, or what the (repo, editDir) conflict abort means in practice.
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?
One compact sentence lists the reported fields, then a second sentence front-loads the mandatory parameter. No filler, no repetition; the only slight weakness is that the field list is dense prose rather than structured.
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?
With no output schema and no annotations, the description compensates by naming the returned status elements, which is the key information an agent needs. It is close to complete, with only the read-only nature and error behavior 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 description coverage is 100%, so the schema already documents repo, editDir, and confirmRepo in detail. The description only restates the required-repo rule, which is redundant with the schema's own '必填' note, adding no new syntax or format meaning.
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 enumerates exactly what the tool reports (baseline location, watcher liveness, watched repo, cached vs stale report, live fingerprint change), which is a specific, verifiable purpose. It is clear this is a status/inspection tool, though it does not explicitly distinguish itself from siblings like av_session_report or av_session_changes.
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?
It states a hard requirement (must explicitly pass the workspace absolute path) but gives no when-to-use context and no comparison to the sibling status/report tools. An agent must infer the usage scenario from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.