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

With no annotations, the description carries the full burden for behavioral disclosure. It only states the basic copy action, omitting crucial details like overwrite behavior, recursive copying for folders, or potential errors.

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

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

The description is a single, efficient sentence with no fluff. It is appropriately front-loaded, though extremely terse.

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

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

The tool has no annotations or output schema, and the description does not clarify important behaviors such as whether folders are copied recursively or if existing destination files are overwritten. The 'prefijo' parameter descriptions are also unexplained, leaving gaps for the agent.

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

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

Schema description coverage is 100%, so the parameters already have descriptions. The tool description adds no extra meaning beyond the schema's 'Ruta origen con prefijo' and 'Ruta destino con prefijo', which remain somewhat ambiguous.

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

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

The description clearly states the tool copies a file or folder to another location. The verb 'Copia' (copies) + resource 'archivo o carpeta' (file or folder) is specific and distinguishes it from siblings like move_file or delete_file.

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

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

No guidance is provided on when to use this tool vs alternatives, no prerequisites, and no exclusions. The description only states what it does, not when to apply it.

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

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

The description discloses a key behavior—creating intermediate subfolders if needed—which goes beyond the schema. However, it doesn't address idempotency, existing folder behavior, or permissions. With no annotations, the description carries the full burden and is only partially transparent.

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

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

A single, clear sentence that is front-loaded with the action and includes the only essential nuance (recursive creation). No wasted words.

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

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

Given the tool's simplicity (one fully documented parameter, no output schema), the description adequately covers the core operation and a key behavior. It doesn't discuss edge cases, but these are less critical for a straightforward creation tool.

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

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

The schema provides a complete description of the folderPath parameter with an example, so the description adds no additional parameter semantics. Baseline 3 is appropriate for high schema coverage.

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

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

The description clearly states the action ('Crea una carpeta') and the resource (folder), and adds a distinguishing behavioral detail (creates intermediate subfolders). This distinguishes it from sibling file operations like write_file or delete_file.

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

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

The description does not explicitly state when to use this tool versus alternatives. While it is the only folder-creation tool, there is no guidance on prerequisites, error conditions, or comparisons to similar operations.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly warns that folder deletion removes all contents and that the operation is irreversible, which are critical behavioral traits. It could add more details like permission requirements, but for a simple delete tool this is sufficient.

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

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

Two concise sentences, front-loaded with the action and immediate caveats. Every word earns its place, with no fluff or repetition.

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

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

Given the simple nature of the tool (one parameter, no output schema), the description covers the essential context: what it deletes, the recursive behavior, and irreversibility. It is complete enough for an agent to use correctly, though it could mention path prefix semantics in more detail.

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

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

The schema description for filePath has 100% coverage, so the description adds little extra meaning about the parameter. The tool description mentions that it deletes files or folders, which aligns with the parameter description, but does not provide additional context beyond the schema.

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

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

The description uses a specific verb ('Elimina') and resource ('archivo o carpeta'), clearly stating it deletes files or folders with all contents if a folder. This distinguishes it from sibling tools like read_file, write_file, or move_file, showing it is the delete operation.

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

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

The description implies when to use it (for deleting files/folders) and highlights the irreversible nature, which serves as a caution. However, it does not explicitly mention alternatives or when not to use it, such as preferring move_file for reversible actions.

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

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

The description discloses that the tool returns metadata (name, type, size, date) for both files and folders, adding behavioral context. However, it does not mention error behavior, permission requirements, or side effects; with no annotations, the description carries the full burden but only partially addresses it.

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

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

A single sentence that is direct and free of filler, immediately communicating the tool's purpose.

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

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

For a simple get-metadata tool, the description covers the core functionality and return fields, but lacks information on error handling and usage context relative to siblings. Given the absence of an output schema, it would benefit from clarifying the return format or behavior on missing paths.

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

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

The input schema already fully describes filePath with a clear example and prefix requirement (100% coverage). The description adds no additional parameter semantics beyond restating that it applies to files or folders.

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

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

The description uses a specific verb 'Obtiene' (gets) and specifies the resource as file or folder, clearly indicating it retrieves metadata rather than content. This distinguishes it from siblings like read_file (content) and list_files (directory listing).

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as read_file or list_files. It does not mention exclusions or alternative tools, leaving the agent to infer usage from the purpose alone.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses the default root behavior and prefix requirements, but omits details like whether listing is recursive, hidden files, or what the response looks like. These gaps keep it at a moderate level.

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

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

Three compact sentences, each contributing: the action, the required prefix format, and the default behavior. No wasted words or redundant information.

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

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

For a simple list tool, the description covers the essential behavior: path handling and defaults. The lack of an output schema means some return format info would help, but the core functionality is adequately explained for an agent to use it correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful value by explaining the root prefix format with examples and the default behavior when folderPath is omitted, going beyond the schema's basic description.

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

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

The description clearly states the tool lists files and folders in a path, with specific root prefix conventions. It distinguishes itself implicitly from list_roots (root listing) and search_files (searching), but does not explicitly name alternatives, so it doesn't earn a 5.

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

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

It provides practical usage guidance: path must include a root prefix ('onedrive/' or 'aisquad/'), and omitting the path defaults to the OneDrive root. This is clear context, but it doesn't explicitly tell when to avoid this tool in favor of a sibling.

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

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

