Server Quality Checklist

Tool Scores

• create_folderA
  3.8/5.0
  Behavior3/5

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

  The description adds useful behavioral context beyond annotations: "a denial means the API key lacks this tool's scope, not a tool failure." It also notes the need for bucketName. However, it does not disclose what happens if the folder already exists, whether the operation is idempotent (though annotations mark idempotentHint=false), or what the successful response contains. Annotations already declare readOnlyHint=false and destructiveHint=false, lowering the bar for extra disclosure, but some gaps remain.

  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 two sentences, front-loaded with the core action. The first sentence states the purpose immediately; the second adds necessary prerequisite and error-context details without redundancy. Every clause contributes value, and there is no wasted wording.

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

  Completeness4/5

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

  The tool has a simple create-folder operation, no output schema, and annotations cover safety flags. The description explains the prerequisite (bucketName) and error interpretation, which is sufficient for basic usage. However, it does not mention the return value or behavior on duplicate folders, which would help the agent fully model the operation. Still, it is more complete than many tools at this complexity level.

  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 each parameter (name, bucketName, parentPath) already described in the input schema. The description does not add semantic detail beyond what the schema provides, such as format constraints or examples. Baseline 3 is appropriate since the schema fully documents parameters.

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

  Purpose5/5

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

  The description clearly states the action: "Create a new folder at the given path in a drive." This is a specific verb+resource pairing that distinguishes it from sibling tools like upload_file or delete_files. The mention of 'given path' adds precision.

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

  Usage Guidelines3/5

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

  The description provides a key prerequisite: "Requires the drive (bucketName)," and explains the meaning of authorization denials. However, it lacks explicit when-to-use versus alternative tools, such as when to choose create_folder over upload_file or browse_folder. There is no mention of alternatives or conditions for non-use.

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

• duplicate_fileA
  3.9/5.0
  Behavior4/5

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

  Annotations already communicate read/write and non-destructive nature. The description adds valuable context about server-side RBAC authorization and explains that a denial means missing scope, not a tool failure. However, it does not disclose naming conventions or behavior when a duplicate name exists.

  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 two sentences, front-loaded with the core action, and includes only necessary context about requirements and authorization. No wasted words.

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

  Completeness3/5

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

  The tool has no output schema, so the description should explain what the tool returns or what the copied file is named. It does not. While it covers purpose and auth behavior, the missing success-result info leaves a clear gap for a mutation tool.

  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 provides 100% parameter coverage, including descriptions for objectKey, storageId, and bucketName. The description only reiterates the bucketName requirement without adding new syntax or format details, so it stays at the baseline 3.

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

  Purpose5/5

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

  The description explicitly states 'Create a copy of a file in the same location', which is a specific verb+resource+location. It clearly distinguishes itself from siblings like move_file and rename_file by emphasizing same-location copying.

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

  Usage Guidelines3/5

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

  The description gives a clear prerequisite (requires bucketName) but provides no explicit guidance on when to use this tool versus alternatives like move_file or upload_file. Context is implied but not stated.

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

• get_file_metadataA
  4/5.0
  Behavior3/5

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

  The description adds a list of returned metadata fields (size, type, timestamps, storage class) beyond what annotations declare. However, the readOnlyHint and openWorldHint annotations already cover safety, and the description does not disclose potential error conditions (e.g., not-found behavior, permission requirements). It provides modest added context but not rich behavioral detail.

  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 two sentences, tightly written, front-loaded with the primary action and clarifying scope. Every phrase earns its place without redundancy or fluff.

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

  Completeness4/5

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

  For a simple read-only metadata tool with well-documented parameters and annotations, the description is sufficient. It lists key metadata attributes and the required context (bucketName). It slightly lacks behavioral expectations like error handling or return format, but the simplicity of the tool and rich schema make it adequately complete.

  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 baseline is 3. The description adds the phrase 'by its object key' and 'Requires the drive', which loosely aligns with the schema, but it does not add new meaning beyond the already detailed schema descriptions for objectKey and bucketName. The schema carries the full parameter semantics.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Get detailed metadata for a single file or object' with specific attributes (size, type, timestamps, storage class). It distinguishes from siblings like get_file_tags (tags only) and list_files (multiple files), and the 'by its object key' qualifier clarifies the access method.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use the tool: for a single file/object, requiring the object key and the drive (bucketName). It does not explicitly name alternatives or exclusions, but the 'single' scope and reference to the drive give enough guidance. The sibling tool names (e.g., list_files, search_files) are implicitly differentiated.

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

