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

No annotations are provided, so the description carries the full behavioral burden and does so well: it discloses the opt-in gate, the scope downgrade behavior, the optional external CLI validation, the exact validation.status outcome set, and the critical caveat that unvalidated/failed results must not be treated as verified artifacts.

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?

Purpose is front-loaded in the first clause and every sentence carries operational content, with little filler. It is somewhat dense as a single run-on block and could be organized more scanably, but nothing 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?

Even without an output schema, the description names the artifacts produced (Before/After JSON + sidecar) and the validation status contract, and it covers the required repo path and confirm gate. An agent has everything needed to invoke it correctly.

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 four parameters and the baseline is 3. The description adds genuine semantics beyond the schema: the density/additive condition that triggers a downgrade to layers, and the meaning of validation.status values.

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 (export) and resource (this round's structural diff as an Archify IR sparse graph, delivered as Before/After JSON + sidecar), and its default-off behavior clearly distinguishes it from read-only siblings like av_session_report and av_status. An agent can tell what this produces without opening the 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?

Explicitly states the precondition (human must verify evidence before passing confirm=true), the default posture (no export, no auto-graphing), and the conditional route (scope=changed by default, downgrade to layers when too dense or purely additive). These are concrete when/when-not rules rather than implied guidance.

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

Does 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.

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

With no annotations the description carries the full burden, and it does disclose non-obvious behavior: the shared snapshot/index basis, session mode being read-only against the current round only, hard-error rather than silent full rescan, and repo being mandatory. It still omits what the returned evidence/fix structure looks like or permission requirements.

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?

Three tight sentences that front-load the core action before the snapshot/session caveats and the required-parameter note. No padding, though the repo reminder is somewhat redundant with the schema.

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 finding-explanation tool with no output schema, the description covers inputs, snapshot semantics, and failure behavior adequately. A brief note on what the explanation contains would close the remaining gap.

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 baseline is 3. The description reinforces that repo must be an absolute workspace path and that from=session restricts the lookup, but both points are already stated in the schema, adding little beyond it.

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 (解释) and resource (某条 finding), plus what it returns conceptually — 结构化边证据与修复建议. It names av_check_layering to establish lineage, but does not sharply contrast itself with the other siblings (av_session_report, av_status), so sibling differentiation is partial.

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?

Explains default behavior (same snapshot/index as av_check_layering, excluding inventory) and when the from=session path applies, including that a missing report errors instead of falling back to a full rescan. It does not explicitly tell the agent when to prefer this over av_check_layering or av_session_report.

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

Does 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: it auto-runs 'ensure' when no baseline exists, compares against git HEAD otherwise, caps output at a ≤3-line verdict, and offers optional HTML detail. It does not state whether the auto-ensure step mutates the workspace or what permissions are needed, which is a notable gap for a check that can create baselines.

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?

It is front-loaded with the core purpose and packed into a few dense clauses with no filler. The trade-off is density – several distinct facts (baseline logic, HEAD comparison, output format, path requirement) are compressed into a single run-on span.

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 three-parameter check tool with no output schema, it covers the essentials: what it does, when to call it, how baselines are handled, and the shape of the return (≤3-line verdict). Missing only the side-effect/permission posture of the automatic ensure step.

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 all three parameters already have documentation, making 3 the baseline. The description only reiterates the required 'repo' absolute-path constraint already stated in the schema, adding no new syntax or behavioral nuance for editDir or confirmRepo.

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 names a specific capability – a daily structural acceptance check ('日常结构验收') that returns a short verdict, and notes cross-harness support (Cursor/Claude/DeepSeek). The verb+resource are identifiable, though the jargon term 'structural acceptance' is abstract enough that it doesn't cleanly separate this from siblings like av_check_layering or av_status without context.

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 gives clear timing guidance – 'prefer calling this before claiming completion' ('宣称完成前优先调这个') – which establishes a concrete trigger. However, it never names an alternative tool or a when-not condition, so the agent must still infer how it differs from the many av_* siblings.

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

Does 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.

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

With no annotations the description carries the full burden, and it does disclose real behavior: it cancels an in-progress debounce and immediately recomputes, it writes built-in HTML by default (Before/Delta/After), and HTML is optional. It does not discuss permissions or reversibility, but the key side effects and defaults are surfaced.

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-loads the verdict content, which is good, but then strings together several loosely related clauses (HEAD default, av_guard, debounce cancellation, HTML output, required repo) in dense run-on sentences. Nothing is wasted, but it reads as an accumulation of notes rather than a structured definition.

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?

No output schema exists, and the description compensates by describing the return payload (verdict components plus full report and HTML). Combined with 100% schema coverage of inputs, an agent has enough to call it correctly, though the side-effect ordering is only lightly explained.

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 four parameters. The description only reiterates that repo must be explicitly passed as an absolute workspace path, matching the schema, and adds no new meaning for from/editDir/confirmRepo. Baseline 3 is appropriate.

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 and resource: it returns the structural acceptance verdict (light color + risk count + most severe item) plus the full report. It also names sibling tools (av_guard, av_session_start) and distinguishes when those apply, though the exact relationship to av_session_report is a little tangled.

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?

Gives concrete routing guidance: with git it defaults to comparing against HEAD so av_session_start is unnecessary, and it points to av_guard for day-to-day use. That covers context and alternatives clearly, though it stops short of explicit when-NOT-to-use exclusions.

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

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

With no annotations, the description carries the burden and does well: it discloses auto-monitoring with an ~8s debounce under MCP, that the CLI does not continuously monitor, the need to echo the returned path.checking, and that the tool is fully offline. It stops short of describing what the snapshot records or any failure/abort behavior beyond the editDir mismatch noted in the schema.

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?

Purpose is front-loaded and every clause carries operational weight (monitoring, offline, required path echo). It is somewhat crammed into a few dense sentences, but there is no filler to cut.

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 session-start tool with no annotations and no output schema, the description supplies the behavioral context an agent needs (monitoring semantics, offline mode, required echo of output). Only minor gaps remain around what the snapshot contains or how failures surface.

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 all four parameters are already documented with descriptions including the worktree warning and the Git-root constraint. The description reinforces that repo must be the workspace absolute path, but adds no format or syntax beyond the schema, matching the baseline-3 rule.

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 opening clause states a concrete action and metaphor (take a 'before' snapshot recording current structure) and the tool name plus sibling reference make the resource clear. It is identifiable as a session-initialization tool distinct from the report/changes siblings, though the purpose statement is interleaved with operational caveats 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 says to run before editing code, notes the daily-priority alternative (av_guard), and distinguishes MCP-backed auto-monitoring from the CLI path that requires a manual report. When-to-use, when-to-prefer-a-sibling, and the environment-dependent difference are all stated without inference.

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

Does 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.