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

Annotations declare readOnlyHint=false, indicating a mutating operation. The description adds that the link is temporary and that the user receives an identifier code after upload. However, it does not disclose side effects like link expiration details, permission requirements, or consequences of exceeding maxUses. Given annotations only cover safety, this is acceptable but not rich.

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 concise sentences in Chinese, front-loaded with the core purpose (generating a link) and followed by the essential workflow. Every sentence adds value without redundancy, making it highly efficient.

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 explain the expected return and flow. It clearly explains that the tool generates a link, the user uploads, and a code is returned for use with download_file. It doesn't specify the exact return structure (e.g., URL format), but for a zero-required-parameter tool with a straightforward purpose, it is sufficiently complete.

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 baseline 3 applies. The description does not add extra meaning to parameters beyond what the schema already provides; all parameter descriptions are clear and self-contained.

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: generating a temporary upload page link to be sent to a human user for browser uploads. It uses a specific verb ('generate') and resource ('upload link'), and distinguishes itself from siblings by mentioning the identifier code workflow with download_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?

The description provides clear usage context: use when you need a human to upload files via a browser link, then retrieve the file with download_file. It implies the workflow but does not explicitly mention alternatives like upload_file for direct uploads or when not to use it, so it's slightly incomplete.

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?

Beyond annotations (destructiveHint=true, idempotentHint=true), the description adds that both file and metadata are deleted immediately and that the operation is irreversible. This provides context about scope and immediacy.

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?

Two short sentences in Chinese convey the action, target, timing, and irreversibility with zero redundant content. Information is front-loaded.

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 one-parameter destructive tool with good annotations and full schema coverage, the description is adequate. It clarifies what is deleted and the immediate nature, though it doesn't describe error behavior or return values (no output 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?

The input schema fully documents the 'code' parameter with details on case-insensitivity and examples. The description does not add further parameter details, so baseline 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 clearly states the action: 'immediately delete the file and metadata with the specified ID code.' It distinguishes from siblings like extend_expiry (which preserves files) and sweep_expired (bulk deletion of expired files), and explicitly mentions it is irreversible.

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 use when you need to delete a file before its natural expiration ('不等到期'), but does not explicitly contrast with alternatives like extend_expiry or sweep_expired. Sibling list is provided but not referenced.

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?

Annotation contradiction: the description states '传 savePath 可以直接写到服务器本地路径' (passing savePath writes directly to a server local path), which implies a write side effect, while annotations declare readOnlyHint=true. This directly contradicts the annotation's indication that the tool does not modify state.

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, front-loaded sentences. The first sentence states the primary purpose, and the next two add essential behavior details without unnecessary 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 carries the burden of explaining return behavior; it does cover text/base64/link outcomes. However, it lacks explicit error cases, prerequisites, and alternative-tool guidance, and the readOnly/savePath contradiction reduces overall reliability.

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%, providing a baseline of 3. The description adds meaningful semantics beyond the schema: it explains the default auto-encoding behavior (text returns body, binary returns base64), the savePath side effect, and the 'file too large returns link' fallback, which clarifies how parameters like encoding and maxInlineBytes behave.

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 purpose: '根据标识码取回文件内容' (retrieve file content by identifier code). It uses a specific verb and resource, and is easily distinguished from siblings like upload_file, get_file_info, and delete_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?

The context for use is implied: you use this when you have a file code and need its content. However, there is no explicit guidance on when to prefer this tool over alternatives (e.g., get_file_info for metadata) and no when-not-to-use exclusions.

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?

The annotations already indicate a mutating, non-destructive, idempotent operation. The description adds valuable behavioral specifics: the expiry is recalculated from 'now', and there is a hard limit of 720 hours. This goes beyond the annotations and clarifies the operation's semantics.

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, well-structured sentence that immediately conveys the core behavior. It is succinct with no redundant wording, making it easy to parse quickly.

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 tool with two parameters and no output schema, the description covers the essential behavior and constraints. It does not mention return values or error handling, but given the annotations and schema coverage, it is sufficiently complete for an agent to understand when and how to invoke it.

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?

While the schema provides full descriptions for both parameters, the description enhances understanding by clarifying that hours are relative to 'now' and specifying the 720-hour upper bound, which the schema does not include. This adds semantic meaning beyond the formal 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's purpose: recalculate a file's expiration time to be retained for N hours from now, with a 720-hour cap. It uses a specific verb (recalculate/extend) and resource (file expiry), distinguishing it from siblings like delete_file or sweep_expired.

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 does not explicitly specify when to use this tool versus alternatives. It explains what it does but lacks context like 'Use this when you need to keep a file longer' or exclusions (e.g., instead of delete_file). No when-not-to-use 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?

