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

Annotations already indicate this is not read-only, so the description adds little about mutating behavior. It does not disclose what happens on conflicts, whether intermediate folders are created, how autorename interacts, or whether the source is preserved. No contradiction with annotations exists.

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, direct sentence with no filler or redundant elaboration. It is front-loaded and every word contributes to the basic 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 mutating tool with no output schema and an open-world annotation, the description is too sparse. It omits important context about conflict behavior, autorename semantics, and what the operation returns or changes, leaving the agent to guess about critical execution details.

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 no parameter-level meaning beyond the input schema. With schema description coverage at only 33%, the description should compensate for undocumented parameters like autorename, but it does not mention any parameters at all.

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 a specific verb ('Copy') and resource ('a file or folder') with a clear destination ('a new path'). It is unambiguous about what the tool does, though it does not explicitly distinguish itself from the sibling dropbox_move beyond the verb itself.

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 a file or folder should be copied to a new path. However, it gives no explicit guidance about when not to use it or when dropbox_move or other alternatives 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?

Annotations already disclose that this is a write operation (readOnlyHint=false), has external side effects (openWorldHint=true), and is not idempotent (idempotentHint=false). The description adds no additional behavioral context, such as conflict behavior, permission requirements, or side effects like recursive folder creation.

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 unnecessary words. It is front-loaded and avoids redundancy, making it optimally concise for a simple tool.

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 two parameters, the description omits critical details about behavior on folder existence, the effect of autorename, whether parent folders are created recursively, and error conditions. With no output schema and minimal annotation detail, this bare description is insufficient for an agent to use the tool correctly without guessing.

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 path parameter is well-documented in the schema with an example, but the autorename parameter lacks any description in both the schema and the tool description. With schema coverage at 50%, the description fails to compensate for the undocumented autorename parameter, leaving its semantics unclear.

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 'Create a folder at the given path' uses a specific verb and resource, clearly distinguishing it from sibling tools like move, copy, delete, and upload. The focus on 'folder' differentiates it from file 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?

The usage is implied by the tool's name and description, but there is no explicit guidance on when to use it versus alternatives (e.g., using upload for files). No exclusions or conditions are mentioned, making it a minimal viable guideline.

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 adds concrete behavior beyond annotations: 'If a link already exists for the path, the existing link is returned instead of erroring.' This clarifies the idempotentHint and aligns with readOnlyHint=false. It does not discuss external side effects, but there is no contradiction with the annotations.

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 sentences with no filler. The main purpose is front-loaded, and the second sentence adds valuable behavioral context. 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?

The description is adequate for basic invocation but leaves gaps: it does not state the return shape explicitly, nor whether audience/allow_download settings are updated when an existing link is returned. With no output schema, a bit more detail would make it 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?

Schema description coverage is 67%, with allow_download lacking any description. The tool description adds no parameter-level detail; 'for a file or folder' merely restates the path schema. It should have explained allow_download or clarified audience behavior but does not.

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?

States a specific verb and resource: 'Create a shareable link for a file or folder.' This clearly distinguishes the tool from siblings like dropbox_get_temporary_link and dropbox_list_shared_links, and the idempotency note adds important 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?

No explicit guidance on when to use this tool versus alternatives such as dropbox_get_temporary_link or dropbox_list_shared_links. The idempotency note implies it is safe to call even if a link exists, but it does not state 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?

The description goes beyond the destructiveHint annotation by explaining what actually happens: the item 'moves to deleted state' and 'can be restored from Dropbox for the retention window.' This gives the agent useful context about recoverability and the temporary nature of the deletion.

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 short sentences with no filler. The core action is front-loaded, and the destructive consequence is stated immediately after, making the most important safety information prominent.

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 one-parameter destructive tool with no output schema, the description covers the action, the scope (recursive deletion), the state change, and recoverability. This is sufficient for an agent to correctly select and invoke the 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 already fully documents the 'path' parameter with an example and root behavior. The description adds semantic value by clarifying that a folder path will delete its contents as well, which is not explicit in the schema 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?

States a specific verb ('Delete'), the target resource ('a file or folder'), and an important scope detail ('and its contents'). It is unambiguous and clearly distinguishes this tool from the sibling file/folder operations like move, copy, upload, and list.

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 purpose itself defines when to use the tool: when a file or folder should be removed. It does not explicitly discuss alternatives, but none of the sibling tools perform deletion, so no exclusionary guidance is needed. The destructive warning reinforces that this is the deletion tool.

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?

Annotations already declare readOnlyHint and openWorldHint, so the read-only nature is established. The description adds behavioral context by specifying exactly what 'authenticated account' includes and ties it to connection verification, which is beyond the structured annotations.

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 with the return payload front-loaded and the use case in the second sentence. There is no filler or repetition of the title, making it efficient 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?

