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

No annotations exist, so the description carries the full burden. It discloses overwrite behavior and provides example paths, but does not explain recursive folder copying, error handling, permissions, or return values. For a mutation operation, this is a moderate level of disclosure.

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

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

The description is a single clear headline followed by a structured argument list. Every sentence serves a purpose—stating the action, defining parameters, and clarifying overwrite semantics—with no filler or redundancy.

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

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

The description covers the action and parameters well for a standard copy operation, but lacks an output/return value description. Given the absence of an output schema and annotations, a brief note on success indication or error behavior would make it fully complete. The provided examples and overwrite detail raise it above a bare minimum.

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

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

The input schema has no parameter descriptions (0% coverage), but the tool description fully compensates by explaining src, dst, and overwrite with examples and a default behavior. This is the strongest possible compensation for missing schema metadata.

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

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

The description states 'Copy a file or folder to a new location' with a clear verb and resource, and the parameter list confirms specific behavior. This differentiates it from sibling tools like move and rename by explicitly indicating duplication rather than relocation.

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 copy versus alternatives (move, rename). Usage is implied by the verb and semantics, but no exclusionary or comparative guidance is provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait by noting "including intermediate directories," which informs the agent that parent folders will be automatically created. There is no mention of error handling, but for a simple creation tool this is meaningful 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 extremely concise: a single main sentence followed by a minimal Args section. It is front-loaded with the core purpose, and every sentence earns its place without any 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?

For a simple tool with one parameter and no output schema, the description covers the essential elements: purpose, parameter, and a key behavioral detail. It is not exhaustive but adequate for the tool's complexity; missing details like behavior when the folder already exists are not critical here.

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 only the parameter name and type (0% coverage). The description compensates by explaining that 'path' is the path to create and provides a concrete example ("/Documents/NewFolder"), giving the agent a clear sense of the expected format.

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 ("Create") and resource ("folder"), and explicitly mentions "including intermediate directories," which clearly distinguishes it from other operations like copy, move, or upload. The purpose is unambiguous and directly tied to the tool's name.

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

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

The description clearly states what the tool does, which implies when to use it (when a folder needs to be created). However, it does not provide explicit exclusions or mention alternatives among the sibling tools, so it falls short of a perfect 5.

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 the key behavioral distinction: deleting without 'permanently' sends items to trash, while 'permanently=True' skips trash. However, it does not mention potential consequences like irreversible loss, permission requirements, or how folders are handled (e.g., recursive deletion), leaving gaps for a destructive operation.

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

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

The description is brief and well-structured: a one-line purpose followed by an Args block with two clear entries. No filler, repetition, or unnecessary detail.

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

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

The description covers the essential semantics of a two-parameter delete operation with no output schema. It clearly communicates the trash vs. permanent behavior, but could be enriched by explicitly addressing folder deletion and the relationship to trash management tools like empty_trash and restore_from_trash.

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?

With zero schema description coverage, the description compensates well. 'Path' is given a concrete example, and 'permanently' is defined as 'skip trash and delete permanently with Default False', adding meaningful context beyond the schema's type and default.

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 opening line 'Delete a file or folder' is a specific verb+resource statement that clearly distinguishes this tool from siblings like copy, move, or rename. The parameter details reinforce the delete action without ambiguity.

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 such as list_trash, restore_from_trash, or empty_trash. It does not mention the default trash behavior as a usage consideration or explain how this tool fits into the trash lifecycle.

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

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

With no annotations, the description carries the full burden. It accurately indicates a read-only operation via 'Get,' but does not disclose authentication needs, rate limits, or return format. For such a simple tool, this is acceptable but not thorough.

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

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

The description is a single, front-loaded sentence with no redundant words. It earns its place perfectly.

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 (no parameters, no output schema), the description is complete enough to understand the tool's purpose. It does not explain auth or response details, but those are not strictly necessary for this trivial read-only operation.

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

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

The tool has zero parameters, so the description has nothing to add. Per the baseline for zero-parameter tools, a score of 4 is appropriate since the schema is trivially complete.

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

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

