Server Quality Checklist

Tool Scores

• create_bucketC
  2/5.0
  Behavior1/5

  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 states the action ('create') without any details on permissions required, whether the operation is idempotent, error conditions (e.g., duplicate bucket names), rate limits, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise with a single phrase ('创建存储桶'), which is front-loaded and wastes no words. However, this conciseness comes at the cost of completeness, but based solely on brevity and structure, it earns full marks.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity of a creation tool with no annotations and no output schema, the description is severely incomplete. It lacks essential context such as what the tool returns, error handling, dependencies on other tools (e.g., 'connect_minio'), and behavioral traits. This makes it inadequate for safe and effective use by an AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100%, with clear descriptions for both parameters ('bucketName' and optional 'region'). The description adds no additional meaning beyond what the schema provides, such as format constraints or examples. Given the high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '创建存储桶' (Create storage bucket) restates the tool name 'create_bucket' in Chinese, making it essentially tautological. While it indicates a creation action and resource type, it doesn't specify what distinguishes this from other bucket-related tools like 'set_bucket_policy' or 'delete_bucket' beyond the basic verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a connection via 'connect_minio'), exclusions (e.g., not for existing buckets), or comparisons with sibling tools like 'list_buckets' or 'bucket_exists'.

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

• get_bucket_policyC
  2/5.0
  Behavior1/5

  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 provides none. It doesn't indicate whether this is a read-only operation (though implied by 'get'), what permissions are required, whether it returns an error for non-existent buckets, what format the policy is returned in, or any rate limits. For a tool that presumably interacts with storage infrastructure, this lack of behavioral context is a significant gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise at just four Chinese characters. While this represents under-specification rather than ideal conciseness, according to the scoring framework, 'conciseness' evaluates whether the description is appropriately sized and front-loaded. This single phrase contains no wasted words and immediately states the core function, earning full marks on this dimension despite its overall inadequacy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity of storage bucket operations and the complete absence of annotations and output schema, the description is woefully incomplete. It doesn't explain what a bucket policy is, what format it returns, error conditions, authentication requirements, or how this tool relates to the many sibling tools. For a tool that presumably returns security/access configuration data, this minimal description leaves the agent with insufficient context to use it effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100% with a single parameter 'bucketName' documented as '存储桶名称' (bucket name). The description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter details in the description, which applies here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '获取存储桶策略' (Get bucket policy) is a tautology that essentially restates the tool name 'get_bucket_policy' in Chinese. While it does specify the verb ('get') and resource ('bucket policy'), it doesn't provide any additional context about what a bucket policy is or what this operation specifically retrieves. It fails to distinguish this tool from its sibling 'set_bucket_policy' beyond the obvious verb difference.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (like needing an existing bucket), no comparison to sibling tools like 'bucket_exists' or 'get_object_info', and no indication of what scenarios would call for retrieving a bucket policy versus other bucket operations. The agent receives zero contextual guidance.

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

• set_bucket_policyC
  2/5.0
  Behavior1/5

  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. The description only states the action ('set bucket policy') without any information about permissions required, whether this is a destructive/mutative operation, potential side effects, error conditions, or what happens if a policy already exists. This is inadequate for a tool that modifies system state.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise - a single phrase in Chinese that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. However, this conciseness comes at the cost of completeness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool that modifies bucket policies (a potentially destructive operation) with no annotations and no output schema, the description is completely inadequate. It doesn't explain what a bucket policy is, what the operation does, what permissions are needed, what format the policy should be in, or what to expect as a result. The agent would have insufficient information to use this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage with clear parameter documentation in Chinese, so the baseline score is 3. The tool description adds no additional parameter information beyond what's already in the schema (e.g., no examples of policy JSON format, no constraints on bucket names).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '设置存储桶策略' (Set bucket policy) is a tautology that essentially restates the tool name in Chinese. While it indicates the verb 'set' and resource 'bucket policy', it lacks specificity about what setting a bucket policy entails and doesn't distinguish this tool from sibling tools like 'get_bucket_policy' or 'delete_bucket_policy' beyond the basic action verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There are no mentions of prerequisites (e.g., bucket must exist), when-not-to-use scenarios, or comparisons to sibling tools like 'get_bucket_policy' or 'delete_bucket_policy'. This leaves the agent with no context for tool selection.

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