For a simple, parameterless, read-only tool, the description is complete: it names the fields returned, the use case, and the operational context. Although there is no output schema, the description fills that gap by enumerating the expected fields.

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?

This tool has zero parameters, and the schema coverage is 100% (empty schema). The baseline for zero-parameter tools is 4; the description appropriately avoids inventing parameter details and focuses on the call's purpose.

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 ('Return') and resource ('authenticated account') and enumerates the fields returned (name, email, account id, team). This clearly differentiates it from the sibling file/folder tools, leaving no ambiguity about its 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?

It gives an explicit use case: 'Good for confirming the server is connected to the right Dropbox.' It does not explicitly name alternatives or exclusion criteria, but the sibling set makes it obvious that this is the account-inspection tool, and the guidance is sufficient for a zero-parameter call.

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?

Annotations already declare readOnlyHint=true, so the description isn't responsible for that. It adds the specific fields returned (size, modified time, id), but does not disclose behavior around deleted items or error handling. It provides minor added context beyond annotations.

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 entire description is one short sentence that immediately states the action and resource, then gives illustrative fields. No filler, appropriately sized.

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 read-only metadata tool, the description covers the core purpose but omits the include_deleted parameter and its effect. With no output schema, some indication of return format would be helpful, but it's not critical. Overall, it's adequate but has 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?

Schema description coverage is 50% (path is documented, include_deleted is not). The description adds no parameter information, failing to explain the purpose of include_deleted. It does not compensate for the missing schema documentation.

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?

States a specific verb 'Get' and resource 'metadata' for a single file or folder, distinguishing it from list_folder which enumerates contents. Also lists example fields, making the purpose 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 phrase 'for a single file or folder' gives clear context that this tool is for a specific path, not a listing operation. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full 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?

Annotations already provide readOnlyHint=true and openWorldHint=true, covering the safety profile. The description implies the URL must already exist but does not disclose error behavior or what specific metadata is returned. It adds minimal behavioral context beyond annotations, but does not contradict them.

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 front-loaded with the action and resource. There is no wasted wording, and it communicates the essential purpose immediately.

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 one-parameter read-only tool with no output schema, the description is adequate. It doesn't enumerate return fields, but the tool name and context make the purpose clear. Annotations cover safety, so nothing critical is missing.

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% — the 'url' parameter has a description. The tool description's mention of 'existing' adds a slight constraint (the link must already be valid), but otherwise it adds little beyond what the schema already provides. 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 states a specific verb ('look up') and resource ('metadata for an existing shared link URL'), which clearly distinguishes it from siblings like create, list, or revoke shared links. It is not a tautology and uniquely describes the tool's function.

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 given on when to use this tool versus alternatives such as dropbox_list_shared_links (to list links) or dropbox_get_temporary_link (to get a temporary download URL). The description only states the action, leaving the agent to infer selection criteria.

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?

Annotations already declare readOnlyHint=true, so the operation is known to be safe. The description adds only the scope ('for the account') and the fact that it returns both usage and allocation, but does not disclose any additional behavioral nuances (e.g., rate limits, quota details, or potential variability in returned fields). Since annotations cover the main safety trait, a 3 is appropriate.

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

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

The description is a single, efficient sentence that contains no unnecessary words. It leads with the verb 'Return' and immediately states the resource and scope, making it easy for an agent to parse quickly.

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, parameterless read-only tool, the description is nearly complete. It names the return content (storage usage and allocation) and the scope (account). It does not explicitly enumerate the fields of the response (no output schema exists), but the high-level description suffices for an agent to understand what the tool provides. A 4 reflects that slight lack of detail while recognizing the tool's simplicity.

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 takes zero parameters, so the description has no parameter-level burden. The schema is empty and fully documented by that fact, and the description correctly focuses on the return value rather than inputs. Baseline 4 for a parameterless tool holds.

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 a clear, specific verb ('Return') and a well-defined resource ('storage usage and allocation') scoped to 'the account'. It is easily distinguishable from sibling tools like dropbox_get_current_account, which returns account identity details rather than quota/space information.

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 an agent needs account storage/quota information, but does not explicitly state when to use this tool versus siblings. There are no direct exclusions or alternative routing, though the purpose is unambiguous enough that an agent would not confuse it with other file/account 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?