• get_file_tagsA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a read-safe operation and the output may depend on external factors. The description adds no further behavioral details beyond the purpose and the bucketName requirement; it does not mention error cases, empty results, or response format. With annotations covering safety, a neutral score is appropriate.

  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, compact sentence that immediately states the action and the key requirement. There is no fluff or repetition; each phrase adds essential information. The structure is front-loaded and easy to parse.

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

  Completeness4/5

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

  Given the tool's simplicity, the description covers the core purpose and a critical prerequisite. No output schema exists, but the description implies the return concept (tags). The annotations cover the safety profile, and the schema fully documents parameters. Minor missing details like what an empty tag set returns are non-essential for this low-complexity tool.

  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 provides thorough descriptions for both parameters: objectKey defines the full path, and bucketName explains the drive naming and default behavior. The tool description only restates these concepts ('by object key', 'requires the drive'), adding no new meaning beyond the schema. Since schema coverage is 100%, the baseline of 3 is justified.

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

  Purpose5/5

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

  The description clearly states the action: 'Get the S3 object tags (key/value pairs) attached to a file, by object key.' This is a specific verb (Get) and resource (S3 object tags), and the 'by object key' scope distinguishes it from the sibling get_file_metadata, which presumably retrieves broader metadata.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use this tool: when you need to retrieve S3 object tags for a specific file identified by object key. It also notes the prerequisite of requiring the drive (bucketName), which helps the agent understand a necessary condition. It does not explicitly mention alternatives or exclusions, but the context is sufficient for basic selection.

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

• recent_filesA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds useful ordering and pagination behavior, but doesn't go deeper into potential nuances like external modifications (covered by openWorldHint) or whether 'accessed' vs 'modified' is prioritized. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that front-loads the action ('List'), resource ('files'), scope ('account's'), and key behavior (newest first, pagination). No redundant words.

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

  Completeness4/5

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

  The tool is simple (list with pagination) and the description, combined with schema and annotations, is largely complete. However, with no output schema, the description doesn't hint at what fields are returned for each file, which could be useful but isn't strictly necessary for invoking the 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 provides complete descriptions for both limit and cursor, including default and constraints. The description only mentions 'pagination' generally, adding no semantic beyond the schema. Baseline 3 is appropriate given 100% schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool lists the account's most recently accessed or modified files, with a specific ordering (newest first) and pagination. This distinctly separates it from siblings like search_files (query-based) or browse_folder (navigational).

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

  Usage Guidelines4/5

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

  The description implies the appropriate context: when an agent needs recently accessed/modified files. It doesn't explicitly name alternatives or exclusions, but the distinct purpose (recently vs. by search or folder) provides clear enough guidance for a straightforward list tool.

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

