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

With no annotations, the description carries the full burden. It discloses key behaviors: auto-upload for local files, credit deduction ('会扣积分'), and product line restrictions. This goes beyond schema and gives important operational context, though it does not describe the return format or error cases.

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 tightly written in three sentences, front-loading the core purpose first, then usage input methods, then exclusions and cost. No wasteful sentences 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 description covers purpose, input methods, product restrictions, and cost, but lacks details on return values, error conditions, or how results are delivered (especially given no output schema). The existence of sibling get_check_result implies a separate retrieval step, but this is not mentioned, leaving the workflow incomplete.

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%, but the description adds meaningful param semantics: clarifies image supports local path vs URL and auto-upload behavior, and explains productVertical limitation (short drama unsupported). This adds value beyond schema, which already provides descriptions for all parameters.

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 detects image compliance risks across specific categories (广告违规, OCR文字, 涉政, 暴力, 色情, 侵权Logo). This specific verb+resource+scope distinguishes it from sibling tools like check_text and check_video, and the title (图片合规检测) aligns well.

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?

Provides clear usage context: supports local file paths (auto-upload) or public URLs, and explicitly states the short drama product line is unsupported ('短剧产品线没有图片检测'). However, it does not explicitly mention alternatives like check_text for text-only scenarios, so it lacks full when-not/alternative 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 transparency burden. It discloses the credit deduction per call, the two-tier risk output, and a warning against duplicate submissions. It does not mention async behavior, but that is covered in the schema's waitSeconds parameter description, so a 4 is warranted.

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 three sentences: first states the core action and output, second lists applicable content types, third covers cost and caution. Every sentence adds value, and the main purpose is front-loaded. No redundancy or padding.

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 7 parameters and no output schema, but the schema already explains parameter details thoroughly. The description adds necessary context about the pre-check use case, supported text types, and cost. It could mention the asynchronous retrieval flow (get_check_result), but that is already in the schema, making the description complete enough.

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 provides 100% parameter descriptions, including detailed explanations for all 7 parameters (e.g., platform, sceneMode, waitSeconds). The tool description adds no additional parameter-level meaning beyond the schema, so the baseline score of 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?

The description clearly states the tool's function: 对一段文案做发布前合规预检, with a specific verb (预检) and resource (文案). It also specifies the output (两档风险明细、法条依据与修改建议), distinguishing it from sibling tools like check_image/check_video (different media) and fix_text (fixing, not checking).

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 explicit scenarios (短视频脚本、口播稿、短剧剧本、投放素材文案、商品标题详情等) and a specific caution (同一段文案不要重复提交). It does not explicitly exclude alternative tools, but the context is clear enough for an agent to know when to use 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 provided, the description carries the full burden of behavioral disclosure. It discloses billing (1 credit/second), long processing times for long videos, auto-upload from local file paths, support for direct links, and optional drift detection via textCheckId. The param description also notes automatic deduction for under-reported duration, adding to the transparency.

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 three concise sentences that front-load the primary purpose, then cover input methods, billing, wait times, and an optional advanced feature. Every sentence adds unique value without repetition 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?

For a complex tool with 8 parameters and no output schema, the description covers key usage context: main function, input methods, billing, wait behavior, and optional drift detection. It mentions the return format as 'risk details with timestamps' but does not fully describe the response structure or timeout handling (though timeout is in the waitSeconds param). Overall, it is quite complete but could add a bit more about the output shape.

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 covers 100% of parameters with detailed descriptions, so the baseline is 3. The main description adds extra context beyond the schema by explaining the billing relationship with durationSeconds and the cross-check purpose of textCheckId, linking it to check_text. This enriches the parametric understanding without redundancy.

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 explicitly states that the tool detects compliance risks in video visuals, audio, and spoken script, and returns timestamped risk details. This clearly distinguishes it from sibling tools like check_text and check_image, which target different media types. The name 'check_video' and title '视频合规检测' reinforce the purpose.

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 conditions for using textCheckId (when the script was previously checked via check_text) and mentions billing and wait times to set expectations. However, it does not explicitly contrast with alternatives like check_image or specify when not to use the tool, though the media type distinction is evident from the tool names.

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 discloses the rewrite action, the dependency on a prior detection, and the credit deduction side effect. It does not cover reversibility or detailed return format, but the key behavioral traits are exposed.

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 two short sentences, front-loaded with the main action, and every sentence adds value: purpose, prerequisite, and consequence. 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 explains the required workflow (must have check id, costs credits) and implies the return of a compliant version, which is sufficient given no output schema. It is complete for the main use case, though it omits edge cases like invalid checkId handling.

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 baseline is 3. The description's mention of using check_text adds no new information beyond the schema's checkId description. Mode, strategy, and waitSeconds are fully documented in the schema.

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 triggers an AI rewrite for a completed text detection, producing a compliant version. It distinguishes itself from sibling tools by explicitly requiring a prior check_id from check_text, making its specific role obvious.

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 explicitly states the prerequisite of using check_text first, providing clear context for when to use the tool. However, it does not mention alternative tools or when-not-to-use conditions beyond the implicit credit cost, so it falls short of a 5.

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 explicitly discloses a key behavioral trait: '不扣积分' (does not deduct points), indicating a read-only operation. It also implies the tool is safe to call for balance verification. It doesn't cover auth or rate limits, but the main side-effect concern is addressed.

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 three sentences, each serving a purpose: stating what the tool does, when to use it, and a key side-effect note. It is front-loaded with the main purpose and wastes no words.

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 simple, zero-parameter tool, the description provides the purpose, a usage trigger, and return values (balance, subscription status, monthly usage). It doesn't cover return formatting, but the mentioned fields effectively communicate what the agent will receive, and no output schema exists to shift that burden.

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 coverage is 100% (no properties to describe). The baseline for zero-parameter tools is 4, and the description correctly adds no unnecessary parameter 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 queries the ByeRisk account's points balance, subscription status, and monthly usage. It uses a specific verb (查询) and resource (账户), and is clearly differentiated from sibling content-checking tools.

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 a specific trigger scenario (when detection reports 402 insufficient points) to use this tool to confirm balance. It doesn't explicitly discuss alternatives, but the sibling tools serve different purposes, so this context is sufficient for basic use cases.

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 full behavioral disclosure responsibility. It adds a useful fact (does not deduct credits: '不扣积分') and frames it as a one-time retrieval, but it does not mention error handling, return format, or what happens if the detection is still in progress beyond the waitSeconds parameter.

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 two short sentences, front-loaded with the core action and then specific use cases. Every sentence adds value with 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?

For a simple retrieval tool with full schema coverage and no output schema, the description provides the essential purpose, use cases, and a cost-related behavioral note. It could mention edge cases like invalid id, but it is reasonably complete for typical usage.

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%: all three parameters (id, type, waitSeconds) have descriptions, including the enum for type and default/max for waitSeconds. The description adds no extra parameter detail beyond what the schema already provides, so the baseline score 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?

The description clearly states the operation: '取一次已提交检测的结果' (get the result of a submitted detection by id). It uses a specific verb and resource, and distinguishes itself from sibling tools like check_text/check_image/check_video by focusing on result retrieval rather than submission.

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 explicitly says when to use this tool: when a previous call timed out or when reviewing historical detections. This provides clear context, though it does not explicitly mention when not to use it or name alternative tools (e.g., for new detections).

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