• generate_presigned_urlC
  2.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It doesn't disclose that this generates a time-limited URL for object operations (GET, PUT, DELETE), which is a key behavioral trait. It misses details like authentication needs (likely requires permissions) or that the URL expires. The description is too minimal for a mutation-related tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single phrase, which is concise but under-specified. It's front-loaded but lacks necessary detail, making it inefficient rather than appropriately sized. It doesn't earn its place with useful information beyond the name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no annotations, no output schema, and a tool that generates URLs (implying mutation or access control), the description is incomplete. It should explain the tool's role in temporary access, return value format, or security implications. It fails to compensate for the lack of structured data.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond the schema, such as explaining how 'method' affects URL usage or what 'expires' implies for security. Baseline is 3 since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '生成预签名URL' (Generate presigned URL) restates the tool name in Chinese without specifying what a presigned URL is or what it does. It doesn't distinguish this tool from sibling tools like 'get_object_info' or 'download_file', which might also involve object access. The purpose is vague rather than specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that presigned URLs are for temporary access, or contrast it with tools like 'download_file' for direct downloads or 'get_object_info' for metadata. There's no context for when this is appropriate.

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

• get_object_infoC
  2.1/5.0
  Behavior2/5

  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 offers minimal information. It implies a read-only operation ('get'), but doesn't specify whether it requires authentication, returns metadata or content, has rate limits, or what happens if the object doesn't exist. For a tool with no annotation coverage, this is inadequate, though it doesn't contradict any annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise (three Chinese characters), but this brevity comes at the cost of under-specification rather than efficiency. It's front-loaded but lacks necessary detail, making it feel incomplete rather than optimally structured. While not verbose, it fails to provide value beyond the tool name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (2 required parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what information is returned (e.g., metadata, size, last modified), error conditions, or how it fits with sibling tools like 'list_objects'. With no annotations or output schema, the description should compensate with more behavioral and usage context, which it lacks.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage (both parameters are documented in Chinese), so the baseline score is 3. The description adds no additional parameter semantics beyond what the schema provides—it doesn't explain format expectations, constraints, or relationships between 'bucketName' and 'objectName'. The schema alone handles the parameter documentation adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '获取对象信息' (Get object information) is a tautology that essentially restates the tool name 'get_object_info' in Chinese. While it indicates the tool retrieves information about an object, it doesn't specify what type of information (metadata, properties, details) or distinguish it from sibling tools like 'list_objects' or 'download_file' that also involve object information. The purpose is vague without additional context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a connected MinIO instance), differentiate from similar tools like 'list_objects' (which lists multiple objects) or 'download_file' (which retrieves content), or specify use cases (e.g., checking object metadata before operations). This leaves the agent without context for tool selection.

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

• copy_objectC
  2.3/5.0
  Behavior2/5

  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. '复制对象' implies a write operation (creating a copy), but it doesn't specify whether this requires specific permissions, overwrites existing destination objects, handles large files, or has rate limits. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits undocumented.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise—just two characters in Chinese—and front-loaded with the core action. There is no wasted verbiage or unnecessary elaboration, making it efficient for quick scanning, though this brevity contributes to gaps in other dimensions.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't clarify the tool's role among siblings (e.g., vs. 'upload_file'), explain behavioral implications (like idempotency or error handling), or provide usage context. The high schema coverage helps, but the description alone is insufficient for safe and effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, with all four parameters clearly documented in Chinese (e.g., sourceBucket as '源存储桶名称'). The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters (e.g., that source and destination can be the same bucket for renaming). Given the high schema coverage, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '复制对象' (copy object) is a tautology that essentially restates the tool name 'copy_object' in Chinese. While it indicates the action (copy) and resource (object), it lacks specificity about what type of object is being copied (e.g., files in storage buckets) and doesn't distinguish this tool from potential siblings like 'upload_file' or 'download_file' that also involve object manipulation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing existing source/destination buckets), exclusions, or comparisons to sibling tools like 'upload_file' (for uploading new objects) or 'download_file' (for retrieving objects). Without such context, an agent must infer usage solely from the tool name and parameters.

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