The description clearly states the verb 'Get' and the resource 'Yandex Disk quota and usage information,' making it immediately distinguishable from sibling tools that handle files, uploads, or trash operations.

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 explicit when-to-use guidance or alternatives are provided, but the purpose is self-evident: to check disk quota/usage. Since no sibling tool serves this function, the usage context is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly notes that the deletion is permanent, indicating irreversibility. However, it does not mention any additional side effects or requirements, though for this simple operation the key risk is adequately communicated.

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

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

The description is a single, concise sentence that uses precise language ('Permanently delete all files in Trash') with no redundant or irrelevant 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?

Given the tool's simplicity (no parameters, no output schema), the description fully captures what the tool does. The permanent and destructive nature is clearly stated, making it complete enough for an agent to select and invoke correctly.

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

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

The tool has zero parameters, and the input schema is empty, so there is no parameter ambiguity. The baseline for no params is 4, and the description does not need to explain parameter details.

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 (permanently delete) and the target resource (all files in Trash). It is specific and distinguishes the tool from siblings like list_trash and restore_from_trash, which serve 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 the use case (cleaning out the trash permanently) but does not explicitly state when to use this tool versus alternatives like restore_from_trash. No exclusions or alternative recommendations are provided, but the context is minimally sufficient.

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

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

Without annotations, the description carries the full burden of behavioral disclosure. It mentions the URL is 'temporary,' which is a useful trait. However, it does not explicitly state that this is a read-only operation, nor does it describe what happens if the path does not exist or whether special permissions are required. The verb 'get' implies safety, but the description does not elaborate.

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

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

The description is extremely concise, consisting of a single declarative sentence followed by one line of parameter explanation. It front-loads the core purpose and contains no filler or redundant information.

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

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

The tool has no annotations and no output schema, so the description must convey return value behavior and constraints. It successfully notes the URL is temporary, but it does not specify the response format, error handling, or whether the path must point to an existing file. For a simple single-parameter tool, this is minimally adequate but leaves some gaps.

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 description's Args section explains 'path' as 'Path on Yandex Disk (e.g. "/Documents/report.pdf")'. This adds substantial meaning beyond the input schema, which only labels the parameter 'path' as a string. The example clarifies the expected format and semantic context, fully compensating for the 0% schema description coverage.

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

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

The description clearly states the tool's purpose: 'Get a temporary direct download URL for a file.' The verb 'get' plus the specific resource 'temporary direct download URL' makes the action unambiguous and distinct from sibling tools like list_files or upload_local_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?

There is no guidance on when to use this tool versus alternatives. The description does not mention circumstances that would favor this over list_files, get_metadata, or publish, nor does it provide exclusions or prerequisites. The phrase 'temporary direct download URL' only implies usage for obtaining a link, but no explicit direction is given.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It implies a read-only operation via 'Get' but does not mention potential errors, return format, permissions, or any side effects. This is minimal 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 compact, front-loaded with the core purpose, and includes only necessary parameter details. The one-line argument explanation with example is efficient and without waste.

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

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

With no output schema and no annotations, the description should explain what metadata is actually returned. It only says 'get metadata' without specifying fields, format, or behavior, leaving important information missing for such a 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 schema only defines 'path' as a string with no description (0% coverage). The description compensates by explaining the path is on Yandex Disk and providing a format example, adding meaningful semantics beyond the schema.

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

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

The description clearly states 'Get metadata for a file or folder' followed by a concrete path example, which specifies the verb, resource, and scope. It does not explicitly differentiate from sibling tools like list_files or disk_info, so it stops short of 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?

There is no guidance on when to use this tool versus alternatives such as list_files or search_files. The description only states the operation, not the context 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 burden. It discloses that path and limit apply to sub-folders and listing, but doesn't describe the return format or error behavior. Core behavior is understandable but not fully transparent.

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

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

The description is economical: one purpose sentence plus three parameter lines. No redundant information; every line is instructional.

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?

