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

With no annotations, the description carries the full burden and does well: it enumerates the exact rule families and IDs executed (SEC001-012, COMPLEX001-005, STYLE001-005), so the agent knows the analysis is automatic and non-configurable, and it adds the important caveat that scores are a health reference, not an audit verdict. It still does not state that the operation is read-only or how it behaves on very large/unsupported files.

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 one-line purpose, then bulleted rule families, then the return payload and the scoring caveat — every block is scannable and earns its place. The rule-ID enumeration is the longest element but is useful signal rather than filler.

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 must describe the return payload, and it does: language, code/comment/blank line counts, issues with rule id/severity/category/confidence/suggestion, and overall/security/maintainability grades A-F. It also frames the score's meaning, leaving nothing essential for correct invocation or result interpretation.

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?

The schema gives only a bare 'File Path' string with 0% description coverage, and the description compensates by specifying that the path may be relative to the project root or absolute. That is genuine added meaning beyond the schema, though no error behavior for invalid paths is described.

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 opens with a specific verb+resource ('分析单个文件') and immediately narrows scope to a single file, which distinguishes it from the project-wide sibling check_project and the diff-oriented review_diff/review_changes. An agent can identify this as the per-file static analysis tool 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?

Scope ('单个文件') plus 'runs all applicable rules automatically' implies when this tool applies versus a project-wide scan, but no sibling is named and no when-not condition or prerequisite is stated. Usage is inferable rather than explicit.

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 well: it discloses that all supported source files are traversed, that the complete rule set runs per file, and exactly what the aggregation contains (counts, top-10 files, letter grade). It stops short of stating read-only safety, runtime cost on large repositories, or pagination/truncation behavior.

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?

The purpose is front-loaded in the first line, followed by a tightly scoped bullet list of what the aggregate contains, then the usage caveat, then the argument. Every element earns its place and nothing is repeated from structured fields.

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 one-parameter, read-only scan with no output schema and no annotations, the description is nearly self-sufficient: it explains both behavior and the shape of the return value in lieu of an output schema. It lacks only operational caveats such as expected runtime on large repos or handling of unreadable/unsupported files.

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 0%, so the description must compensate, and it does: it explains the single 'directory' parameter as the project directory to scan and states the default is the current directory. Only one parameter is required, and its meaning is fully covered, though path format/relative-vs-absolute semantics are not addressed.

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 gives a concrete verb+resource: it scans a project directory and returns an aggregate code-quality overview (file/line counts, language distribution, severity counts, top-10 problem files, A-F grade). Its project-wide aggregate scope implicitly separates it from the per-file/per-change siblings (analyze_file, review_diff, review_changes), though no sibling is named explicitly.

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 clear use case ('适合在不熟悉的仓库里摸底') and an explicit caution/kill-criterion ('不要把它当审查结论'), which steers the agent away from treating output as a review verdict. It does not name the alternative tools for when narrow, file-level, or diff-level analysis is needed.

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 clearly indicates this is a read-only listing operation and describes the return fields (ID, name, description, category, default severity). However, it does not disclose potential ordering, filtering, or error conditions.

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?

The description consists of two concise sentences with the purpose front-loaded. Every word adds value, no redundancy.

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?

Given zero parameters and no output schema, the description fully explains what the tool does and what it returns. It is complete for a simple listing tool.

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?

There are no parameters, and schema description coverage is 100% (vacuous). The description adds context about what the tool returns, but since there are no parameters, it is not deficient. The baseline of 3 is exceeded because the description still provides helpful output information.

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 clearly states the tool lists all registered code review rules, using the verb '列出' (list) and resource '代码审查规则' (code review rules). It distinguishes from sibling tools (analyze_file, check_project, review_diff) which involve analysis or checking rather than listing.

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?

The description implies usage for AI selective calling but does not explicitly state when to use this tool versus alternatives or provide exclusions. Usage is implied as a prerequisite for selecting rules.

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 substantial work: it discloses that output is facts-only and not review verdicts, that every finding needs source confirmation, that limits include skipped/truncated files, that non-git repos return an error+hint, and it defines signal classification (SEC005 vs security_finding). The one gap is that it never explicitly states the tool is read-only and has no side effects on the repository.

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 purpose and organized into Args / Returns / usage-order blocks, so it is easy to scan. It is nonetheless long, and the Returns enumeration is dense; it earns most of its length because no output schema exists, but it could be slightly tighter.

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 3-param flagship tool with no annotations and no output schema, the description covers parameters, return structure, traversal order, error paths, and sibling routing. An agent has everything needed to call it correctly and interpret the result.

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 0%, so the description must compensate fully and does: scope enumerates all three accepted values with precise meanings, base is documented with examples and gated to scope='base', and directory explains both the default (cwd) and the subdirectory-scoping behavior. This is more informative than the schema itself.

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 ('审查一个 git 变更') and names the concrete deliverable ('审查证据包'), then enumerates exactly what that pack contains. It also distinguishes itself from a sibling by routing single-file work to analyze_file: '单文件场景请改用 analyze_file'.

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 explicit defaults and selection conditions for each scope ('working' default = unstaged+staged+untracked, 'staged', 'base' requires base), plus an explicit alternative for the single-file case. It further specifies the recommended traversal order (focus → priority=high files → signals → limits) and the non-git-repo fallback.

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 scope (staged + unstaged) and the exact detection set DIFF001-DIFF004 with severity for secrets. It does not describe the return format or how findings are reported, which is a gap for a no-output-schema tool, but the behavioral profile is otherwise well covered.

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 deprecation notice and migration path before the detection list, so the most decision-relevant fact is first. The bulleted detection rules are scannable, though the deprecation paragraph and rules list make it longer 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?

For a zero-param, no-annotation, no-output-schema tool, the description covers purpose, deprecation status, migration target, and detection scope. The only notable omission is what the response looks like, which the agent must infer.

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?

The tool takes zero parameters, so the baseline is 4 and the description does not need to explain any input. It correctly implies operation against the current repository context.

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 (审查/review) and resource (当前 git 仓库中未提交的变更, staged + unstaged), and explicitly contrasts itself with the sibling review_changes. An agent can distinguish it from review_changes and analyze_file without opening any 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 marks itself deprecated for v0.2.x callers only and names review_changes as the replacement, with the concrete reasons (变更级信号, 只报新增行, 复杂度回归, working/staged/base 三种范围). When-to-use and when-not-to-use are both stated.

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