• get_storage_statsC
  2.4/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden but only states the action without behavioral details. It doesn't disclose if this is a read-only operation, requires authentication, has rate limits, returns aggregate or per-bucket stats, or any other traits beyond the basic purpose.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient phrase in Chinese that directly states the purpose without waste. It's appropriately sized and front-loaded, though its brevity contributes to gaps in other dimensions.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no annotations, no output schema, and a simple tool with 0 parameters, the description is incomplete. It doesn't explain what statistics are returned (e.g., numeric data, JSON structure) or how it fits into the MinIO context, making it inadequate for reliable agent use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, but that's acceptable here; baseline is 4 for zero parameters as it avoids unnecessary details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '获取存储统计信息' (Get storage statistics) restates the tool name 'get_storage_stats' with minimal elaboration, making it a tautology. It doesn't specify what kind of storage statistics (e.g., MinIO bucket usage, object counts, total size) or distinguish it from sibling tools like 'list_buckets' or 'get_object_info'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention context (e.g., monitoring storage usage, checking capacity) or exclusions, leaving the agent to guess based on the name alone among many storage-related siblings.

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

• download_filesC
  2.6/5.0
  Behavior2/5

  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 states the action ('download') but doesn't describe side effects (e.g., whether it overwrites local files, requires authentication, or has rate limits), output format, or error handling. For a batch operation with potential local system impact, this is a significant gap in transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single phrase ('批量下载文件'), which is concise and front-loaded. However, it's overly terse, lacking necessary details for a batch download tool. While efficient, it under-specifies, slightly reducing its effectiveness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity of a batch download tool with no annotations and no output schema, the description is incomplete. It doesn't address critical aspects like what the tool returns (e.g., success/failure status), error conditions, or dependencies on other tools (e.g., 'connect_minio'). For a tool that interacts with storage and local systems, more context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with clear descriptions for 'bucketName' and 'files' (including nested 'objectName' and 'localPath'). The description adds no additional meaning beyond the schema, such as explaining parameter relationships or constraints. Baseline 3 is appropriate since the schema adequately documents parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '批量下载文件' (batch download files) states the basic action but is vague about scope and resources. It doesn't specify from where files are downloaded (e.g., from a storage bucket) or distinguish it from sibling 'download_file' (singular). The description lacks specificity about the target system or context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a connected MinIO instance), compare it to 'download_file' for single files, or specify use cases like batch processing. Without such context, an agent must infer usage from the tool name and schema alone.

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

• upload_filesC
  2.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. '批量上传文件' indicates a write operation but doesn't disclose behavioral traits like permissions needed, whether it overwrites existing files, error handling for partial failures, rate limits, or response format. This is a significant gap for a mutation tool with zero annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Extremely concise with just four characters ('批量上传文件'), front-loaded with the core action. However, it's arguably too brief, bordering on under-specified rather than efficiently informative, but within the context it's not wasteful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no annotations, no output schema, and a mutation tool with batch operations, the description is incomplete. It lacks details on behavior, error handling, and integration with sibling tools, making it inadequate for safe and effective use by an AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents parameters (bucketName, files array with localPath, objectName, metadata). The description adds no meaning beyond the schema—it doesn't explain parameter relationships, constraints, or usage examples. Baseline 3 is appropriate when schema does all the work.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '批量上传文件' (batch upload files) states a clear verb ('upload') and resource ('files'), but it's vague about the destination and doesn't distinguish from sibling 'upload_file'. It specifies 'batch' which differentiates it from the single-file sibling, but lacks details on the storage system or context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives like 'upload_file' (for single files) or other storage operations. The description implies batch processing but doesn't mention prerequisites, constraints, or typical scenarios for choosing batch over single upload.

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