With no output schema, the description should elaborate on return values. It says 'Get information' and hints at folder listing via path/limit, but doesn't explicitly state what the response contains (metadata, file list, etc.). This is a clear gap for a moderately complex 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 description includes an Args section explaining each parameter: public_key (key/URL), path (sub-path within folder), limit (max items for folder). This adds meaning beyond the schema's sparse titles and defaults, compensating for 0% schema description 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 states 'Get information about a public resource by its public key or URL' with a specific verb and resource type. It doesn't explicitly distinguish from siblings like get_metadata, but the 'public resource' qualifier adds some 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 implies usage when you have a public key or URL, but offers no explicit guidance on when to use this tool vs alternatives, nor any exclusions. The context of sibling tools is not addressed.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'check the status,' which implies a read operation but does not explicitly state that it is read-only, what statuses are returned, whether it polls, or any error behavior. Minimal transparency is provided.

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

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

The description is concise and well-structured. It opens with the purpose in one sentence, then includes a brief Args section with a clear description of the parameter. Every sentence earns its place with no redundancy or fluff.

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

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

The tool is simple but has no output schema and no annotations. The description explains what it does and the parameter, but does not describe the return value, possible statuses, or how to interpret the result. This leaves the agent without essential context for handling the output, making it incomplete for a status-checking tool.

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

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

The input schema only specifies job_id as a required string. The description adds meaningful context by stating it is 'the job ID returned by upload_local_file_background,' which clarifies the origin and purpose of the parameter. This is valuable given the 0% schema description coverage.

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

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

The description clearly states the tool checks the status of a background upload and explicitly references the initiating function, upload_local_file_background. This makes the purpose specific and distinguishes it from general status tools. However, it does not explicitly differentiate from the sibling tool list_upload_jobs, which could also relate to upload status.

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 after upload_local_file_background by mentioning the job ID from that function, providing clear context. However, it does not explicitly state when to use this tool over alternatives like list_upload_jobs, 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.

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 makes the read-only nature evident through 'List' and explains pagination with offset and limit. However, it does not disclose potential errors, permission requirements, or whether the listing is direct-children-only or recursive.

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 tightly structured docstring with a front-loaded purpose sentence followed by a clear parameter list. Every line earns its place, and it avoids fluff while covering all key details.

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 output schema exists and the tool is a straightforward directory listing, the description covers the essential context: path, pagination, and sorting. A small gap is the lack of explicit mention that only direct children are listed, but the phrasing 'at the given path' implies this.

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?

With schema description coverage at 0%, the description thoroughly compensates by explaining every parameter: path with examples, limit range (1–100), offset for pagination, and sort field values including descending prefix '-'. This adds meaning far beyond the bare 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 opens with a clear verb and resource: 'List files and folders at the given Yandex Disk path.' It specifies path-based listing, which is distinct from siblings like list_recent_files or list_trash, though it does not explicitly name those alternatives.

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?

Usage is implied through the path parameter and listing semantics, but the description provides no explicit 'when to use this vs. search_files or list_recent_files' guidance. It does not state exclusions or mention when a different tool would be more appropriate.

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 discloses the scope ('entire disk'), the recency filter, and the limit range, which are useful. However, it omits behavioral details such as sort order, whether trashed files are included, and whether it is a read-only operation (though 'List' implies non-destructive).

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

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

The description is extremely concise, with one purpose sentence and one parameter explanation. Every word earns its place, and it is front-loaded with the core action.

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 tool with one parameter and an output schema, the description is nearly complete. It states the scope and parameter behavior. It could mention sorting order or whether it includes trashed files, but given the low complexity and existing output schema, it is adequately complete.

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

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

The schema only defines 'limit' as an integer with a default of 20, but the description's Args section adds the range (1–100) and meaning (Max number of files to return). This fully compensates for the 0% schema description coverage, though it doesn't explain the default value in more 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 starts with a specific verb ('List') and defines the resource ('recently uploaded files') with a clear scope ('across the entire disk'). This distinguishes it from sibling tools like list_files (which likely lists all files in a context) and search_files (which searches by query).

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

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

