Server Quality Checklist

Tool Scores

• operations_statB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'mirroring rclone lsjson' which gives a hint about output format, but it does not explicitly state whether the operation is read-only, whether any modifications are made, or if special permissions are required. This lack of transparency is a significant gap for a tool with no 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, focused sentence that front-loads the purpose ('Stat an object'). It is concise with no redundant information, making it easy to parse quickly.

  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 annotations and no output schema, so the description must compensate. It provides a clear scope (single entry) and hints at output via the lsjson reference, but it lacks details on the exact return format, behavior with directories versus files, or how the 'opt' parameter affects results, leaving some gaps for the 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 input schema has 100% parameter descriptions, so the schema already fully documents all five parameters. The description adds no parameter-specific details beyond what the schema provides, so 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.

  Purpose4/5

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

  The description clearly states the tool returns metadata for a single file or directory, which is a specific verb and resource. The reference to 'mirroring rclone lsjson' hints at differentiation from listing tools like rclone_lsjson, but it could be more explicit in distinguishing from sibling operations.

  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 usage for single-item metadata retrieval via the phrase 'single file or directory', but it does not explicitly state when to use this tool over alternatives such as rclone_lsjson or operations_size, nor does it mention any exclusions or prerequisites.

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

• core_statsB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It implies a read-only, non-mutating operation via the word 'snapshot', which is useful, but it does not explicitly state that it has no side effects, nor does it mention behaviors related to the `_async` parameter. 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 a single, front-loaded sentence that says 'Current stats snapshot' and then explains what is returned. Every word contributes; it is minimal and efficient with no filler.

  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 stats tool with four optional parameters and no output schema, the description covers the key return content (bytes, speed, error counts). It does not explain grouping or async behavior, but those are well-covered by the schema, so the description is sufficient for basic 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?

  The schema provides full (100%) description coverage for all four parameters, so the baseline is 3. The tool description adds meaning about return content (bytes, speed, errors) but not about parameter semantics; it does not compensate or go beyond the schema's parameter documentation.

  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 returns a snapshot of active transfer statistics including bytes transferred, speed, and error counts, using a specific verb and resource. However, it does not differentiate from the sibling tool `operations_stat`, which likely serves a similar purpose, so it stops short of a perfect 5.

  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 such as `operations_stat` or other sibling tools. The description gives no context about typical use cases, prerequisites, or scenarios where this tool is preferred.

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

• rclone_lsjsonB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description must carry the burden of behavioral disclosure. It states that the tool lists objects and directories, which implies read-only behavior, but does not explicitly state that no modifications occur. It also mentions returning fields like `rclone lsjson`, which adds some context about output shape, but lacks details on pagination, response format, or backend-specific behavior.

  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, consisting of a single sentence with a dash-used emphasis. It is front-loaded with the action ('List objects') and includes a useful clarifier about matching `rclone lsjson`. Every word earns its place, and there is no superfluous information.

  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?

  The tool has 15 parameters and no output schema, yet the description only provides a one-line summary. It fails to mention default behavior (e.g., non-recursive unless `recurse` is set), the return format (JSON array), or any caveats about performance or API usage. The reference to `rclone lsjson` assumes familiarity with the external tool, which may not be available to the agent. This is insufficient for such a complex 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?

  Schema description coverage is 100%, so the baseline is 3. The description does not add any additional parameter semantics beyond what the schema already provides. Each parameter in the schema has a clear description (e.g., 'recurse', 'dirsOnly'), so the tool description does not need to compensate.

  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: 'List objects — Lists objects and directories for a remote path.' It specifies the action (list), resource (objects and directories), and scope (remote path). It also distinguishes from siblings like operations_mkdir and operations_deletefile by its focus on listing. The reference to `rclone lsjson` further clarifies the exact behavior.

  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 gives no guidance on when to use this tool versus alternatives. It does not mention any exclusions or prerequisites. Siblings like operations_stat could be confused for listing a single object, but the description provides no comparative context or usage hints.

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

• operations_deletefileA
  3.5/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 disclosing behavior. It only states that the file is removed, with no mention of permanence, irreversibility, permission requirements, or side effects. This is minimal guidance for a destructive operation.

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

  Conciseness4/5

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

  The description is short and front-loaded, but the em-dash clause 'Removes a specific object from the remote' is somewhat redundant with 'Delete single file'. It is compact but not maximally 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?

  The description lacks critical context for a destructive tool, such as whether deletion is permanent, what happens if the file does not exist, and whether special permissions are required. With no annotations and no output schema, the description is insufficient for safe 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 the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.

  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 (delete) and the resource (single file/object). It distinguishes from siblings like copyfile and movefile by focusing exclusively on deletion.

  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 when to use the tool (to delete a single file), and the sibling tool names provide contrast for other operations. However, it does not include explicit exclusions or alternatives, but the context is clear enough.

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