• delete_bucketC
  2.7/5.0
  Behavior2/5

  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. '删除存储桶' implies a destructive, irreversible mutation, but it doesn't specify critical behaviors: whether deletion requires specific permissions, if the bucket must be empty first, what happens on success/failure, or any rate limits. For a high-risk tool with zero annotation coverage, this is a significant gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single phrase ('删除存储桶') that directly states the action and resource with zero wasted words. It is appropriately sized for a simple operation and front-loaded, though its brevity contributes to gaps in other dimensions. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (destructive mutation), lack of annotations, and no output schema, the description is incomplete. It fails to address key contextual aspects: behavioral risks, prerequisites, error handling, or output expectations. For a tool that permanently deletes resources, this minimal description is inadequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with the single parameter 'bucketName' documented as '存储桶名称' (storage bucket name). The description adds no additional meaning beyond the schema, such as format constraints (e.g., naming rules) or examples. With high schema coverage, the baseline is 3, as the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '删除存储桶' (delete storage bucket) states the verb and resource, making the basic purpose clear. However, it doesn't distinguish this tool from similar destructive operations like delete_bucket_policy, delete_object, or delete_objects, which all involve deletion but target different resources. The purpose is understandable but lacks sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., bucket must exist, be empty), exclusions (e.g., cannot delete if policies exist), or comparisons to siblings like delete_bucket_policy or delete_objects. The agent must infer usage from the name alone, which is insufficient for a destructive operation.

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

• bucket_existsC
  2.9/5.0
  Behavior2/5

  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 states the tool checks existence but doesn't describe what 'exists' means (e.g., permissions, accessibility), the return format (e.g., boolean, error on not found), or any side effects (e.g., rate limits, authentication needs). For a read operation with no annotation coverage, this is a significant gap in transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence ('检查存储桶是否存在') that directly states the tool's purpose with zero waste. It is front-loaded and appropriately sized for a simple tool, earning its place without unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, no output schema, no annotations), the description is incomplete. It doesn't explain the return value (e.g., boolean, error message), behavioral nuances like error handling, or how it differs from similar tools. For a tool with no output schema and minimal context, more detail is needed to be fully helpful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, with 'bucketName' documented as '存储桶名称' (bucket name). The description adds no additional meaning beyond this, such as format constraints or examples. With high schema coverage, the baseline is 3, as the schema already provides adequate parameter semantics without extra value from the description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '检查存储桶是否存在' clearly states the tool's purpose as checking if a storage bucket exists, using a specific verb ('检查' - check) and resource ('存储桶' - storage bucket). It distinguishes from siblings like 'create_bucket' (creates) and 'list_buckets' (lists all), but doesn't explicitly differentiate from tools like 'get_object_info' which might also check existence indirectly. The purpose is unambiguous but could be more specific about scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_buckets' (lists all buckets) and 'get_object_info' (checks object existence), there's no indication of when this tool is preferred—e.g., for quick existence checks without listing all buckets or before operations like 'delete_bucket'. The lack of context leaves usage unclear.

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

• connect_minioC
  2.9/5.0
  Behavior2/5

  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 states the tool connects to a server but doesn't describe what this entails—whether it establishes a session, validates credentials, returns a connection handle, or has side effects like authentication. For a connection tool with zero annotation coverage, this leaves critical behavioral traits unspecified.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence ('连接到MinIO服务器') that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word contributing to clarity. No fluff or redundancy is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity of a connection tool (6 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what the tool returns (e.g., a connection object, status), error conditions, or how it integrates with sibling tools. For a foundational operation like server connection, more context is needed to guide effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all parameters documented in the schema (e.g., endPoint, port, useSSL, accessKey, secretKey, region). The description adds no additional parameter semantics beyond what's in the schema. According to the rules, when coverage is high (>80%), the baseline score is 3 even without param info in the description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '连接到MinIO服务器' (Connect to MinIO server) clearly states the tool's purpose as establishing a connection to a MinIO server. It uses a specific verb ('连接到' - connect to) and resource ('MinIO服务器' - MinIO server), making the action clear. However, it doesn't differentiate from sibling tools, which are all MinIO operations but focus on different actions like bucket/object management rather than connection establishment.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., this must be called before other MinIO operations), exclusions, or relationships to sibling tools like bucket_exists or upload_file. Without such context, users must infer usage from the tool name alone.

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