The description provides clear context: use this tool to get recently uploaded files across the entire disk. It does not explicitly name alternatives or exclusions, but the purpose is specific enough that an agent can infer when to use it. No 'when not to use' guidance is given.

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 disclosure burden. It only states the action and args, but does not describe the return format, whether it reads-only (though implied), or any edge cases like empty trash or pagination behavior. This is minimal for a tool with zero annotation support.

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 exceptionally concise: one sentence for purpose and two lines for args. Every word earns its place, and it is well-structured with an 'Args' section.

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 only two optional parameters, and an output schema exists (so return values need not be described). The description covers the core purpose and parameter semantics sufficiently, but it could have mentioned that trash items can be restored or permanently deleted via sibling tools for richer context.

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 description adds meaningful details beyond the schema: it specifies limit as 'Max items to return (1–100)' and offset as 'Offset for pagination,' including a range not present in the schema. Since schema coverage is 0%, this compensation is valuable.

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 'List files in the Trash.' with a specific verb and resource, and the 'Trash' scope distinguishes it from siblings like list_files and list_recent_files. It is precise and unambiguous.

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

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

The usage context is implied by the name and description (listing trashed files), but there is no explicit guidance on when to use this tool versus alternatives like list_files or search_files, nor 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.

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

No annotations are provided, so the description carries the full burden. The word 'List' implies a read-only operation, but there is no mention of whether it includes only active jobs or also completed ones, and no details about ordering, pagination, or other behavioral nuances. Minimal but adequate for a simple listing tool.

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

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

The description is a single sentence, extremely concise, and contains no filler or redundant wording. Every word earns its place.

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

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