• search_filesA
  4/5.0
  Behavior4/5

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

  The description adds meaningful behavioral context beyond the readOnlyHint/openWorldHint annotations by clarifying that the search operates on 'the indexed view' (implying results may not be a real-time filesystem scan) and that pagination is used. It does not contradict annotations and provides useful information about scope and output style.

  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?

  Three short sentences with no redundancy or filler. The first sentence gives the core purpose, the second states a key dependency, and the third notes pagination. Every sentence carries information, and it is well front-loaded.

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

  Completeness4/5

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

  For a simple search tool with no output schema, the description covers the core function, the indexed nature, the requirement on bucketName, and pagination. It does not specify the exact structure of matches, but the tool is not complex enough to demand more; the gaps are minor given the schema richness.

  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 coverage is 100%, so all parameters are already documented with descriptions. The text reinforces that bucketName is required and indicates the search is name-based, but it does not add meaningfully to the schema descriptions (e.g., no examples, no default behavior beyond what's stated). Meets the baseline for high coverage.

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

  Purpose5/5

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

  The description immediately states the tool's verb ('Search'), target resource ('files and folders'), and scope ('within a drive (the indexed view)'), with a distinctive qualifier that separates it from sibling tools like list_files or browse_folder. It also explicitly notes the pagination behavior, making the core function unmistakable.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool (searching by name keyword) and notes a prerequisite (requires bucketName), but it does not explicitly contrast it with alternatives such as list_files or browse_folder. There is no 'use this instead of X' guidance, so it stays at implied usage rather than explicit recommendations.

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

• share_linkA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the link is time-limited and pre-signed, which is useful context, but it does not disclose expiration behavior, auth requirements, or any side effects beyond the annotation hints. Given the annotation coverage, this is adequate but not rich.

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

  Conciseness5/5

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

  The description is two sentences, with the primary purpose in the first sentence and a helpful alternative in the second. No wasted words; every part earns its place.

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

  Completeness4/5

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

  For a tool with no output schema, the description effectively implies the return value (the pre-signed URL) by calling it 'a pre-signed URL suitable for sharing.' It covers the core behavior, required parameter, and provides an alternative path for advanced use. Minor gap: expiration details aren't specified, but the tool is simple and the description is sufficient for selection and invocation.

  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 already well-documented. The description mentions that bucketName is required and repeats the schema's purpose of filePath, but adds no new meaning beyond the schema. Baseline 3 is appropriate since the schema carries the load.

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

  Purpose5/5

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

  The description clearly states the tool creates a shareable, time-limited pre-signed URL for a file, using the verb 'Create' with a specific resource (link) and scope (file). It distinguishes from siblings like download_file and upload_file by focusing on share-link generation, and mentions the dashboard as an alternative for richer management.

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

  Usage Guidelines4/5

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

  The description provides clear context: it is for creating simple time-limited share links and requires the bucket name. It also gives an explicit alternative (CloudSee dashboard) for richer share management, though it does not explicitly state when not to use this tool or compare to sibling tools directly.

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

• download_fileA
  4.3/5.0
  Behavior5/5

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

  Beyond the readOnlyHint and openWorldHint annotations, the description discloses that the URL is short-lived, grants read access to one object only, is time-limited, and returns the URL rather than the file bytes. This adds valuable behavioral context that the annotations do not cover.

  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 two sentences, front-loaded with the primary action, and each sentence earns its place: the first states purpose and requirement, the second explains behavior and return value. No wasted words.

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

  Completeness5/5

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

  For a simple URL-returning tool, the description fully covers what it does, what it requires, what it returns, and the key behavioral nuance (does not load bytes). With readOnlyHint and detailed schema, no essential context is missing.

  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 for all parameters, so the schema already explains filePath, storageId, bucketName, and forceDownload. The description adds no parameter-level meaning beyond stating that bucketName is required, which is already in the schema. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Get a short-lived pre-signed download URL for a file.' It clearly states the action and result, and distinguishes itself from siblings by noting it does not load file bytes into the conversation, differentiating from upload or content-fetching tools.

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

  Usage Guidelines3/5

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

  The description provides context (requires bucketName, URL is time-limited, share with care) but does not explicitly mention when to use this tool versus alternatives like share_link, nor does it state exclusion conditions beyond not loading bytes. The 'does not load file bytes' is more a behavioral fact than a usage guideline.

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

• rename_fileA
  4.3/5.0
  Behavior5/5

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

  Beyond the destructiveHint annotation, the description discloses queued behavior (returns RequestId, completes in background under 2 minutes), the need for confirm=true, and the RBAC/authorization nuance (denial means scope issue, not tool failure). This adds significant behavioral context that the annotations alone do not provide.

  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 four sentences and front-loads the core purpose. Each sentence adds meaningful information (addressing, queueing, destructiveness, auth). It is slightly dense and repeats the storageId caution that already exists in the schema, but overall it is efficient and well-structured.

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

  Completeness4/5

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

  For a mutating tool with no output schema, the description covers key aspects: how to address the object, queued async behavior, verification strategy, confirmation requirement, and auth context. It does not describe the preview return when confirm=false or error scenarios, but these are partially inferable from the schema and annotations. The description is sufficiently complete for an agent to invoke the 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?

  Schema coverage is 100%, so the baseline is 3. The description reinforces the storageId distinction (from indexed tools, not list_files) and mentions required fields, but most parameter-level meaning is already present in the schema descriptions. The addition of queued behavior and confirm semantics is more behavioral than parameter-specific, so no strong uplift beyond baseline.

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

  Purpose5/5

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

  The description states 'Rename a file or folder in a drive' with a specific verb and resource, and immediately clarifies the addressing scheme (exact object key plus storage id). It distinguishes from sibling tools like move_file and duplicate_file by focusing on key renaming, and explicitly notes the storage id source differs from list_files, eliminating ambiguity.

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

  Usage Guidelines4/5

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

  The description provides clear when-to-use context: it explains the storage id must come from indexed listing tools, not list_files, and says to verify by listing until the new name appears. It also states prerequisites (drive/bucketName) and the confirm requirement. However, it does not explicitly contrast with alternatives like move_file or duplicate_file, leaving some inference to the agent.

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

• browse_folderA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint, and the description adds meaningful context about the indexed view (implying potential staleness) and the dependency on bucketName. It also mentions sorting and pagination, which is beyond the annotation scope.

  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?

  Three sentences, front-loaded with the core action, then providing usage alternatives. Every sentence contributes necessary information without unnecessary verbosity.

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

  Completeness4/5

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

  Given the moderate complexity (5 params, no output schema), the description covers purpose, usage, prerequisites, and distinguishes from siblings. It adequately conveys that the result is a paginated list, though it omits error handling or default sort behavior, which would enhance completeness further.

  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 coverage is 100% with detailed parameter descriptions, so the schema already defines all five parameters. The description only reinforces bucketName requirement, adding minimal semantic value beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool lists files and sub-folders in a folder, specifying it uses the indexed view with sorting and pagination. It distinguishes itself from siblings by naming search_files for keyword filtering and list_files for recursive storage listing.

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

  Usage Guidelines5/5

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

  Provides explicit guidance: requires bucketName, and directs users to search_files for keyword filtering and list_files for recursive direct storage listing. This clearly states when to use this tool vs alternatives.

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

• upload_fileA
  4.4/5.0
  Behavior5/5

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

  The description discloses substantial behavioral details beyond the annotations: the pre-signed URL flow, automatic multi-part upload for files over 8 MiB, and the RBAC authorization mechanism with an explicit note that denial is a scope issue, not a tool failure. There is no contradiction with annotations (readOnlyHint=false confirms write operation).

  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 efficient and front-loaded with the core action, followed by necessary process details (pre-signed URLs, size threshold, RBAC). Every sentence contributes useful information without redundancy. It is well-structured and appropriately sized.

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

  Completeness4/5

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

  The description covers the upload process, size handling, and authorization failure behavior, which is solid for a tool with no output schema. However, it does not mention what the tool returns on success (e.g., object URL or metadata) or what happens on overwriting an existing file. This is a minor gap given the complexity.

  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 coverage is 100% with each parameter described. The description adds minimal parameter-specific meaning, mostly restating that bucketName is required (which the schema already states). It does not clarify new parameter behavior beyond what the schema provides, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the action: 'Upload a local file to a folder in a drive.' It uses a specific verb and resource, and the distinct purpose is obvious versus sibling tools like download_file or search_files. The scope (drive/folder) and the requirement for bucketName are also mentioned.

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

  Usage Guidelines4/5

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

  The description gives clear context: it requires a drive (bucketName), reads from local machine, and uses pre-signed URLs. It explains the process but does not explicitly state exclusions or alternatives (e.g., when to use download_file instead). However, the context is sufficient to infer appropriate use.

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

• list_filesA
  4.5/5.0
  Behavior5/5

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

  Beyond the readOnlyHint and openWorldHint annotations, it discloses that object IDs are regenerated on every call and must not be used for certain operations, and describes recursion defaults and pagination. This adds essential behavioral context that annotations do not cover.

  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 front-loaded with purpose, then parameter requirement, return values, and an important caveat about object ID stability. Each sentence carries critical information without redundancies, making it concise yet comprehensive.

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

  Completeness5/5

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

  For a read-only listing tool with no output schema, the description covers return fields, pagination, recursion, bucket requirements, and a critical ID instability warning with explicit alternative tools. This is a thorough and self-contained context.

  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 already fully describes all three parameters (100% coverage), including defaults and required-conditions. The description mentions the bucket requirement and recursion default but adds no additional parameter-level detail, so baseline 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool lists files from storage, recursively by default, and explicitly distinguishes itself from siblings by noting it is 'the most reliable way to see what a drive actually contains' and by contrasting with search_files/browse_folder/recent_files for stable IDs.

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

  Usage Guidelines4/5

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

  It provides clear usage context ('most reliable way to see what a drive actually contains') and gives explicit alternative tools for stable StorageId use. It lacks a broader 'when not to use' statement, but the guidance is specific enough for an agent to make a reasonable choice.

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

• move_fileA
  4.6/5.0
  Behavior5/5

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

  Goes well beyond annotations by disclosing queued/asynchronous behavior (returns RequestId, completes in background, verify by listing), destructive nature of move vs copy, confirm requirement, RBAC authorization context, and that denials indicate scope issues. This adds rich operational context that annotations only hint at, fully informing the agent of side effects and expectations.

  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 information-dense and front-loaded with the core function, then systematically covers addressing, async behavior, destructiveness, and auth. Every sentence earns its place, though it is slightly long and could be split into clearer paragraphs. Still, it avoids fluff and is well-organized.

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

  Completeness5/5

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

  For a complex tool with 8 parameters and no output schema, the description covers critical operational aspects: queued completion, verification method, destructive consequences, confirm flag semantics, and RBAC error interpretation. It also clarifies parameter sources and defaults, making the tool fully usable without external context. No significant gaps exist.

  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?

  Schema covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds important semantic nuance beyond the schema: the storageId must come from search_files/browse_folder/recent_files and will NOT work from list_files, and confirm=true is required for actual execution while omitted/false yields a preview. These clarifications prevent misuse of parameters, elevating value above the schema alone.

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

  Purpose5/5

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

  The description explicitly states the tool moves (or copies) a file/folder to a new location, specifying the addressing method (exact object key + storage id). It clearly distinguishes move vs copy behavior and ties to sibling listing tools, leaving no ambiguity about the tool's primary function.

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

  Usage Guidelines4/5

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

  Provides clear guidance on when to use (for move/copy operations) and critical prerequisites: requires confirm=true for destructive moves, correct storageId source, and bucketName. It implicitly differentiates from siblings by noting the storageId must come from indexed listing tools, not list_files, and explains queued background execution with verification instructions. Lacks explicit mention of alternative tools like duplicate_file or rename_file, so not a perfect 5.

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

• delete_filesA
  4.7/5.0
  Behavior5/5

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

  Beyond the destructiveHint and readOnlyHint annotations, the description discloses queued asynchronous behavior (RequestId, background completion, ~2 minutes), the need to verify by listing, and RBAC denial semantics. This is rich context that significantly aids the agent.

  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 compact yet dense, front-loaded with the core purpose, then detailing addressing, queuing behavior, and authorization. Every sentence contributes actionable information with no fluff.

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

  Completeness5/5

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

  Despite no output schema, the description explains the return type (RequestId per object), how to confirm completion, and the meaning of authorization denial. It covers the tool's complexity comprehensively, addressing async behavior, prerequisites, and irreversibility.

  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?

  Schema coverage is 100%, so the baseline is 3. The description reinforces and clarifies parameter usage, especially the storageId pitfall ('not from list_files') and the structure of objects array (one request per object). This adds practical guidance beyond the schema.

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

  Purpose5/5

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

  The description clearly states the action: 'Permanently delete one or more files/folders from a drive' with specific details on object addressing. It is easily distinguished from sibling tools like rename_file, move_file, and duplicate_file.

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

  Usage Guidelines4/5

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

  Provides clear context for correct usage, including the exact source of storageId (from search_files/browse_folder/recent_files, not list_files), the need for bucketName, and confirm=true. It implicitly distinguishes from other file operations, though it does not explicitly list alternatives or when-not-to-use scenarios.

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

• list_bucketsA
  4.7/5.0
  Behavior4/5

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

  Annotations already convey readOnlyHint and openWorldHint, and the description adds meaningful context: results are filtered by caller permissions and the tool returns drive names used as identifiers elsewhere. This is useful behavioral detail beyond the annotation flags, though not exhaustive.

  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 two sentences, front-loaded with the action, and every clause earns its place. It is both concise and well-structured.

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

  Completeness5/5

  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 schema and strong annotations, the description provides sufficient context: what is listed, permission scoping, usage order, and a critical naming convention. No return schema is needed because the description explains the key output field.

  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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameters; it instead clarifies the output semantics (Name = bucketName), which is valuable for downstream tool usage.

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

  Purpose5/5

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

  The description uses a specific verb 'List' and identifies the resource as 'drives registered to the authenticated CloudSee Drive account that the caller is allowed to see,' clearly distinguishing it from sibling file-level tools like list_files and browse_folder.

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

  Usage Guidelines5/5

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

  It explicitly instructs to use this tool first before browsing or searching, and explains that the returned 'Name' corresponds to the 'bucketName' expected by other tools. This provides direct guidance on when to use it and how it relates to alternatives.

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

• restore_archived_fileA
  4.8/5.0
  Behavior5/5

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

  Annotations already mark it as destructive and non-read-only, but the description adds critical context: confirm=true is required, the operation incurs retrieval cost, may take minutes to hours, and RBAC denials are scope errors rather than tool failures. It also clarifies this is Glacier un-archiving, not file recovery. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is four sentences, front-loaded with action and resource. Each sentence earns its place: action, prerequisite, clarification/cost/time, and confirmation/auth behavior. There is no filler or redundant restating of the title or schema.

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

  Completeness4/5

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

  The description covers prerequisites, side effects, cost, latency, auth behavior, and the mutating nature requiring confirmation. The only gap is that with no output schema, it does not mention what the tool returns (e.g., job status or async tracking), which would be useful for an operation that takes minutes to hours. Overall, it is quite complete for selection and invocation.

  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 already covers all six parameters with 100% description coverage, so the baseline is 3. The description adds value by emphasizing the bucketName prerequisite and the confirm=true gate, reinforcing critical parameters beyond their schema descriptions. It does not redundantly restate each parameter, making it useful emphasis rather than repetition.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Begin restoring an archived (S3 Glacier) object so it can be downloaded.' It further distinguishes itself with 'NOT recovery of a deleted file,' clearly separating it from deletion/recovery tools. The purpose is unambiguous and distinct from sibling tools like download_file or delete_files.

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

  Usage Guidelines5/5

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

  Explicitly describes when to use: to restore an archived object for download. Provides exclusions ('NOT recovery of a deleted file'), states required prerequisites (bucketName, confirm=true), and warns of cost/time implications. This gives clear decision-making guidance beyond simply naming the action.

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

• update_metadataA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare destructiveHint=true, but the description adds crucial specifics: this SETS the full state and omitted fields/tags are cleared. It also discloses the confirm flag as a required safety gate and explains server-side RBAC behavior. No contradiction; the description genuinely enriches the annotation.

  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 compact (three sentences) with every sentence carrying essential information. It front-loads the purpose, then packs destructive behavior, prerequisites, and auth nuances without unnecessary verbosity.

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

  Completeness5/5

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

  For a destructive mutation tool with 5 parameters, nested objects, and no output schema, the description covers the purpose, usage, prerequisites, behavioral side effects, id source, and error interpretation. The absence of return-value details is acceptable given the behavior is fully clarified by the description and schemas.

  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?

  Schema coverage is 100%, so the baseline is 3, but the description adds meaningful cross-parameter context: it aggregates prerequisites (bucketName and confirm=true), explains the destructive full-overwrite semantics for metadata and tags, and reinforces the storageId provenance caveat. This goes beyond simple schema repetition, though some redundancy with schema descriptions exists.

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

  Purpose5/5

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

  The description specifies 'Update a file's metadata (category / description / project) and tags' with a clear verb and resource. It also distinguishes from sibling tools by pointing to the correct storage id source (search_files / browse_folder / recent_files, not list_files), which differentiates it from read/list operations.

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

  Usage Guidelines5/5

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

  Explicitly states when to use the tool and what to avoid: it requires the storage id from indexed listing tools, not list_files. It also names prerequisites (bucketName and confirm=true) and clarifies that RBAC denials mean the API key lacks scope, not a tool failure, guiding troubleshooting.

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