• config_listremotesA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It states that all remote names are returned and implies a read-only listing operation, but it does not disclose edge cases (e.g., empty config file), authentication requirements, or whether the list reflects only the persistent config. For a straightforward list command, 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 a single, front-loaded sentence with two parts: a succinct purpose ('List configured remotes') and an explanatory clause. No wasted words, easy to scan.

  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 (no required parameters, no output schema, no annotations), the description is complete enough: it names the action, the resource, and the return type. It does not need to elaborate further, though it could mention formatting (e.g., array vs. newline-delimited).

  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 both parameters (_async and _group) with high coverage (100%). The description adds no extra parameter-level meaning, so the baseline of 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 uses the specific verb 'List' with the resource 'configured remotes' and explicitly states the return value: 'names of all remotes defined in the config file.' This clearly distinguishes the tool from siblings like config_get (which likely retrieves specific config) and operations_* 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 compared to alternatives. It does not mention config_get for details on a single remote, nor does it state any prerequisites or exclusions. The agent must infer usage solely from the tool's name and description.

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

• operations_mkdirA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses an important behavior (idempotence via "if it does not exist"), but it does not mention whether parent directories are created, what happens on errors, or detail the response/return value. This is a moderate level of transparency for a simple create operation.

  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 short and front-loaded, with the main action stated first. The phrase "Create directory" is somewhat redundant with the tool name, but the clarifying clause adds value. Overall it is efficient with no unnecessary filler.

  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?

  Given the tool's simplicity and full schema coverage, the description provides a basic understanding of the action. However, it omits key context such as whether parent directories are created automatically and what happens if the target already exists (the "if it does not exist" hints at idempotence but does not fully clarify error behavior). This leaves some gaps for a no-annotation, no-output-schema 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 schema already describes all four parameters with 100% coverage, so the baseline is 3. The description adds no supplementary meaning about the parameters; it only paraphrases the concept of a target directory, which is already captured by 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 verb (create) and resource (directory/container), and the idempotent condition "if it does not exist" adds precision. It is distinctly different from sibling tools like operations_copyfile or operations_deletefile, so purpose is unambiguous.

  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 usage (to create a directory), but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. Sibling tools are all different operations, so no conflict is present, but no guidance is given beyond the obvious purpose.

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

• config_getA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of transparency. It discloses that the tool returns key/value settings, implying a read operation, but lacks explicit statements about safety, error handling, or prerequisites such as existing remote.

  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: two short sentences that front-load the verb and resource, with no redundant information.

  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?

  For a simple getter, the description adequately states the return type (key/value settings), but with no output schema and no mention of edge cases like missing remote names or error behavior, it is only minimally 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 coverage is 100%, so the baseline is 3. The description adds minimal meaning by clarifying the 'single remote' scope, but the parameter descriptions already cover all necessary 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 verb ('Get'), resource ('remote configuration'), and scope ('single remote'), distinguishing it from sibling tools like config_listremotes which list all remotes.

  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 usage for a single remote, which contrasts with listremotes, but it does not explicitly name alternatives or provide when-to-use versus when-not-to-use guidance.

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

• core_aboutA
  3.8/5.0
  Behavior3/5

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

  Since no annotations are provided, the description must carry the full burden of behavioral disclosure. It states the tool returns storage quota and usage details, implying a read-only operation, but it does not explicitly confirm safety, side-effect-free behavior, or error conditions. The description adds 'equivalent to rclone about' which offers some context, but there is room for more explicit behavioral disclosure.

  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 primary action ('Get remote quota') and includes a clear explanation of the return value. It is concise, with no superfluous words, and effectively communicates the tool's function.

  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, with no output schema and no annotations. The description explains what it returns (storage quota and usage details) and provides context via the rclone equivalence. It is complete enough for an agent to select and invoke the tool correctly, though it could optionally mention the format of the returned details.

  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 descriptions for all three parameters (fs, _async, _group), achieving 100% coverage. The tool description adds no additional parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.

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

  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 purpose: 'Get remote quota' and elaborates on returning storage quota and usage details. It distinguishes itself from sibling file-operation tools by focusing on quota information and even mentions the equivalent rclone command, making its purpose 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 provides clear context for when to use the tool (to retrieve quota and usage), but it does not explicitly discuss when not to use it or mention alternative tools. The equivalence to 'rclone about' offers some guidance, but it lacks explicit exclusions or comparisons with siblings.

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

