运行黄雀自审

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

The description explicitly states it will not write reports to any path, which is a valuable behavioral disclosure beyond the readOnlyHint and non-destructive annotations. This addresses a common concern about audit tools that might produce output files. Combined with the annotations (readOnly, idempotent, non-destructive), the agent has a clear safety profile. It doesn't describe what the audit returns or whether it can be run concurrently, but that is partially covered by the output 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?

The description is a single, concise sentence that communicates the tool's purpose and a key behavioral guarantee. There is no wasted text, and critical information (that no report is written) is front-loaded. Excellent for a zero-parameter tool.

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 zero parameters, a clear read-only purpose, and an output schema available, the description covers the essential context. The only gap is that it doesn't explain what the audit report contains or how to interpret the response, but the output schema likely handles that. For a simple, self-contained audit tool, this is sufficient.

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 has zero parameters, and the schema has no properties. Since there are no parameters to describe, the baseline is 4 per the rubric. The description adds no parameter semantics because none exist, which is appropriate. The tool's behavior is fully specified by its name and description.

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 the tool runs invariant and external activation checks, which clearly identifies the purpose as an audit operation. It distinguishes from siblings by referencing '自审' (self-audit) rather than source management or pipeline execution, though it doesn't explicitly name an alternative tool for other audit-like operations.

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 this is a standalone audit tool with no parameters, suggesting it should be run to check invariants and external activations. It doesn't explicitly state when to use it versus siblings, but the context of '自审' (self-audit) and the sibling list (which includes pipeline and source management) provides enough distinction. No exclusions or alternatives are named, so it's slightly below a perfect 5.

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