Annotations already declare readOnlyHint=true, and the description adds useful behavior: the URL expires in roughly 4 hours, is direct, and supports download/streaming. This goes beyond the annotation by clarifying the temporary nature and the fact that no permanent shared link is created.

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 sentences with no filler. The core action and key constraint (time-limited URL) are front-loaded, and every clause adds relevant guidance.

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 single-parameter read-only tool, the description is complete: it names the resource, the purpose, the temporary nature, and the distinction from permanent links. With no output schema, the phrase 'Get a direct ... URL' also conveys the return value sufficiently.

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 path parameter is fully documented in the input schema. The tool description does not need to repeat it; it only adds the context that the path refers to a file. This meets the baseline without adding significant new parameter meaning.

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 ('Get') and a precise resource ('direct, time-limited (~4h) download/streaming URL for a file'). It clearly distinguishes this from permanent shared links, which is relevant given siblings like dropbox_create_shared_link, dropbox_list_shared_links, and dropbox_get_shared_link_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 states when to use it: 'reference or fetch file contents without creating a permanent shared link.' This gives clear context and implicitly excludes permanent-share scenarios, though it does not explicitly name alternate tools or list when-not-to-use conditions.

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?

Beyond readOnlyHint and openWorldHint, the description discloses pagination/truncation behavior and recursion semantics. It does not cover output item shape or ordering, but the annotations already cover safety and the added behavioral traits are useful.

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 short sentences, front-loaded with the action, with no filler. Every sentence contributes actionable guidance.

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?

Covers core invocation, root handling, recursion, and pagination. Missing return item shape and limit semantics, but given the annotations and the simplicity of a list operation this is largely 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 description explains the non-obvious semantics of path (root), recursive (walk subfolders), and cursor (continuation after truncation). limit is not explained in prose, but its name and min/max constraints make its purpose reasonably inferable.

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?

States a specific verb ('List') and resource ('contents of a folder'), and clarifies root and recursion. This clearly distinguishes it from siblings such as dropbox_get_metadata or dropbox_read_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?

Provides explicit how-to guidance: root path, recursive=true, and cursor for truncated results. It does not explicitly name alternatives or when not to use it, but the context is clear enough for an agent to select it for folder listing.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, which the description aligns with. The description adds the pagination behavior via cursor, going beyond the annotations and helping the agent understand the iteration pattern. It does not detail the response format, but that is a minor gap given the read-only nature.

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 sentences with no filler. It leads with the action, then adds the optional path and the pagination mechanism. Every clause contributes to the agent's understanding.

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 with no required parameters, the description covers the main behavior and pagination. It omits the return value structure, but given the absence of an output schema and the read-only annotation, this is acceptable yet not fully complete. The optional path semantics are adequately implied.

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 50% (only 'path' is described). The description compensates by explaining 'optionally for a specific path' and 'Paginates via cursor', which gives meaning to the cursor parameter that the schema leaves undocumented. This adds value 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 states a clear verb-resource pair: 'List existing shared links', with an optional path qualifier and a note on pagination. It distinguishes itself from siblings such as create_shared_link and get_shared_link_metadata by focusing on enumeration, and the title reinforces the action.

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 describing the action and optional path filter, but it does not provide explicit when-to-use vs. alternatives or exclusions. It mentions 'optionally for a specific path' and pagination, which gives context, but no direct guidance on when to prefer this over other list tools.

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?

Annotations already mark this as a non-read-only, non-idempotent operation, and the description confirms the move semantics. However, it does not disclose edge-case behaviors such as failure when the destination exists without autorename, or what happens to shared links/source data.

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 with no redundant wording. It efficiently captures the core operation without 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 is adequate for a simple file operation, especially with a fully documented schema and mutation annotations. However, there is no output schema and no guidance on return values, conflict behavior, or when move should be preferred over copy/delete.

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 100% parameter description coverage, including the rename semantics of to_path and the autorename behavior. The tool description adds no additional parameter-level meaning beyond what the schema already provides.

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 specific verbs 'Move or rename' and clearly states the resource type ('file or folder') and the operation direction ('from one path to another'). This is distinct from sibling tools like dropbox_copy or dropbox_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 description implies the tool is for relocating or renaming items, but it does not explicitly state when to use this tool versus dropbox_copy, which is a likely alternative. There is no exclusions or 'when-not-to-use' guidance.

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

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

The description adds valuable behavioral context beyond the readOnlyHint annotation: it returns UTF-8 text, enforces a size guard (DROPBOX_MAX_READ_BYTES, default 5 MB), and points out the large/binary file limitation. This is precisely the kind of runtime behavior an agent needs to know.

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 front-loaded: the action and return type come first, followed by the size guard and the alternative-tool routing. Every sentence earns its place and no filler is present.

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 one-parameter tool with a fully described schema, the description covers the output format, the size limitation, and the appropriate alternative for unsupported files. No critical operational context is missing.

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 schema already documents the path parameter thoroughly, including an example and the empty-string root convention. The description itself does not add further parameter-level detail, 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 the verb ('Download and return contents as UTF-8 text') and the resource ('a file'), with concrete use cases like docs, notes, code, and csv. It also distinguishes itself from the sibling dropbox_get_temporary_link by emphasizing text retrieval versus link creation.

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 names the alternative tool for large or binary files — dropbox_get_temporary_link — and provides the condition that should trigger that alternative. This gives an agent clear routing guidance for when this tool is and isn't 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?

