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 states the tool is pure rule-based ('不调 LLM、不耗额度'), advisory-only ('未执行实际拦截'), and discloses that task_scope can only escalate, that optional delegation-chain fields have zero impact when omitted, and that verdicts are aggregated to L3 with a risk_diluted flag on cross-agent propagation. It omits auth/permission requirements and error/limit behavior, so it is strong but not exhaustive.

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 content is front-loaded with the core verb, but it is delivered as one very long semicolon-joined paragraph and repeats schema-level details (delegation_depth escalation, task_scope narrowing). Information density is high, yet structure and non-redundancy are only adequate.

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 cover returns, and it does: matched_rules, outcome, per-level counts, ruleset_version, disclaimer, and chain_trace are all named, alongside which rule categories are covered. An agent has enough to call and interpret the tool, with only minor gaps around permissions and failure modes.

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 every action field, alias, and nested scope property, making 3 the baseline. The description adds some cross-parameter meaning (scope narrowing only escalates, chain_id/agent_id/parent_agent_id trigger server-side chain taint analysis, session_id writes to the audit table), but it largely restates what the schema descriptions already say.

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 precise verb+resource: grade a Computer-Use Agent action trajectory, returning per-step L0–L3/takeover verdicts plus matched_rules, outcome and summary counts. It clearly distinguishes itself from a generic safety check by being trajectory/action-oriented, but never names its siblings (check_cua_code_audit, check_safety, verify_text) to make the boundary explicit.

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 a concrete usage context: '用于在 agent 执行前/后做安全自检' (run before/after agent execution as a safety self-check). That is clear context, but there are no exclusions and no explicit routing against the sibling safety tools, so it stops short of a full when/when-not statement.

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 meaningful behavior: it is a deterministic rule scan that calls no LLM and consumes no quota. It also implies a read-only, non-mutating operation. It stops short of describing the resulting report, severity levels, or any limits, leaving notable behavioral gaps for a tool with zero annotation coverage.

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 tight paragraph that front-loads the core purpose, then the detection categories, then the behavioral trait and file-mode note. Every clause carries information; the enumeration is dense but relevant, with no filler or repetition.

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?

The tool has no output schema and no annotations, so the description should ideally characterize the audit report it returns; instead it only describes what is scanned and how. It covers purpose, detection scope, and the quota-free nature well, but the absence of any return-value or result-shape description leaves a real gap for a scanning 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?

Schema description coverage is 100%, so the schema already documents code, files, filename, and language in detail (including the 二选一 / mutually-exclusive relationship). The description adds little parameter-level meaning beyond reiterating single-file vs multi-file support, so the 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 (静态分析 Agent 源码 / statically analyze Agent source code) and enumerates exactly what it looks for (dangerous imports, eval/exec, injection surface, dangerous defaults, missing sandbox). An agent can tell it is a code auditor. However, it never names or distinguishes itself from sibling scanners (check_safety, verify_agent, check_cua_actions), so it misses the 5 bar for sibling differentiation.

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 clause '纯规则扫描，不调 LLM、不耗额度' implies a usage context (prefer this deterministic, quota-free check) and '支持单文件或多文件扫描' hints at input modes, which are implied usage cues. But there is no explicit when-to-use, when-not, or routing versus the other check_*/verify_* siblings, so guidance stays at the inferred level.

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 largely delivers: it discloses that the tool runs rule-based plus optional LLM checks, returns specific risk fields, supports a fast <10ms mode, and consumes detect quota even in fast mode. It does not discuss mutability or side effects, but for a detection tool this is adequate.

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 dense and front-loaded, stating the core purpose first, then detection layers, return schema, fast-mode behavior, and quota impact. Every sentence conveys actionable information without redundancy or 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?