• operations_movefileA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses long-running/async behavior and jobid polling, which adds value beyond the schema. But it does not explicitly state that the source is deleted after a successful move, nor does it mention permissions, overwrite behavior, or sync return values.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose, followed by a necessary async warning. There is no fluff or redundancy, making it highly concise and well-structured.

  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 description is minimally viable for a move operation but lacks explicit details on prerequisites (e.g., required source/destination), sync return values, and the fact that the source is removed. With six parameters and no output schema, more clarity would improve completeness.

  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 six parameters already have descriptions. The tool description does not add further meaning for any parameter; it only echoes the `_async` behavior. Thus the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the action ('Move a single file') and the resource ('one object') with explicit source and destination contexts. This distinguishes it from siblings like operations_copyfile, operations_deletefile, and operations_mkdir.

  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 an explicit conditional guideline for async execution ('If this operation is expected to take a long time... you MUST set `_async: true`'), including how to handle the resulting jobid. However, it does not mention alternatives or when to prefer move over copy/delete, so it lacks full selection guidance.

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

• operations_copyfileA
  4.1/5.0
  Behavior3/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 disclosing behavior. It explains the async mode and jobid/polling behavior, which is valuable. But it does not mention overwrite semantics, what the synchronous call returns, or error conditions, leaving gaps for a file-copy operation.

  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 short and front-loaded, but the opening 'Copy a single file — Copies one object' is somewhat redundant. The important async warning is clearly highlighted. Overall it is concise with minimal waste.

  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 6-parameter operation with no output schema, the description covers the core usage (copy from source to destination) and the crucial async guidance. It lacks details on synchronous return values and edge cases, but the schema fills in parameter specifics, making it sufficiently complete for an agent to invoke correctly.

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

  Parameters4/5

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

  The schema covers 100% of parameters with descriptions, providing a baseline of 3. The tool description adds meaningful context: it explains the source/destination remote/path structure and emphasizes the `_async` parameter's importance for long operations and its jobid return value, going 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 opens with 'Copy a single file' which is a specific verb and resource, immediately distinguishing it from sibling tools like operations_movefile (move vs copy) and operations_deletefile. It clearly states the action: copying one object from a source remote/path to a destination remote/path.

  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 includes explicit guidance to use `_async: true` for long-running operations and mentions polling with `job_status`. However, it does not explicitly state when to prefer this tool over alternatives like movefile, though the action itself differentiates.

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

• core_versionA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that the action is a 'report' (implying read-only) and explicitly lists the three categories of returned data (version, build metadata, Go runtime details). This gives the agent a clear picture of behavior without hiding anything.

  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 entire description is one concise sentence that front-loads the primary verb and resource ('Report rclone version'), then immediately lists the expected output. Every word earns its place; there is no filler or redundancy.

  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?

  This is a trivial tool with no output schema, so the description must explain return values. It does so by enumerating version, build metadata, and Go runtime details. The generic parameters are fully documented in the schema, and no other context is required. The description is complete for its 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?

  The input schema has 100% description coverage for both parameters (_async and _group), including their meaning and purpose. The description adds no parameter-specific details, but since these are generic infrastructure parameters, the schema already suffices. Thus the baseline of 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 uses specific verbs and a resource: 'Report rclone version' and clearly states the exact output: 'running rclone version, build metadata, and Go runtime details.' This unambiguously differentiates it from sibling tools like core_stats or operations_mkdir, which serve entirely different purposes.

  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 makes the use case obvious—call this tool when you need the rclone version or build/runtime information. There are no competing sibling tools for this functionality, so no exclusions or alternative tool references are needed. The context is clear and sufficient.

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

• operations_sizeA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description discloses the key behavioral traits: a potentially long-running operation, the requirement to set _async for long runs, immediate jobid return, and polling via job_status. It does not state read-only status, but 'Count remote size' strongly implies a non-mutating 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 two sentences: the first leads with the purpose and output metrics, the second presents the critical async guidance. Every sentence is informative and the format is 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 size-counting tool with no annotations and no output schema, the description covers the main behavior, the async path, and the polling mechanism. It lacks an explicit return-value breakdown or error cases, but is reasonably complete for the tool's simplicity.

  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, but the description adds important semantics by mandating _async for long-running cases and clarifying the background-execution behavior. It also reinforces that fs denotes the remote to measure, though _group is only covered by 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 opens with 'Count remote size' and specifies the exact outputs: total size, file count, and number of objects without size metadata. This clearly distinguishes it from sibling file-operation tools like operations_mkdir or operations_deletefile.

  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 clearly frames the tool as a remote-size reporting operation and provides important operational context through the async execution note. It does not explicitly compare against alternatives or state when not to use it, but the purpose is specific enough to guide selection.

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