Annotations already mark this as destructive and idempotent. The description adds behavioral context by specifying what gets destroyed: the URL's ability to grant access. It does not contradict annotations and clarifies the consequence of the destructive action, though it stops short of stating permanence or reversibility.

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 that fronts the action and the effect with no filler. Every word contributes to understanding, making it highly efficient.

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 one-parameter destructive operation with annotations covering destructiveness and idempotency, the description is largely complete. It lacks only details about return value or behavior on invalid URLs, which are not covered by schema or output schema, but these are minor for this tool's simplicity.

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% and the single parameter 'url' is already described as 'The shared link URL to revoke.' The description's reference to URL adds no new format, validation, or example information, so it stays at the baseline for fully covered 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 ('Disable') and resource ('shared link') and states the concrete consequence ('URL no longer grants access'). It clearly distinguishes from sibling tools like dropbox_create_shared_link, dropbox_list_shared_links, and dropbox_get_shared_link_metadata, which cover creation, listing, and metadata rather than revocation.

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 purpose statement implies the use case (when a shared link should be disabled), but it does not explicitly state when to use this tool, when not to, or mention alternatives. There are no exclusion conditions or routing to sibling tools, so guidance is only implicit.

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?

Annotations provide readOnlyHint=true and openWorldHint=true, indicating a safe, read-only operation. The description adds valuable behavioral context beyond these annotations: it reveals that content is searched 'where indexed' and explains the pagination protocol with 'has_more' and 'cursor'. These details inform the agent about result continuation and content matching, which the annotations do not cover. No contradiction with annotations.

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

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

The description is three concise sentences with no fluff. The main action is front-loaded, and the scoping and pagination details are provided efficiently. Every sentence contributes meaning: purpose, optional scoping, and continuation handling.

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 6 parameters and only 1 required, the description covers key nuances: content search, folder scope, and pagination. It does not describe the exact response structure, but the mention of 'has_more' and 'cursor' implies the output format. Given the read-only annotations and schema coverage, the description is largely complete for an agent to call the tool correctly, though a note on result contents could make it fully 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?

Schema description coverage is high (83%), so the baseline is 3. The description adds extra meaning by clarifying the query behavior ('where indexed'), the path scope ('Optionally scope to a folder'), and the cursor usage ('call again with the returned cursor'). These enrich the parameter definitions beyond the schema descriptions, particularly for path and cursor.

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 explicitly states 'Search the account for files and folders matching a query' – a specific verb and resource. It distinguishes itself from siblings like list_folder by specifying a global search across the account with optional folder scoping. The phrase 'filename and, where indexed, content' clarifies the scope of matching, leaving 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?

The description implies usage by describing the search behavior and optional folder scope, but it does not explicitly contrast with alternatives like list_folder or get_metadata. There is no 'use this when' or 'instead of' guidance. However, the context of searching across the account and pagination hint at when it is appropriate, so the usage 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?

Beyond the annotations, the description discloses that larger local files are automatically streamed via an upload session, which is non-obvious and useful. It does not contradict the readOnly/idempotency hints and does not need to restate the write side effect already implied by readOnlyHint=false.

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 tight sentences that lead with the primary purpose and then pack the two most important behavioral details. No filler or repetition of schema descriptions.

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 5-parameter upload tool with no output schema, the description plus schema covers the essential input modes, conflict behavior via mode, and large-file handling. It could mention return behavior or parent-folder creation, but these are not blocking for an agent to call the tool 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?

With 80% schema coverage, the schema already documents most parameters; the description adds the crucial 'either text or localPath' relationship and the automatic chunking threshold, which are not encoded in the schema. It leaves autorename underexplained, but that parameter also lacks an in-schema description, and the added context 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 opens with 'Upload content to a path', a specific verb and resource, and clearly distinguishes the tool from read/list/delete siblings by its write intent. It also clarifies the two input forms (text or localPath), leaving 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?

The description gives clear direction on when to choose inline text versus a local file and explains the ~140 MB threshold for single vs. chunked uploads. It does not explicitly name alternative sibling tools or state when not to use upload, but no other sibling performs uploads, so the guidance is sufficient.

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