Given no output schema, the description compensates by naming the main return fields (passed, risk_score, risk_level, threats[], quota) and by explaining fast-mode routing. It does not describe possible errors or quota limits in detail, but for a 4-parameter safety check tool the provided context is largely 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?

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying the fast-mode semantics, the prompt+output relationship, optional hallucination checking, and the returned risk structure. This is more than the schema alone provides, so a 4 is justified.

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 a specific verb and resource: an AI safety gateway that detects OWASP LLM Top 10 risks on prompt and output. It further distinguishes the tool by enumerating rule engine dimensions, optional LLM analysis, and hallucination detection, making it easy to tell apart from siblings like verify_text or verify_agent.

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 gives clear context for when to use the tool: whenever an AI prompt/output needs safety screening. It also explains the fast-mode vs full-mode choice and quota behavior excluded. However, it does not explicitly mention cases where sibling tools should be used instead, so no exclusions or when-not guidance is provided.

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. It does disclose a meaningful behavioral trait: '耗 detect 额度' (consumes detect quota), effectively a cost/rate-limit warning, and clarifies the evaluation dimensions and return payload. It omits failure modes, error behavior, and how quota is shared across calls, but for a non-mutating analysis tool the disclosed cost and output structure are adequate.

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 terse sentences in the source language with zero filler. Purpose is front-loaded first, then return values, then cost. Every clause carries information – no repetition of the tool name or schema content. Efficient and well-ordered.

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 complex tool with 6 params and nested objects but no output schema, the description compensates reasonably by naming the return fields (main.claims, steps[].checks, quota) and the quota-cost behavior. It does not fully explain the return structure's semantics or the effect of speed/domain switches, but for an analysis tool the coverage is strong.

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 fully documents all six parameters. The description adds only framing: it ties 'task' to task_completion judging and maps the six dimensions to steps[].checks, but does not explain the semantics of speed modes (fast|standard|deep), domain values, or tool_schemas beyond what the schema already provides. Baseline 3 applies since the schema does the heavy lifting.

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 pair ('Agent 输出与轨迹自检' – output and trajectory self-check) and details exactly what it does: per-claim hallucination verification plus a six-dimension structured evaluation (事实性/来源/指令合规/工具声明一致/任务完成/反思). It names the concrete return structures, making the tool's function unambiguous and distinct from simpler verifiers.

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 scope is implied through the six evaluation dimensions and the agent_trajectory param, which signals this is for full agent runs rather than single strings. However, it never explicitly contrasts with siblings like verify_text, check_cua_actions, or check_safety, nor states when NOT to use it. The '耗 detect 额度' cost note is useful resource guidance but not a when/when-not rule.

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 provided, the description carries the full burden of behavioral disclosure. It does disclose that the tool consumes detect quota (a side effect) and describes the return structure (red/yellow/green summary, per-claim details, citations, quota). However, it does not mention potential rate limits, authentication, or any other operational behaviors. The disclosure is partial but not misleading.

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, dense paragraph that front-loads the core purpose ('逐声明幻觉核验') and follows with the pipeline and output details. Every clause adds value, and there is no redundant fluff. It is concise yet information-dense, though it could benefit from bullet points for readability.

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 that there is no output schema, the description appropriately describes the return format (summary, per-claim details, citations, quota). It also mentions the quota cost. However, it does not address error scenarios, retry behavior, or any edge cases like empty text (though schema enforces minLength). For a tool with this complexity and 5 parameters, the description is mostly complete but could mention what happens on failure.

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 input schema has 100% description coverage for all 5 parameters, so the schema itself provides clear meanings for each field. The tool description adds no additional parameter-specific context beyond the overall pipeline. Given the high schema coverage, a baseline of 3 is appropriate; the description does not need to compensate.

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's function: verifying statements in input text for hallucinations, with a specific pipeline (extract claims, verify each) and output types. It is specific about the verb and resource. However, it does not explicitly distinguish itself from sibling tools like verify_agent, though the name 'verify_text' suggests a text-focused scope.

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 provides no guidance on when to use this tool versus alternatives. It does not mention when it is appropriate or when to choose verify_agent or other siblings. The only usage-related note is that it consumes detect quota, which is a cost constraint but not a usage guideline.

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