For a zero-parameter listing tool with an output schema present, the description is nearly complete. It states the resource and what is included (statuses). It could benefit from clarifying whether it includes all historical or only in-progress jobs, but given the output schema, the agent can infer the return shape. This is a minor gap.

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 the baseline is 4. The description mentions 'all' which defines the scope, but there is nothing else to add beyond the schema since no parameters exist. It adds no contradictory or misleading information.

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 'List' and clearly identifies the resource 'background upload jobs' and includes 'statuses' as part of the result. It distinguishes itself from the sibling tool 'get_upload_status' by the scope ('all' vs. a single job's status).

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

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

The description clearly conveys that this tool lists all background upload jobs, which contrasts with the sibling 'get_upload_status' that implies a single job status. While it doesn't explicitly state 'use this to see all jobs', the 'all' wording and sibling context make the usage clear.

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

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

There are no annotations, so the description must disclose behavioral traits. It mentions the overwrite parameter but omits key details such as the source being removed, what happens if the destination exists without overwrite, or whether the operation is reversible.

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 very concise, with a single sentence for purpose and a compact list of arguments. There is no redundancy, but it could be slightly more detailed on behavior without becoming verbose.

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 mutating tool with no output schema and no annotations, the description is minimal. It does not explain the return value, the fate of the source, or failure conditions, leaving important gaps for an agent to guess.

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 has no descriptions, but the description's Args section explains all three parameters with examples for src and dst and a clear semantic for overwrite. This compensates well for the lack of schema descriptions.

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 that the tool moves a file or folder, using the verb 'move' with the resource 'file or folder'. It is distinct from sibling tools like copy and rename, which have different 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 provides no guidance on when to use this tool versus alternatives like copy or rename. It simply states the action without conditions, 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?

With no annotations, the description carries the full burden. It discloses the primary outcome (returning a public URL) and implies the resource becomes publicly accessible, but it omits side effects, permissions, reversibility, and error behavior.

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

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

The description is exceptionally concise: one sentence stating purpose and a single-line parameter explanation. Every word earns its place, and the structure is immediately scannable.

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 tool with one parameter and no output schema, the description covers purpose, parameter, and return value. It could improve by noting how to undo publication or handle already-published resources, but current coverage is nearly sufficient.

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 only a name and type for the single parameter, but the description adds full meaning with an explanation and a concrete example path, completely compensating for the lack of schema-level 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 uses a specific verb ('publish') and resource ('file or folder') and clearly states the outcome (return its public URL). This distinguishes it from sibling tools like unpublish and get_public_resource.

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 the tool: when you need to publish a file/folder and get a public URL. It does not explicitly mention alternatives or exclusions, but the context is clear.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It adds useful context that the tool moves the item within the same directory, but it does not explain behavior on overwrite, non-existent items, permissions, or result/return values. This is a moderate gap for a rename operation, but the provided context is helpful.

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

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

The description is extremely concise, consisting of a single purpose statement and a clear Args block with examples. Every sentence serves a purpose, and the structure is front-loaded with the tool's function. No unnecessary information is included.

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 simplicity of the tool (two required parameters, no output schema, no annotations), the description is fairly complete. It clearly explains the parameters and the same-directory constraint. However, it omits any mention of return values or error conditions, which would enhance completeness for an agent deciding whether to call this 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?

Schema description coverage is 0%, so the description is the only source of parameter meaning. It fully explains both parameters: 'path' as the full path with an example, and 'new_name' as the new name without a path with an example. This compensates entirely for the schema's lack of descriptions, providing clear semantics.

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

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

The description clearly states the tool's purpose with a specific verb and resource: 'Rename a file or folder'. It also adds the scope constraint 'moves it within the same directory', which distinguishes it from the sibling tool 'move' for cross-directory moves. This is a clear, non-tautological statement of what the tool does.

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

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

The description implies usage by stating the rename operates within the same directory, but it does not explicitly mention when to use this tool versus alternatives like 'move' or 'copy'. No clear exclusions or alternative tool references are provided. Usage context is only implied, not stated.

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 explains destination defaulting and overwrite behavior, but does not disclose side effects like removing the item from Trash, failure conditions, or permission requirements.

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

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

The description is compact and efficiently structured: a one-sentence purpose followed by a short, focused parameter list. Every line adds useful information with no 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 relatively simple restore operation, the description covers the action and all parameters clearly. It lacks some behavioral details like return values or conflict handling specifics, but it is sufficiently complete given the tool's scope.

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 description adds substantial meaning beyond the bare schema: it explains path format with an example, notes destination is optional and falls back to the original path, and clarifies the overwrite flag's purpose. This fully compensates for the 0% schema description 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 starts with a specific verb and resource: 'Restore a file or folder from Trash.' This clearly identifies the operation and distinguishes it from sibling tools like list_trash, empty_trash, and delete.

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 context implies that this tool is used for items already in Trash, but there is no explicit guidance on when to choose this over related tools like empty_trash or delete. No alternatives or exclusions 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 full burden of behavioral disclosure. It discloses the name-based search constraint and documents parameter limits, but it does not explicitly state that this is a read-only operation, nor does it describe the return format or any side effects. This is adequate but not extensive.

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

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

The description is concise and well-structured, with a clear one-sentence purpose followed by a bulleted list of parameters. Every sentence earns its place 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?

Given the tool's simplicity and the presence of an output schema, the description covers the core functionality and parameter details well. It lacks some context such as search scope (all disk vs specific folder), but it remains sufficiently complete for an AI 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?

The description adds significant meaning beyond the schema by explaining each parameter: query, limit with its allowed range (1–100), and media_type with its full list of accepted values. Since schema description coverage is 0%, this is essential and well-executed.

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 ('search'), identifies the resource ('files on Yandex Disk'), and specifies the search method ('by name'), which clearly distinguishes it from sibling tools like list_files and get_metadata.

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

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

The description provides clear context for the tool's intended use (searching files by name), but it does not explicitly mention when to prefer this over sibling tools or exclude alternatives. It lacks explicit when-not guidance, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action 'Revoke public access' without any mention of side effects, required permissions, reversibility, or what happens if the resource is not currently published. This is a significant gap for a mutation tool.

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

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

The description is extremely concise: a one-line purpose statement and a brief Args section. Every sentence is useful, and the example for the path parameter is front-loaded. There is no redundant information or fluff.

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

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

For a tool with a single parameter and no output schema, the description covers the core purpose and parameter meaning adequately. However, it lacks any usage context or behavioral caveats (e.g., prerequisites like 'only works on currently published resources'). Given the simplicity, this is a minimally viable description but not complete enough to guide an agent in all situations.

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 only provides the parameter name 'path' with a title, and schema description coverage is 0%. The description compensates by defining 'path' as 'Path on Yandex Disk' and providing a concrete example ('/Documents/presentation.pdf'). This adds meaningful context beyond the schema, though it could be slightly more explicit about the path referring to the resource being unpublished.

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 action with a specific verb and resource: 'Revoke public access to a file or folder.' This distinguishes it from siblings like 'publish' (the opposite action) and 'get_public_resource' (reading public access). There is no ambiguity about what the tool does.

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 explicit guidance is provided about when to use this tool versus alternatives. The description does not mention when a file should be unpublished, whether it should only be used on previously published resources, or any alternative tools (e.g., 'publish' for opposite action). It leaves the decision entirely to the agent without context.

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

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

With no annotations provided, the description carries the full burden. It adds the http/https URL constraint and overwrite behavior, but does not disclose whether the operation is asynchronous, what it returns, or how errors are handled. This is moderate transparency for a mutation tool.

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

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

The description is a single clear sentence followed by a structured list of arguments. Every line earns its place, no fluff, and the main idea is front-loaded.

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

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

There is no output schema, so the agent cannot infer return values; the description does not mention whether it returns a job ID, succeeds silently, or throws errors. It also omits size limits or authentication details, leaving gaps for a mutation tool. However, it covers the basic usage adequately.

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 0%, so the description fully compensates by explaining each parameter: url specifies source and scheme, path gives an example, and overwrite explains the boolean's effect. It adds meaning beyond the raw schema, though it does not detail failure behavior when overwrite is false.

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 ('Upload') with a resource ('file to Yandex Disk') and the method ('by downloading it from a remote URL'). It clearly distinguishes itself from sibling tools like upload_local_file by specifying the remote URL source.

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

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

The description clearly implies this tool is for uploading files from a remote URL, giving context for when to use it. However, it does not explicitly mention alternatives or when not to use it, such as using upload_local_file for local files.

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 of disclosing behavior. It mentions 'blocking', a size threshold, and timeout risk. However, it does not describe return values or error handling, leaving a slight gap in transparency.

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

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

The description is concise and well-structured: a purpose statement, usage guidance, then a clean parameter list. Every sentence adds value, and key info is front-loaded.

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

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

The description covers purpose, usage, and all parameters, which is sufficient for a simple upload tool. It lacks explicit return-value or error-info, but given the tool's simplicity and no output schema, the completeness is strong but not perfect.

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 has zero descriptions for parameters, but the description explains local_path (absolute path), disk_path (destination with example), and overwrite (overwrite if exists). This fully compensates for the schema gap.

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 uploads a local file to Yandex Disk and specifies it is blocking, distinguishing it from the sibling upload_local_file_background. The verb 'upload' and resource are explicit and unambiguous.

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

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

It explicitly says to use for files under ~100 MB and directs users to upload_local_file_background for large files to avoid timeout. This provides clear when-to-use and alternative guidance.

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

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

With no annotations, the description carries the transparency burden. It discloses crucial behaviors: the upload starts and returns immediately with a job_id, it runs in the background, and it avoids timeout issues. This goes beyond the schema's parameter list. However, it does not mention failure scenarios (e.g., what happens if the local file is missing) or any job lifecycle limits, so it is not exhaustive, but it is adequate for an agent to anticipate the async flow.

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

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

The description is compact and well-structured: a one-sentence purpose, a statement of the immediate return behavior, a usage note, and a formatted arg list. Every line contributes value, and the key information is front-loaded. There is no fluff 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 the tool's async nature, the description provides the essential operational loop: start upload, get a job_id, and poll via get_upload_status. It also explains the parameters and the time-out rationale. Although there is no output schema, the description explicitly states the return value (job_id), making the contract clear. It is complete enough for an agent to use correctly without further research.

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 0%, yet the description fully compensates by explaining each parameter in the Args list: local_path is an absolute file path, disk_path includes a concrete example, and overwrite tells the agent what the boolean controls. This is far more informative than the schema's bare type/title entries, giving the agent exact semantic meaning and usage intent.

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 ('Start uploading') and identifies the resource ('a large local file to Yandex Disk') plus the key differentiator ('in the background'). It clearly distinguishes itself from the sibling 'upload_local_file' by noting the immediate return of a job_id and points to a complementary tool (get_upload_status). This leaves no ambiguity about the tool's purpose.

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

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

The description provides clear context for when to use this tool ('Suitable for files of any size — no timeout issues') and implies it is the background alternative to a synchronous upload. It also tells the agent to follow up with get_upload_status. However, it does not explicitly state when NOT to use it or name the synchronous sibling as an alternative, so it stops short of full exclusion guidance.

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