stagenth · file-relay

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

With no annotations, the description carries the transparency burden. It explicitly discloses idempotent behavior ('如果路径已经存在, 直接返回该文件夹元数据') and compares to mkdir -p for recursive creation. It does not detail permission requirements or edge-case errors, but the core mutation behavior and return-on-existing behavior are transparent.

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 extremely concise: two short sentences, front-loaded with the action and an analogy, followed by a crucial idempotency note. Every word contributes value, and there is no redundancy with the schema.

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 one-parameter create-folder tool with no output schema, the description provides the essential behavioral context: recursive mkdir -p-style creation and idempotent return. The normal-case return metadata is only implied, and error conditions are not discussed, but these are minor gaps given the tool's simplicity.

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 already documents the single parameter with full detail, including path format and mkdir -p semantics, so description-level parameter clarification is unnecessary. The tool description adds the idempotency note, which is behavioral rather than parameter-specific. Per rubric, high schema coverage establishes a baseline of 3.

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?

Description opens with '创建文件夹' and the mkdir -p analogy, making the action and resource unmistakable. It is unique among the sibling tools (the only folder-creation tool), so there is clear differentiation. The verb+resource specificity is strong.

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 mkdir -p analogy and idempotency statement give clear context for when to use the tool: create a folder recursively and safely even if the path already exists. It does not explicitly list when-not scenarios, but no alternative create-folder tool exists in the sibling list, so the guidance is sufficient.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the basic function without mentioning side effects, permission requirements, or the nature of the returned share link. For a mutation-like operation, this is a significant transparency gap.

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 effectively communicates the tool's purpose without unnecessary verbosity. It is appropriately front-loaded and contains no redundant information.

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?

While the input schema thoroughly documents parameters, the description omits critical context such as what the tool returns (the share link itself) and any prerequisites or side effects. With no output schema and no annotations, the description is incomplete for a tool whose primary output is the generated link.

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%, with all four parameters having clear descriptions (e.g., 'expires_in_seconds' notes that omitting it means permanent). The description itself adds no parameter-level meaning beyond what the schema already provides, so the baseline score 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 clearly states the tool's function with a specific verb and resource: "为文件生成一个分享链接" (generate a share link for a file). This unambiguously distinguishes it from sibling tools like download_shared_file or import_shared_file, which consume share links rather than create them.

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 context for when the tool should be used: whenever a share link for a file is needed. It does not explicitly mention alternatives or exclusions, but there are no competing sibling tools for creating share links, so the usage context is sufficiently clear.

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 entire burden of behavioral disclosure. It merely states 'delete a file' without mentioning irreversibility, permission requirements, trash behavior, or side effects. This is a critical gap for a mutation tool, as the agent cannot assess the consequences of invocation.

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 short sentence, making it extremely concise and front-loaded with the core purpose. However, it omits essential behavioral context, so while there is no wasted text, the brevity borders on under-specification.

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 delete operation, the description is underspecified: it lacks information about what happens to the file (e.g., permanent vs. trash), required permissions, and how it differs from bulk delete tools. The presence of sibling tools like delete_files and delete_folder further highlights the need for clearer scoping. Without annotations or output schema, this is insufficient for safe 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?

The input schema fully documents the single parameter file_id with a Chinese description '文件 ID', achieving 100% coverage. The tool description adds no additional parameter-level detail, so the schema already provides the necessary semantics. Baseline 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 identifies the action (delete) and resource (file), but it does not explicitly distinguish this from sibling tools like delete_files (plural) or delete_folder. The singular aspect is implied by the name and description, but not stated, so it falls short of full 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?