With no annotations, the description carries the transparency burden. It discloses the exact root values and their nature (OneDrive personal vs. shared folder), and provides usage context. It doesn't mention return format or side effects, but for a read-only listing of roots, the provided context is adequate.

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

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

The description is compact, front-loaded with the action, and includes only essential information plus a useful example. No filler or redundancy.

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

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

Given zero parameters and no output schema, the description fully covers what an agent needs: the purpose, the exact valid values, and how to use them. It is complete for this simple tool.

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

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

The tool has zero parameters, so by the rubric baseline is 4. The description adds no parameter-specific semantics, but none are needed since the schema is empty.

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

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

The description clearly states the tool lists available roots ('Lista las raices disponibles'), names the two specific roots ('onedrive' and 'aisquad'), and explains their meaning. It distinguishes itself from sibling file operations by defining these as navigation prefixes, making the purpose unmistakable.

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

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

It explicitly instructs to use the listed prefixes for navigation with an example ('onedrive/PROYECTOS BIT'), signaling that this tool is the entry point for discovering valid top-level paths. While it doesn't name alternative tools, the context implies when this should be used versus other file operations.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the basic action (move/rename) without mentioning whether the operation is destructive, whether overwrites occur, or any permission requirements. For a mutation tool, this is insufficient.

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

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

The description is a single sentence with no unnecessary words. It directly states the action and object, making it front-loaded and easy to parse.

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

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

Given the tool has no annotations and no output schema, the description is too minimal. It does not explain what happens on success, whether the operation is reversible, or any edge cases. For a mutation tool, this leaves significant gaps in the agent's understanding.

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

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

The schema descriptions for sourcePath and destinationPath already explain the parameter meanings (with prefixes and renaming behavior). Since schema coverage is 100%, the description adds little beyond what the schema provides, but it does confirm the action context.

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

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

The description clearly states the tool moves or renames a file or folder, which is a specific verb+resource combination. It distinguishes from siblings like copy_file and delete_file by the action, but does not explicitly mention alternatives or scope.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention scenarios where moving/renaming is preferred over copying or deleting, nor any prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It mentions reading text files but doesn't disclose the return format, error behavior for missing files, or any limitations (e.g., binary files). The transparency is minimal.

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

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

The description is a single concise sentence, front-loaded with the action and resource, and includes useful examples of file types. No wasted words.

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

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

The tool is simple with one parameter and no output schema. The description clarifies supported file formats, but it doesn't explain what the tool returns (e.g., raw text vs. structured response) or mention potential errors, 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.

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

Schema coverage is 100% since the only parameter 'filePath' has a description. The tool description adds no extra semantics beyond the schema's 'Ruta con prefijo del archivo a leer', 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.

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

The description clearly states it reads the content of text files, listing common extensions. It uses a specific verb and resource, but it doesn't distinguish from the sibling tool 'get_file', so it loses a point for lacking sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'get_file' or 'list_files'. It simply states what it does without any context for selection.

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

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

With no annotations, the description carries the burden. It discloses that the search is recursive, which is a meaningful behavioral trait. However, it does not disclose return format, case sensitivity, or any permissions—minimal behavioral context beyond the recursive flag.

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

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

One concise sentence that gets straight to the point, front-loaded with the verb, with no unnecessary words.

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

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

The description is adequate for a simple search tool but leaves out important operational details such as what the results contain (paths? names?) and any limitations. Given no output schema, a bit more context would be helpful.

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

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

The schema already describes both parameters (query and folderPath) with clear examples and coverage is 100%, so the description adds little extra parameter semantics. It only reiterates that search is by name, which aligns with the schema.

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

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

The description clearly states the tool searches files and folders by name within a folder, using a specific verb (busca) and resource. This distinguishes it from sibling tools like list_files or read_file, which have different purposes.

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

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

The description implies usage—when you need to find files/folders by name—but it does not explicitly compare with alternatives or state when not to use it. No exclusion criteria or alternative tool names are mentioned.

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

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

With no annotations provided, the description carries the burden. It discloses key behaviors: file creation/overwrite and automatic creation of intermediate directories. However, it does not mention potential side effects like data loss from overwriting, permission requirements, or error handling, leaving gaps in transparency.

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

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

The description is two concise sentences, front-loaded with the main action and followed by the folder-creation behavior. Every word earns its place, with no redundancy or filler.

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

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

For a simple write tool with two well-documented parameters and no output schema, the description is sufficiently complete. It explains the core action and a key side effect. Minor omissions like error scenarios or return behavior do not significantly hinder understanding.

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

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

Schema coverage is 100% with both parameters described. The description adds no extra parameter-level meaning beyond the schema, merely referencing 'contenido' and 'archivo'. The intermediate-folder creation is a behavioral trait, not a parameter detail.

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

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

The description clearly states the tool's function: 'Crea o sobreescribe un archivo' (creates or overwrites a file) with specified content. It uses a specific verb and resource, and distinguishes itself from sibling tools like create_folder and read_file by targeting file writing with overwrite semantics.

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

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

The description implies usage for writing files and creating intermediate folders, but does not explicitly contrast with alternative tools like create_folder or copy_file. The context is clear, yet no exclusions or when-not-to-use guidance is provided.

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