The description adds valuable behavioral context beyond the readOnlyHint annotation by enumerating the exact fields returned and stating that file content is omitted. This is particularly useful since there is no output schema. No contradictions with annotations.

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 sentence that efficiently conveys the action, the target resource, and the critical exclusion. It is front-loaded and every phrase earns its place.

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 single-parameter read-only tool without an output schema, the description sufficiently lists the return fields and notes the content exclusion. It could optionally mention error behavior or permission requirements, but these are not critical given the read-only nature and annotation coverage.

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% with detailed parameter documentation including format examples and case-insensitivity. The description's reference to '标识码' adds no extra 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 specifies a read-only 'view' operation for file metadata (name, size, checksum, download link, retention time) and explicitly distinguishes itself from content-fetching by stating it does not return file content. This provides a specific verb, resource, and scope that differentiates it from sibling tools like download_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?

The description clearly implies that this tool is for metadata retrieval when file content is not needed, and the explicit 'does not return file content' provides a clear when-not-to-use. However, it does not name specific alternative tools like download_file, so it lacks explicit 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?

The readOnlyHint and openWorldHint annotations already communicate safety, so the description adds value by specifying the exact data returned (file count, space, retention policy, next expiry). It does not disclose potential performance costs, but that is a minor gap given the simple read operation.

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?

One concise sentence conveys all essential information without redundancy. It is front-loaded and easy to parse.

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 the tool's simplicity (no parameters, no output schema), the description sufficiently covers the return information by listing the four metrics. The read-only annotation completes the safety context, making this fully adequate for agent invocation.

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, so the schema provides complete coverage. The description correctly omits parameter details, and the baseline of 4 for zero-parameter tools 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 clearly states the tool's function: viewing current file count, occupied space, retention policy, and next expiration time. This is a specific verb-resource pair that distinguishes it from siblings like list_files (file listing) and get_file_info (single file details).

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 use for monitoring storage overview but does not explicitly contrast with alternatives such as list_files or get_file_info. There are no exclusions or when-not-to-use conditions, so it meets the 'implied usage' 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?

Annotations declare readOnlyHint=true, so the read-only nature is already known. The description adds meaningful behavioral context: it lists only current non-expired files by default, supports filtering/pagination, and includes an includeExpired parameter for pending cleanup records. This goes beyond the annotations to clarify default scope and edge 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 two sentences, front-loads the core purpose, and includes a practical usage tip. Every sentence earns its place, with no fluff or repetition of schema details.

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 read-only list tool with no output schema, the description adequately explains the default scope (non-expired), filtering/pagination capabilities, and a use case. It could mention that includeExpired covers not-yet-cleaned records, but that's already in the schema. The description is sufficiently complete for selecting this 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?

The input schema has 100% description coverage for all 6 parameters, so the schema already documents each parameter's meaning. The description adds a high-level summary of what filtering is possible (keyword, tag, pagination) but doesn't add details beyond the schema. Baseline 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 uses a clear verb ('列出' - list) and resource ('当前未过期的文件' - current non-expired files), and explicitly mentions filtering and pagination capabilities. It also distinguishes itself by noting this is the tool to use when the identifier is forgotten ('忘记标识码时用它找回文件'), which differentiates it from siblings like get_file_info and download_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?

The description implies usage context: it's for browsing/finding files when you don't have the identifier, and mentions it lists non-expired files. However, it doesn't explicitly list alternatives or exclusions (e.g., when to use get_file_info instead). The sibling context helps but the description itself could be more 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?

Annotations already indicate destructive and idempotent behavior. The description adds valuable context that this is a manual supplement to a scheduled background task, which prevents an agent from calling it redundantly. No contradiction with annotations.

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 is front-loaded with the purpose and immediately follows with usage context. Every word earns its place.

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-parameter tool with strong annotations, the description is sufficient. It explains the purpose and when to avoid use, though it could explicitly mention that 'cleanup' implies permanent deletion of expired files, especially given the destructiveHint.

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?

With zero parameters and 100% schema coverage, the description appropriately adds no parameter details. The baseline of 4 is appropriate since there is no additional semantic burden to carry.

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 specific action: '手动触发一次到期清理' (manually trigger an expired-file cleanup). It distinguishes itself from all sibling tools, which focus on file operations, by targeting the cleanup task directly.

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 when not to use it: '一般无需调用' because a background task already runs the cleanup. This gives clear guidance for an agent to avoid unnecessary invocation, though it doesn't provide alternative 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?

The annotations already signal readOnly=false and destructive=false, and the description adds non-obvious behaviors: default 24-hour retention with auto-deletion, base64 for binary content, server-side URL fetching, and source mutual exclusivity. No contradiction with annotations.

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 with the main purpose, followed by a practical bulleted list. Every sentence earns its place by conveying non-obvious constraints or defaults.

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 10-parameter upload tool with no output schema, the description covers core behavior, source alternatives, and retention policy. It could mention response format or size limits, but the provided guidance is sufficient for selecting and invoking the tool correctly.

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, but the description adds critical semantics beyond the schema: mutual exclusivity among source parameters, binary vs. text handling, and the default/range of ttlHours. Other params like tags and uploadedBy rely on 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 uploads a file and returns an identification code and download link, with a specific verb and resource. It is distinct from sibling tools like download_file, delete_file, and list_files.

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 explicitly explains that only one of content/text/path/url may be used and describes the appropriate scenario for each. It also gives the default retention and how to override via ttlHours, though it does not explicitly contrast with sibling upload link creation.

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