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

With no annotations provided, the description carries the full burden and adds meaningful behavioral context: it is rule-based, does not call an LLM, and does not consume quota. It also discloses the return value shape. The optional audit side effect when session_id is supplied is only mentioned in the schema, not the description, but that is a minor gap because the schema documents it.

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 compact and front-loaded: it states the purpose, the output, the key behavioral trait, and the intended usage context in three dense sentences. There is no filler or 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?

The description enumerates the return payload (L0-L3 verdicts, matched_rules, outcome, counts), which compensates for the lack of an output schema. Combined with a fully documented input schema, an agent has enough to call the tool correctly. Slightly more top-level transparency about the session_id audit write would round it out, but that is captured in the schema.

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%, and the input schema already documents all parameters and aliases in detail. The description adds little parameter-level meaning beyond 'submit action trajectory', so the baseline of 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?

The description states a specific verb and resource: risk-grading CUA action trajectories and returning L0-L3 verdicts, matched_rules, outcome, and counts. It is not a tautology and clearly communicates the tool's function, though it does not explicitly differentiate from sibling tools like check_safety 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 a clear applicability context: '用于在 agent 执行前/后做安全自检' (used for safety self-check before/after agent execution). It also notes that the tool is pure rule-based and consumes no LLM quota, which helps an agent decide when to invoke it. However, it does not mention exclusions or explicitly name alternatives among the sibling tools.

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.