• delete_bucket_policyC
  2.9/5.0
  Behavior2/5

  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 states the action is a deletion, implying a destructive mutation, but doesn't clarify critical aspects: whether this is irreversible, what permissions are required, if it affects bucket functionality, or what happens on success/failure (e.g., returns confirmation or error). For a destructive tool with zero annotation coverage, this is a significant gap in safety and operational context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single phrase ('删除存储桶策略'), which is extremely concise and front-loaded with the core action. There is no wasted verbiage or redundancy, making it efficient for quick comprehension. Every word earns its place by directly conveying the tool's purpose without unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (destructive mutation), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral risks, success criteria, or error handling, which are crucial for safe invocation. While the purpose is clear, the absence of guidance and transparency makes it inadequate for a tool that permanently removes access controls, leaving the agent under-informed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, with 'bucketName' documented as '存储桶名称' (bucket name). The description adds no additional parameter semantics beyond this—it doesn't explain format constraints, examples, or how the bucket name relates to the policy deletion. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema already provides adequate parameter documentation without extra value from the description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '删除存储桶策略' (Delete bucket policy) clearly states the action (delete) and target resource (bucket policy), making the purpose immediately understandable. It distinguishes from siblings like 'delete_bucket' (deletes the bucket itself) and 'set_bucket_policy' (sets policy). However, it doesn't specify what a 'bucket policy' entails (e.g., access controls), which keeps it from a perfect score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., bucket must exist, policy must be set first), when not to use it (e.g., if you need to modify rather than delete), or refer to sibling tools like 'get_bucket_policy' to check current policy or 'set_bucket_policy' as an alternative. This leaves the agent with minimal context for decision-making.

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

• delete_objectC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose that this is a destructive operation (implied but not explicit), whether it requires specific permissions, what happens on success/failure, or if deletions are permanent/reversible. For a mutation tool with zero annotation coverage, this is inadequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and target, making it highly efficient and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'delete' entails (permanent removal?), error conditions, return values, or how it differs from 'delete_objects'. Given the complexity and risk of object deletion, more context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters 'bucketName' and 'objectName' are fully documented in the schema. The description doesn't add any semantic context beyond what the schema provides (e.g., format examples, constraints), meeting the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '删除存储桶中的对象' clearly states the action (delete) and target (object in a bucket), making the purpose immediately understandable. However, it doesn't differentiate from sibling 'delete_objects' (plural), which suggests this tool handles single-object deletion versus batch deletion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like 'delete_objects' or 'delete_bucket'. There's no mention of prerequisites (e.g., bucket must exist), exclusions, or comparative context with sibling tools.

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

• delete_objectsC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. While '删除' (delete) clearly indicates a destructive operation, it doesn't specify whether deletions are permanent/reversible, what permissions are required, rate limits, or what happens with partial failures. The batch nature is mentioned but without details about atomicity or error handling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient Chinese sentence that communicates the core functionality without waste. It's appropriately sized for a tool with clear parameters and no complex behavioral nuances needing explanation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive batch operation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns (success/failure indicators, error messages), doesn't warn about irreversible data loss, and provides no context about the MinIO storage system evident from sibling tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain format constraints, size limits for the objectNames array, or special characters in bucket/object names. Baseline 3 is appropriate when schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('批量删除' - batch delete) and target ('存储桶中的对象' - objects in a storage bucket). It distinguishes from the sibling 'delete_object' (singular) by specifying batch operation. However, it doesn't explicitly mention the storage system context (MinIO) that's implied by the sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like 'delete_object' (for single objects) or 'delete_bucket' (for entire buckets). It doesn't mention prerequisites (e.g., bucket must exist), error conditions, or typical use cases for batch deletion.

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