There is no guidance on when to use this tool versus alternatives such as delete_files or delete_folder. The description only states the basic action, leaving the agent to infer usage from the tool name alone. No exclusions or alternative recommendations are 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 provided, the description carries the full transparency burden. It discloses that files are moved to a recycle bin (not permanently deleted) and are recoverable for 30 days via web, plus the per-ID result return. This goes beyond a generic 'delete' statement, though it does not mention permission requirements or rate limits.

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 extremely concise: two short sentences. The first sentence states the core purpose and the recycle-bin behavior; the second adds operational details (one-by-one, failure isolation, per-ID results). No wasted words, and critical 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 batch deletion tool, the description covers key aspects: purpose, recycle-bin behavior, recoverability window, partial failure semantics, and return format. Without an output schema, it still explains what the agent can expect. It doesn't mention the 100-item limit in prose, but that's already in the schema, so completeness is solid.

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 already provides full coverage for the sole parameter 'file_ids', including the note that they can be obtained via list_files and a max of 100. The description adds minimal parameter-specific meaning, only reinforcing that each ID is processed individually. Baseline 3 is appropriate given the high schema coverage.

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: '批量删除文件' (batch delete files), with specific details about the operation (moving to recycle bin). It distinguishes itself from sibling tools like delete_file (singular) by emphasizing '批量' (batch) and from folder-deletion tools by specifying '文件' (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?

The description provides clear usage context: it deletes one by one, and a single failure doesn't affect the rest, which implies it's suitable for batch operations where partial resilience matters. However, it does not explicitly compare to delete_file for single deletions or state when not 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?

No annotations are provided, so the description must disclose side effects itself. It does so well by explaining that ready/locked files are soft-deleted to a recycle bin, physical OSS deletion occurs after 30 days, and users can restore within that window. This is critical safety context for a destructive 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?

The description is two concise sentences: the first states the purpose, the second discloses the soft-delete behavior. There is no redundant information, and the most important safety detail 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?

The description covers the core safety behavior (soft delete, restore window) and the schema provides the folder_not_empty error for non-recursive use. Minor gaps remain: no distinction from delete_folders sibling and no description of return/response, but for a delete tool with strong schema this is adequate.

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%: folder_path and recursive are fully documented, with recursive's description detailing empty-folder vs recursive subtree behavior. The tool description adds no parameter-specific detail beyond the schema, so the baseline 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 it deletes a folder ('删除文件夹') and uses the rmdir/rm -r analogy to convey single-folder deletion semantics. This distinguishes it from sibling tools like delete_file (file deletion) and delete_folders (plural/batch deletion), even though the latter isn't explicitly named.

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 rmdir/rm -r analogy implies when to use the recursive flag (empty vs non-empty folder), and the schema's recursive parameter adds explicit empty-folder constraints. However, there is no direct guidance on when to choose delete_folder over delete_folders for multiple folders, nor any mention of prerequisites like permissions.

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 behavioral burden. It discloses soft-deletion to a recycle bin, 30-day recovery, per-path failure independence, and return results—all valuable context for a destructive operation. It omits permission or rate-limit details, but the safety and failure behavior are well covered.

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 concise sentences, each earning its place: the first states purpose and scope, the second explains execution semantics, and the third covers data safety. No redundancy or fluff.

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 batch delete tool with 2 params and no output schema, the description covers core behavior, failure handling, return structure, and data recoverability. Schema handles parameter limits and recursive semantics. Missing minor items like prerequisites or path validation, but overall sufficient for tool selection and 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?

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no param-specific meaning beyond the schema; the recycle-bin mention is general behavioral context. 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?

Description explicitly states 'batch delete folders (batch version of delete_folder)', providing a specific verb, resource, and scope. It distinguishes from delete_folder by calling itself the batch version and from delete_files by targeting folders.

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 indicates this is the batch version of delete_folder, implying use when multiple folders need deletion. It also explains failure isolation and per-path results, giving clear context. It does not explicitly name alternatives like delete_files, but the batch/plural distinction and 'batch version of delete_folder' provide sufficient 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 full burden and does so thoroughly. It discloses content-type selection logic, rate-limiting behavior via astream_file/throttle, 15-minute URL validity, no Authorization header needed for resource links, and zero side effects (no share creation, no audit records). This is rich behavioral transparency beyond basic 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?

The description is longer than average but well-organized with bullet points and sections. The first sentence states the main purpose, and the following details on content types, rate limiting, and side effects are each valuable. Some redundancy exists (e.g., repeating 'astream_file' details), but overall it is appropriately sized for the tool's complexity.

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?

No output schema and no annotations increase the burden on the description. It covers return types, rate limiting, and side effects well, but it omits essential parameter semantics (file_id/file_uuid requirements) and error handling. The tool is complex (3 params, multiple return types), yet the description leaves a notable gap in how to specify the target file, making it incomplete for an agent.

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 only 33% (as_text has a description). The description explains as_text behavior but says nothing about file_id or file_uuid—how to specify which file to download, their relationship, or which is required. With low schema coverage, the description should compensate, but it does not address these key 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?

Description clearly states the tool downloads a file and returns it as native MCP content types, with specific branching for image, audio, text, and other types. This specific verb+resource+behavior distinguishes it from siblings like download_shared_file and file_read.

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 by explaining which content block is chosen for different file categories, but it does not explicitly state when to use this tool versus alternatives (e.g., file_read for text, download_shared_file for shared links). No exclusions or alternative references are given, so guidance is only implied.

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 burden of disclosing behavioral traits. It covers important side effects: it doesn't consume the user's storage quota and download traffic counts against the sharer. However, it doesn't mention the return format (e.g., base64 vs text), which is a notable omission.

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 short, purposeful sentences. It front-loads the core purpose and immediately gives a realistic usage scenario, with no filler or redundant information.

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 provides a clear use case and side effects, but with no output schema, it leaves out crucial return value information and error scenarios (e.g., wrong password). This gap prevents the AI agent from fully anticipating the tool's output.

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% for all three parameters, so the baseline applies. The description adds contextual meaning around share_uuid (the /s/<uuid> link) but does not elaborate on as_text or password beyond what the schema already provides.

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 action ('download file via share link') and resource (the /s/<uuid> link), and explicitly notes it works without being the file owner, distinguishing it from sibling tools like download_file. The use case is concrete and clear.

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 identifies when to use the tool: when someone sends a share link and the AI needs to read its content directly. However, it does not explicitly state when not to use it or name alternative tools, so it lacks full exclusionary 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 provided, the description carries full behavioral transparency. It discloses that binary files are not handled (and points to download_file) and that long text is truncated per max_bytes with a marker. However, it does not specify error behavior or the exact marker format, leaving some gaps.

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 long and front-loaded with the core function. The second sentence efficiently covers exclusions and parameter behavior without unnecessary detail.

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 text-file reading tool, the description covers main function, binary file exclusion, and truncation behavior. It lacks an explicit statement about the response format (e.g., raw text), but the purpose is sufficiently clear. Given the lack of an output schema and complexity, this is adequate.

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 descriptions already cover all parameters (file_id, max_bytes) with types and bounds. The tool description adds behavioral meaning to max_bytes by explaining it truncates long text and marks the result, which is not captured in the schema. This adds semantic value beyond the structured fields.

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 '直接返回文本类文件的内容' (directly returns content of text files) and lists common formats, making the tool's purpose clear. It also distinguishes itself from the sibling download_file by directing binary files there, which is strong 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 description gives clear when-to-use guidance: use for text files, avoid for binary files. It explicitly names the alternative tool: '二进制文件...请用 download_file' (for binary files use download_file), and explains the truncation behavior for long text via max_bytes.

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 only states '查询' (query), implying read-only behavior, but does not disclose additional traits such as permissions, error handling, or side effects. This is a minimal disclosure that adds little beyond the tool's name.

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 front-loads the action and includes the crucial parameter condition. Every part is essential and there is no 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?

For a simple query tool with only two parameters and no output schema, the description covers the core purpose and parameter constraint. However, it lacks details on return format, error conditions, or authorization requirements, which would be useful given the absence of annotations and an output schema. It is adequate but leaves some gaps for the agent to infer.

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 already provides descriptions for both parameters (100% coverage), so the baseline is 3. The description adds value by clarifying the relationship between file_id and file_uuid ('提供其一即可' - one of them suffices), suggesting they are alternative identifiers rather than both being required. This goes beyond the schema's individual descriptions, though it does not specify behavior if both are provided or if neither is provided.

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 ('查询单个文件详情' - query single file details) and specifies the resource (single file). The word '单个' (single) distinguishes it from sibling tools like list_files, and the purpose is specific and unambiguous.

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 when needing details of a specific file, especially noting that either file_id or file_uuid is sufficient. However, it does not explicitly mention alternatives or when not to use this tool, leaving the agent to infer the appropriate context from the sibling 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 return format (root_path, tree, stats with folders/file count and truncated flag), which implies truncation behavior and provides useful context for the agent. It does not explicitly state it is a read-only operation, but 'returns' implies that. The stats field with 'truncated' is a meaningful behavioral trait beyond a simple list.

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 concise, front-loaded with the primary purpose, and includes a compact return example. Every sentence earns its place: the purpose, a usage recommendation, and the return schema. The code block is brief and informative, with no fluff.

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 there is no output schema, the description compensates by providing a concrete return structure (root_path, tree, stats) and truncation semantics. With 4 parameters all documented in the schema, and a clear usage hint, the description is complete enough for an agent to select and invoke 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?

The schema description coverage is 100%, so the baseline is 3 per the rubric. The description adds no parameter-specific details, but the schema already fully documents each parameter (max_depth, max_nodes, folder_path, include_files) with clear explanations. Therefore, the description does not need to compensate, and a 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 tool returns the user's folder/file hierarchy as an ASCII tree diagram, with a specific verb (returns), resource (folder/file hierarchy), and form (ASCII tree). It also includes a recommendation for when to use it ('when the user asks about directory structure'), which distinguishes it from sibling tools like list_files and list_folders.

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 recommends using this tool when the user asks about 'directory structure', providing clear when-to-use context. However, it does not name alternatives or explicitly state when not to use it, so it stops short of a full 5. The sibling names imply alternatives, but the description itself lacks 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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It indicates a read-only inspection of quota usage, but does not mention whether authentication is required, what specific data is returned (e.g., used vs. total), or possible error conditions. This is minimal disclosure 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, concise sentence in Chinese that states the tool's purpose without extraneous words. It is fully front-loaded with the key information 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?

For a zero-parameter quota lookup, the description adequately explains the tool's purpose and implies a return value of quota usage. However, since there is no output schema, it would be more complete if it specified whether the result includes total quota, used space, or both. That said, the level of detail is sufficient for this simple getter 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 zero parameters, so the baseline is 4. The description does not need to add parameter details because there are none, and it appropriately leaves the parameter section empty.

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 the verb '查看' (view) and specifies the resource '当前用户的存储配额使用情况' (current user's storage quota usage), clearly stating what the tool does. It is distinct from sibling tools, which focus on file operations, sharing, and uploads, making the purpose unambiguous.

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 the tool is to be used when checking the current user's storage quota. No sibling tool performs this function, so there are no alternatives to exclude. The context is clear, though it lacks an explicit 'when to use' statement or exclusion criteria.

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 fully discloses key behavioral traits: server-side byte-stream copy, quota/whitelist/instant-upload checks, no bandwidth consumption, traffic charged to sharer and storage to importer. This exceeds minimal safety disclosure.

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 concise paragraphs: purpose first, then behavioral details. Every sentence adds value, 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?

Given no output schema or annotations, the description adequately explains the operation, side effects, and quota/traffic impact. It could mention return value but that's optional for a side-effect operation.

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 covers both parameters with descriptions (UUID and optional password), so baseline 3 applies. The description adds no parameter-specific detail beyond 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 imports a shared file into the current user's file list, using a specific verb and resource. It distinguishes from siblings like download_shared_file by explaining it's a server-side copy equivalent to download-then-upload.

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 explains the context (importing shared files) and contrasts with a local download-then-upload workflow, but doesn't explicitly name alternative tools or specify when not 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?

No annotations exist, so the description carries the burden. It discloses default recursive traversal, return fields (subfolders, has_subfolders), and folder_path to avoid ambiguity from recursion. It does not mention pagination or auth, but for a read-only list operation the disclosed behaviors are substantial.

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 tightly scoped sentences: the first states the core action, the second covers return hints and a sibling alternative, the third resolves a subtle ambiguity (same-name files). No fluff; every sentence contributes directly to tool usage.

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 6-parameter recursive list tool with no output schema, the description explains the key behaviors (recursion, hierarchy hints, folder_path disambiguation) and gives sibling guidance. It omits page/size semantics and return pagination shape, but the given details are sufficient for most use cases.

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 already covers recursive, search, category, and folder_path with descriptions. The description adds context for recursive default behavior and the folder_path output field, but page and size remain undocumented and are not addressed. With 67% schema coverage, this is adequate but not enriched.

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?

Description opens with '列出当前用户的文件' (list current user's files), clearly specifying the action and resource. It further differentiates from sibling tools by noting the default recursive behavior and explicitly pointing to get_folder_tree for tree-shaped queries, which distinguishes it from related list/search 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?

Explicit when-to-use guidance is present: '若用户问“目录结构 / 树”, 直接调 get_folder_tree' and the recursive parameter note '用户问“都有什么文件”时一律保持 True'. Also advises using list_folders for path discovery, covering both alternatives and prerequisites.

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 error behavior (throws folder_not_found) and the fact that only directories are listed. It does not mention return format or sorting, but for a simple list operation this is reasonable additional context beyond what the schema provides.

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 extremely concise, using two short sentences with a useful analogy and a clear pointer to a sibling tool. Every sentence earns its place, and the front-loaded purpose is immediately understandable.

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 list tool with no output schema, the description covers the core behavior (listing folders), error handling, and alternative usage. It does not explicitly describe the return format, but the `ls -d` analogy implies a list of directory names/paths, making it sufficiently complete for an agent to invoke 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 schema already documents both parameters (recursive, folder_path) with full descriptions. The tool description adds no parameter-specific meaning beyond the `ls -d` analogy, which is already implied by the schema. 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?

The description clearly states the tool lists folders ("列出文件夹") and uses the `ls -d` analogy to convey it shows only directories. It explicitly distinguishes itself from list_files, making the purpose unambiguous relative to siblings.

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 guidance: use this tool for listing folders, and use list_files for listing files ("要列文件用 list_files"). It also mentions the error condition (folder_not_found) when the path doesn't exist, giving clear operational context.

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 transparency burden. It explicitly discloses a key behavioral trait: the OSS bytes remain unchanged, only the logical path changes, and the operation completes in milliseconds. This goes beyond simply saying 'move' and provides valuable insight into the operation's nature, though it omits details like permissions or failure modes.

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. The first sentence states the action and provides a helpful Unix analogy; the second adds a high-value behavioral note. No extraneous words are present, and the purpose 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 move operation, the description and schema together cover the essential context: what it does, the key behavioral distinction (logical vs. physical move), and all parameter definitions. It lacks explicit error handling or return-value descriptions, but these are not required given no output schema and the straightforward nature of the 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% coverage with clear descriptions for all three parameters: file_id, target_folder_path, and auto_create_folders. The description itself does not add parameter-specific details, which is acceptable given the schema's thoroughness, so the baseline score 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 clearly states the tool's function: moving a file to a specified folder, with an explicit analogy to Unix `mv`. It distinguishes the tool from siblings like `move_folder` and `rename_folder` by specifying it operates on files, and the logical-path detail further clarifies its 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 Unix `mv` analogy implies the tool is for moving files between directories, and the mention of 'logical path' suggests a fast, metadata-only operation. However, it does not explicitly compare to alternatives like `move_folder` or state when not to use it, so usage guidance remains implied rather than 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?

With no annotations, the description carries the full burden. It discloses two critical behaviors: recursive logical path updates for all descendants and that OSS bytes remain unchanged. This goes beyond a bare 'move' statement and provides meaningful insight into the tool's side effects, though it omits details about permissions, atomicity, or return values.

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 lines, starting with a verb and clear object, and includes a compact code example. Every sentence conveys essential information without redundancy; the recursive path detail and OSS byte note are valuable and efficiently phrased.

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 moderate complexity without annotations or output schema, the description covers the core semantic (logical move) and a key side-effect (recursive path updates), which is sufficient for invocation. It does not describe return values or failure modes, but this is not critical for a move operation with well-documented parameters.

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% and each parameter has a thorough description, including the root path convention and the rename alternative. The main description adds a concrete example but does not enrich parameter meaning 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 clearly states the tool moves an entire folder, using a concrete shell analogy (`mv /工作/项目A /归档/`). It distinctly targets folder-level operations, differentiating from file moves and rename operations by naming the latter explicitly in the schema.

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 schema description for target_parent_path explicitly directs users to use rename_folder when a rename is also needed, providing a clear alternative. However, it does not explicitly state when to use move_file instead of this tool, though the operation's scope is implied by the folder-specific language.

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 only reveals that the parent folder is not moved, which is a useful trait, but it omits critical behavioral details such as failure conditions (e.g., name conflicts), permission requirements, reversibility, and return values. This is insufficient for a mutation tool.

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 extremely concise, consisting of a single short phrase. It is front-loaded and contains no unnecessary words. While it is appropriately compact for the tool's apparent simplicity, it is so brief that it borders on under-specification, but the conciseness criterion rewards efficiency, so a 4 is given.

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 lack of annotations and output schema, the description must provide sufficient context for the agent. It only states 'does not move parent', which is minimal. It does not explain what the tool returns, how errors are handled, or why one would use this over move_folder. The schema covers parameter definitions but not the broader operational context, leaving the description 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?

The schema provides 100% parameter description coverage for both folder_path and new_name. The description adds no parameter-level detail beyond what the schema already contains, so the baseline score of 3 is appropriate. It neither enhances nor detracts from the schema's clarity.

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 '改名 (不动 parent)' clearly identifies the action as rename and the resource as a folder (implied by the tool name). The phrase '不动 parent' distinguishes it from move_folder, which is a sibling tool. However, it does not explicitly state that the target is a folder or that the operation is on a folder name, relying somewhat on the tool name.

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 hints that this tool only renames and does not move the parent, implying that if relocation is needed, another tool (like move_folder) should be used. This is an implied usage guideline, not an explicit one. It does not name alternatives or provide clear when-to-use/when-not-to-use criteria, so it falls short of a 4.

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. It discloses that the tool only scrapes and formats, does not generate content, and enforces a public-only restriction. This goes beyond a minimal description, though it omits details like authentication or error behavior.

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: the first states the core function and output, the second adds key constraints. No wasted words, and the most important 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?

Considering the tool has no output schema and no annotations, the description adequately covers the main purpose, return output (clean Markdown), and important constraints. It could explicitly describe the return structure in more detail, but for a simple three-parameter tool, this 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?

The input schema documents all three parameters with detailed descriptions (100% coverage). The description reinforces the URL restriction but adds no new parameter-level meaning beyond what the schema already provides, 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 verb+resource: scrapes a public webpage and returns clean Markdown. It also specifies the intended use for AI reading/summarization/extraction. This distinguishes it from sibling file-management 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?

The description provides clear context on when to use the tool (for reading public webpages) and includes an explicit restriction (only public pages, no internal/reserved addresses). It does not explicitly name alternatives, but the sibling tools are clearly unrelated file operations, making the usage context sufficient.

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, but it only mentions the scope of the search. It does not describe what the search matches, what the response looks like, whether it is read-only, or any limits or errors.

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, front-loaded sentence with no wasted words. It is concise and scannable, though it sacrifices valuable behavioral detail for brevity.

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 lack of annotations and output schema, the description is too sparse to fully support correct invocation. It fails to explain return values, search behavior, or result ordering and pagination, making it only minimally useful for an agent deciding how to use the 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 schema covers only 50% of parameters with descriptions (query), and the description adds no parameter-level meaning. The limit parameter is left to its schema constraints, and there is no compensation for the missing semantics in the 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 a specific action ('search') and a clear resource scope ('all files of current user'). This distinguishes it from listing tools like list_files, though it does not explicitly clarify whether the search covers file content or only metadata.

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?

There is no guidance on when to use this tool versus alternatives such as list_files or get_folder_tree. The description only implies the obvious case of needing to search, with no exclusions, prerequisites, or alternative recommendations.

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 takes on the full burden of behavioral disclosure. It reveals key traits: concurrent calls are allowed, the backend tracks uploaded indices, and retrying the same chunk_index is safe due to idempotent temporary writes. This goes beyond basic operation description, though it omits authentication requirements and error behaviors.

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 extremely concise: a single lead line identifying the step, followed by two short sentences covering concurrency, backend state, and idempotency. Every sentence carries unique value, with no redundancy or filler. The structure front-loads the most critical purpose information.

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 effectively covers the essential context for a chunked upload step: its place in the workflow, concurrency behavior, retry semantics, and server-side idempotency. While there is no output schema and the description doesn't mention return values, this step is simple enough (upload one chunk) that the provided details are sufficient for an agent to invoke it 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 description coverage is 100% for all 3 parameters, so the schema fully documents each parameter's type, constraints, and meaning. The description adds no additional parameter semantics—it only reinforces the retry safety for chunk_index, which is already implied by the schema's 0-based index. 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 specifies '上传单个分片' (upload a single chunk) and places it as '第 2 步 / 共 3 步' (step 2 of 3), clearly defining the verb, resource, and its position in a multi-step process. This distinguishes it from sibling tools like upload_init and upload_complete, making the purpose unambiguous.

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 clearly states this is step 2 of a 3-step process, implying usage after upload_init and before upload_complete. It also provides explicit guidance on concurrency and retry safety ('可并发调用', '网络抖动重试同一 chunk_index 安全'), which tells the agent when and how to reuse the tool. However, it does not explicitly mention alternatives or when not 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, the description carries the full burden of behavioral disclosure. It states that direct mode calls OSS CompleteMultipartUpload server-side and avoids ECS memory/bandwidth, while relay mode merges temp chunks. It also lists the returned file metadata fields. Missing details like error handling or prerequisites, but the core behavioral traits are transparent.

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 well organized: a one-line purpose statement followed by two bulleted path options and a return-value note. Every sentence contributes essential information, with no 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 the tool's moderate complexity (two modes, no output schema), the description adequately covers the operation, the two implementation paths, and the return metadata. It omits error scenarios and explicit prerequisites, but the 'step 3 of 3' context plus fully described schema parameters fill most gaps. Overall, sufficient for 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?

Schema description coverage is 100% for both parameters: 'parts' and 'session_uuid' are fully defined in the input schema, including ETag format and the two modes. The tool description merely echoes this information without adding new semantic nuance, so it stays at the baseline of 3.

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 opens with '合并所有分片 (第 3 步 / 共 3 步)', which clearly identifies the verb (merge) and resource (all shards) and positions it as the final multipart upload step. It then contrasts the two merging paths (direct vs relay) and states the returned metadata, making it distinct from sibling tools like upload_init and upload_chunk.

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 explains when to include 'parts' (direct OSS mode) versus omitting them (relay mode), and recommends the direct path for shim. It implies usage after upload_init and upload_chunk via '第 3 步 / 共 3 步', but it does not explicitly list exclusions such as 'for small files use upload_file'.

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 discloses important side effects: upload consumes paid storage quota and deducts credit. It also reveals the underlying init/chunk/complete mechanism and the 20MB limit. It doesn't cover return value or overwrite behavior, but core behavioral context is well covered.

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 well-structured with bullet points and front-loads the primary action. It is concise and avoids redundancy, though the final '新增 folder_path:' reads like a changelog artifact rather than polished documentation, slightly reducing clarity.

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 and no annotations, the description covers essential context: when to call, cost implications, size limits, and integration with chunking flows. It omits explicit return-value details and MIME type handling, but for a file upload tool with rich sibling context, this is reasonably 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 coverage is high (80%), so the baseline is 3. The description adds value by stating the 20MB suitability constraint and reaffirming folder_path's default of '/', which complements the schema. It doesn't add detail for mime_type, but the overall parameter context is adequate.

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: uploading a base64-encoded file to the user's transfer station. It also distinguishes itself from sibling chunking tools by explaining it wraps init + single chunk + complete, and defers large files to web-based chunked upload.

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 explicit when-to-use and when-not-to-use guidance: only call when the user explicitly requests storage/transfer/sharing, and avoid uploading intermediate results, logs, or temp files. It also adds size-based guidance (<20MB vs web upload), making alternatives clear.

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. It explicitly explains the two return modes (instant vs. non-instant) and the necessary next calls, providing useful lifecycle context beyond a simple tool description.

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 extremely concise and front-loaded with the purpose. Bullet points for return modes make the structure clear without any waste.

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 the essential return values and the multi-step flow, which is crucial since there is no output schema. It lacks explicit mention of error handling or prerequisites, but for a step-initialization tool, the provided context is sufficient for correct 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 83%, so parameters are already well-documented. The tool description adds no additional parameter meaning, matching the baseline for high schema coverage.

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 initiates a chunked upload session and is step 1 of 3. This specific verb+resource distinction separates it from siblings like upload_chunk and upload_complete.

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 as the first step in a chunked upload flow and explains the subsequent steps, but it does not explicitly compare with alternatives like upload_file or state when chunked upload is preferred.

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 disclosing behavior. It explicitly mentions limits (50 files / 200MB), auto-renaming for duplicate names, and the temporary 15-minute download URL, which are useful behavioral details beyond the schema. It does not cover all edge cases (e.g., error handling), but it is more transparent than typical.

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: the first sentence states the primary action and outcome, while the second provides constraints. Every sentence adds value, with 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?

For a simple 2-parameter tool with no output schema, the description is complete. It explains what the tool does, how the result is returned (a 15-min URL), and the key constraints. An agent can confidently invoke it without ambiguity.

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%: both file_ids and zip_name have descriptions, so the description adds minimal new parameter-level details. It does add the auto-renaming behavior for files with the same name, which is a minor semantic enhancement, but essentially the schema already handles parameter explanations.

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: it packages multiple files into a ZIP, stores it in the transfer station, and returns a 15-minute download URL. This is a specific verb-object pairing that distinguishes it from sibling tools like download_file or create_share_link.

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 its usage context: when you need to bundle multiple files into a single ZIP for temporary download. It does not explicitly name alternatives or exclusions, but the context is clear enough. Sibling tools are all file operations, making the ZIP-specific purpose apparent.

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