• download_fileC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states it downloads a file but doesn't mention important behaviors like whether it overwrites existing local files, requires authentication, handles errors, or has rate limits. For a file operation tool with zero annotation coverage, this leaves significant gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence in Chinese that directly states the tool's purpose. There's no wasted verbiage or unnecessary elaboration - it's appropriately concise for a straightforward download operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given this is a file operation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens on success/failure, whether files are overwritten, authentication requirements, or return values. For a tool that modifies the local filesystem, more behavioral context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any additional meaning about the parameters beyond what's already in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '从存储桶下载文件' clearly states the action (download) and resource (file from bucket) in Chinese. It's specific about what the tool does but doesn't differentiate from its sibling 'download_files' (plural), which appears to be a similar tool for multiple files.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives like 'download_files' (for multiple files) or 'generate_presigned_url' (for temporary access). The description only states what it does, not when it's appropriate.

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

• list_objectsC
  2.9/5.0
  Behavior2/5

  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 offers minimal information. It doesn't mention whether this is a read-only operation, what permissions are required, how results are returned (pagination, format), or any rate limits. The description only states what the tool does at the most basic level.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise - a single Chinese phrase that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it front-loaded and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, how to interpret results, or provide any context about the operation's behavior beyond the basic purpose. The description should do more to compensate for the lack of structured metadata.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, so all parameters are documented in the schema. The description adds no additional parameter information beyond what's already in the schema, which is acceptable given the comprehensive schema documentation. The baseline of 3 is appropriate when the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('列出' meaning 'list') and resource ('存储桶中的对象' meaning 'objects in a bucket'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_buckets' or explain how this listing differs from other object-related operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'get_object_info', 'download_file', and 'list_buckets', there's no indication of when this listing operation is appropriate versus other object-related operations.

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

• upload_fileC
  2.9/5.0
  Behavior2/5

  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 states the action ('upload') but lacks details on permissions required, whether the operation is idempotent, error handling (e.g., if the bucket doesn't exist), or response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a basic upload operation, with zero waste or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity of a file upload operation (mutation, multiple parameters, no output schema), the description is incomplete. It lacks information on behavioral traits (e.g., overwrite behavior, error cases), usage context, and output expectations. With no annotations and no output schema, the description should provide more guidance to be fully helpful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all parameters documented in the schema itself (e.g., 'bucketName' as storage bucket name, 'filePath' as local file path). The description doesn't add any meaning beyond what the schema provides, such as explaining parameter interactions or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '上传文件到存储桶' clearly states the action (upload) and target (file to storage bucket) in Chinese, which translates to 'Upload file to storage bucket'. It specifies the verb and resource, making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'upload_files' (plural), leaving some ambiguity about when to use one versus the other.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing bucket), exclusions, or compare it to siblings like 'upload_files' or 'generate_presigned_url'. Without such context, users must infer usage from the tool name and parameters alone.

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

• list_bucketsB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It states the action ('列出' - list) but doesn't disclose behavioral traits such as whether it requires authentication, if it's read-only (implied but not stated), rate limits, pagination behavior, error conditions, or what the output format looks like. For a tool with zero annotation coverage, this leaves significant gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient phrase ('列出所有存储桶') that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (0 parameters) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the output contains (e.g., bucket names, metadata), potential errors, or behavioral context like authentication needs. For a list operation with no structured output documentation, more detail would be helpful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 0 parameters with 100% coverage, so the schema fully documents the absence of parameters. The description doesn't need to add parameter details, and it correctly implies no inputs are required by not mentioning any. This meets the baseline for tools with no parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '列出所有存储桶' (List all storage buckets) clearly states the tool's purpose with a specific verb ('列出' - list) and resource ('存储桶' - storage buckets). It distinguishes itself from siblings like 'bucket_exists' (checks existence) and 'list_objects' (lists objects within a bucket), but doesn't explicitly mention these distinctions in the description itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing to connect first), when it's appropriate (e.g., for inventory checks), or when to choose other tools like 'get_storage_stats' for metrics or 'bucket_exists' for existence verification.

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