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

Annotations already mark the tool as read-only, and the description adds useful behavioral context beyond them: it identifies the underlying EVS endpoint, names the extra fields returned, and documents a practical limitation (bare root paths unsupported). This gives the agent realistic expectations for calling the 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 only two sentences, with the core function front-loaded and the prerequisite and limitation placed immediately after. Every clause adds information, with no filler or redundant restatement.

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 (2 fully documented params, read-only, no output schema), the description covers the critical invocation pitfalls: EVS path format and the need to discover roots via `list_files`. It names the added return fields but does not enumerate the full return structure, which is a minor gap for an output-schema-less 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 100% and both parameters are already documented with format examples and references to sibling tools. The description mostly restates the path-format constraint rather than adding substantial new meaning, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and object: 'Lists the files and folders backed up for a given device at a given path.' It distinguishes this tool from the sibling `list_files` by explicitly naming the richer EVS endpoint and the added fields (trash/checksum/live-image), so an agent can tell them apart without opening their schemas.

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 explicitly tells the agent to use `list_files` first to discover drive letters/roots and warns that a bare root path has never been observed working. It also contrasts this tool with `list_files` by field richness, giving a clear selection rationale, though it does not explicitly state the condition under which `list_files` should be preferred over this 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?

Discloses the mutation clearly with 'MUTATING' and 'modifies real backed-up data', and adds the observable consequence that the folder appears in subsequent listings, verified by live mutation testing. This goes beyond the annotations' readOnlyHint=false and destructiveHint=false by explaining what actually changes.

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 dense paragraph that front-loads the mutation warning, then explains behavior, evidence, and parameter constraints. Every sentence carries useful guidance 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 mutating tool with no output schema, the description covers the mutation effect, verification via subsequent listings, and parameter prerequisites. It does not describe error responses or permission requirements, but it gives enough context for correct invocation and post-call verification.

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%, but the description adds meaningful usage semantics: parentPath must be pre-existing and uses EVS path format, folderName is a plain name not a path, and deviceId comes from list_devices. These details prevent common invocation mistakes beyond the raw 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?

States a specific verb and resource: 'creates a new folder inside a device's live backup' via the EVS endpoint. It clearly distinguishes itself from sibling listing/reading tools like browse_folder and list_files, and from mutation tools like delete_file.

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

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

Provides explicit preconditions: parentPath must be an existing folder and the agent should use browse_folder/list_files first to confirm it exists. It also clarifies that folderName is a name, not a path. It stops short of naming alternative tools to use when not creating a folder, but the context is otherwise 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?

Annotations already declare destructiveHint=true, but the description adds substantial behavioral detail: batch deletion across all paths, immediate disappearance from listings, trash-vs-permanent behavior, visible per-path failure reporting, and the unverified nature of permanent deletion. It also explicitly records what was live-confirmed versus merely presumed, exceeding what the annotations provide.

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 dense but purposeful, with the destructive warning front-loaded and every sentence contributing either behavior, confirmation status, or a safety caution. The prose is structured so the most critical constraints appear first, followed by detailed caveats.

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 destructive mutation tool without an output schema, the description covers the critical operational context: trash default, permanent-delete uncertainty, recovery path, partial failure visibility, path format, and a live-testing reference. An agent has what it needs to invoke this safely and interpret broad behavior, even if exact response structure is not specified.

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 covers all three parameters with rich descriptions, and the tool description adds cross-cutting semantics such as 'single batch call across all of paths' and repeated p fields. It doesn't need to explain each parameter further, but the added batch/partial-failure context is genuinely useful.

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 'MUTATING, DESTRUCTIVE' and states a specific action: 'removes one or more files/folders from a device's live backup' via the named endpoint and batch semantics. It clearly identifies the resource and behavior, and the contrast with the sibling restore_from_trash prevents confusion.

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 explicitly explains default trash behavior, how to recover with restore_from_trash, and cautions to 'Always double-check paths before calling this, especially with permanent: true.' It also warns that permanent:true is unverified and should not be relied on until self-tested, giving an agent clear guardrails for when and how to invoke the 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?

Beyond the readOnlyHint annotation, the description discloses important behavioral details: it always writes to disk rather than returning inline, reports `{ path, bytesWritten }`, performs transparent Unicode normalization retries, and notes that the Content-Type header is unreliable. These are significant behavioral traits not visible from annotations or schema.

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 long but each sentence contributes: core behavior and rationale, prerequisite usage, a critical caveat about content type, and a non-obvious retry behavior. The key action and outcome are front-loaded before caveats, and nothing feels redundant or filler.

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

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

For a tool with no output schema, the description fully explains the return shape. It covers prerequisites, path handling caveats, delivery mechanism, retry behavior, and output semantics. The complexity introduced by the endpoint's quirks is well handled, leaving the agent with sufficient context 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?

The input schema already documents all three parameters at 100%, so the baseline is 3. The description adds extra meaning by explaining when the `path` may be retried under alternate Unicode normalization, emphasizing `destinationPath` is always required and never auto-chosen, and clarifying how to derive the file type. This goes modestly beyond the schema definitions.

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 action ('Downloads a backed-up file's actual content'), the exact endpoint, and the distinguishing behavior of streaming to a local file. It clearly differentiates this tool from sibling browsing/listing tools by emphasizing it retrieves file content rather than 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?

It explicitly instructs the agent to use `browse_folder` or `list_files` first to discover the file path, and warns that bare root paths should be resolved via `list_files`. This provides clear when-to-use guidance and routeing to sibling tools, satisfying the criterion for explicit usage direction.

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 explicitly warns that the set of keys is not stable across accounts and should be treated as a loose flag bag rather than a fixed schema, which is important non-obvious behavior. It does not fully describe the response container or error behavior, but the zero-parameter read-only nature reduces that need.

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, front-loaded with the core behavior, and every phrase adds value: the purpose, concrete examples, and the unstable-schema warning. There is no filler or repetition of schema information.

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

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

For a zero-parameter read tool with no output schema and no annotations, the description provides enough context to select and invoke it: it returns boolean feature flags, explains their purpose, and warns about schema instability. It could add a bit more about the exact return shape (e.g., object mapping flag names to booleans), but the warning partially covers that by calling it a 'loose flag bag'.

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 is empty with zero parameters, so parameter semantics are not applicable. The baseline for zero-parameter tools is 4, and the description appropriately focuses on what the returned flags mean rather than input 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?

Description states a specific verb ('Returns') and a concrete resource: boolean feature flags used to decide which product sections appear in the web console left nav. It also gives concrete examples (Remote PC, E2 object storage, 360 backup), making it clearly distinguishable from sibling account tools like get_account_usage or get_dashboard.

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 when to use this tool: when an agent needs to know which feature flags are enabled for an account, especially to understand UI section visibility. It does not explicitly name alternatives or exclusion conditions, but the unique purpose among siblings is clear, and no misleading usage signals are present.

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 does exceptionally well: it reveals the scraping mechanism, the fragility, the failure behavior ('fails with a clear tool error... rather than a crash or a guessed value'), the raw string return format with unit suffixes, and the unconfirmed semantic scope. This is far more transparent than typical tool descriptions.

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 sentences, front-loaded with the core functionality. Each subsequent sentence adds a distinct and decision-relevant caveat: the scraping mechanism and fragility, the raw string format, and the quota-naming ambiguity. There is no redundancy or filler; all content 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-param tool with no annotations and no output schema, the description covers everything an agent needs: what is returned, how the data is obtained, reliability risks, failure mode, data representation, and semantic ambiguity. The only minor omission is an example response, but the raw string examples ('0.00 KB', '5000.00 GB') already convey the format.

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 is empty and schema description coverage is 100%. With zero parameters, the description does not need to add parameter semantics. Rule baseline for 0 params is 4. The description does not attempt to explain nonexistent parameters, which 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 starts with a specific verb and resource: 'Returns the account's used and total Sync storage quota.' It also clarifies the exact naming scope ('Sync' quota, not total backup usage), which distinguishes this tool from sibling account-level tools like get_account_features and get_dashboard. The title reinforces the purpose with 'Get account storage usage (Sync quota).'

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 name alternatives or state when not to use the tool, but it provides strong contextual guidance: it explains that there is no dedicated JSON endpoint, so this tool scrapes the data from a page and is inherently fragile. This gives clear context for when an agent should rely on it and the associated risk. No explicit exclusions are given, so it falls 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 provided, the description carries the transparency burden. It clearly discloses that this is billing information only and does not return account/data content, which is useful behavioral context. It does not spell out side-effect safety, but 'returns' strongly implies a read-only operation and the content scope is clearly bounded.

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 front-loaded, with the main purpose in the first sentence and the boundary in the second. The reference to docs/api-map.md and 'Still needed from you' item 6 adds useful context but is slightly extraneous for tool invocation, keeping it from a perfect score.

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 tool with no output schema and no annotations, the description is complete: it states what is returned, what is excluded, and why. The content list (current plan, monthly/yearly price, promo code) gives the agent enough expectation to invoke and interpret the result 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, so the 0-param baseline of 4 applies. There is no parameter documentation needed, and the description correctly focuses on what the response contains.

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 names a specific verb and resource: returns iDrive's cloud-to-cloud product tier pricing/upsell info, including plan, price, and promo. It also draws an explicit boundary against connected cloud accounts and backed-up data, which distinguishes it from sibling tools like get_account_usage and get_dashboard.

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 exactly what the tool is for (pricing/upsell info) and clearly states what it is not for: listing connected cloud accounts or backed-up data. It even notes that no such endpoint has been discovered, preventing the agent from attempting an unsupported use.

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 takes full responsibility for exposing behavior. It honestly discloses that the response shape is unmapped and unconfirmed, that only one captured session exists, and that it returned an empty array — excellent transparency about uncertainty and non-contractual output.

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 waste: the first states what the tool returns, and the second sets critical expectations about reliability and schema stability. The uncertainty caveat is placed after the core behavior, which is the right order.

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 tool with no output schema, the description fully covers the return value's nature, its diagnostic purpose, and the risk that it may be an empty array. Nothing an agent needs to make a safe calling decision 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?

The input schema has zero parameters, so there is nothing for the description to document. The baseline of 4 applies because no parameter meaning is needed and the description adds no misleading parameter 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?

States a specific verb and resource: returns the raw JSON from iDrive's user dashboard endpoint. It clearly differentiates this from sibling tools by emphasizing the unmapped, raw payload rather than a structured, business-meaningful result.

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 diagnostic-only usage by telling callers to treat the result as opaque and not rely on fields, but it does not explicitly state when to use this tool instead of siblings like get_account_usage or get_server_version. Usage context is present but not fully developed.

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 destructiveHint=falce, so the read-only nature is covered. The description adds useful context beyond the annotations: the EVS endpoint identity, the UI dialog it mirrors, and the fact that the endpoint fetches size and last-modifed date.

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 tight sentences: the first states the core action and endpoint, the second gives a UI-equivalence anchor, and the third gives the necessary pre-step. Every sentence earns its place and the important action comes first.

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 read-only, two-parameter tool with no output schema, the definition is complete: it states what metadata is returned, where the path comes from, and how to discover it. The schema handles all parameter details, and annotations cover safety.

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%, and the schema already provides rich details for both path and deviceId, including path format examples and a caveat about bare root paths. The top-level description adds no extra parameter-level semantics, so the baseline of 3 applies.

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 ('fetches') and resource ('metadata for a single backed-up fyle or folder'), and identifies the exact endpoint. It does not explicitly contrast with sibling tools such as get_fyle_versions or download_fyle, but the metadata-focused scope makes its purpose clear.

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 tells the agent to run browse_folder or list_fyles first to discover the path, which is actionable pre-requisite guidance. It does not, however, provide explicit when-not-to-use or alternative-routing instructions among file-related siblings.

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?

Goes well beyond the readOnlyHint annotation by disclosing that a file with no prior versions returns a normal successful response with hasVersions:false, not a tool error. It also candidly states that the real version-list shape is unconfirmed, so raw JSON is passed through and fields should be treated as unstable until observed live.

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 front-loaded with the purpose and uses subsequent sentences for essential caveats about response shape and path discovery. It earns its length, though the path-discovery instruction is partially redundant with the schema description, preventing a perfect score.

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 read-only tool with no output schema, the description covers the confirmed no-version response shape, flags the unconfirmed version-list shape, and explains the raw JSON fallback. It also provides the prerequisite discovery step, making it complete for an agent to invoke correctly.

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

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

Schema coverage is 100%, and the input schema already documents both parameters thoroughly, including EVS path format and the source of deviceId. The description adds usage guidance about discovering paths but no additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Lists prior backed-up versions of a single file' via the evs/getVersions endpoint. It clearly differentiates this tool from siblings like browse_folder/list_files and download_file by focusing on version history retrieval.

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 explicitly instructs the agent to use browse_folder or list_files first to discover the path to query, and the schema description warns against bare root paths and directs to list_files. It does not explicitly contrast with other file operations, but the read-only version-listing 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?

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, and the description adds meaningful behavioral context beyond that: it names the exact reported values (package.json version, short hash, dirty-working-tree indicator, display string) and explicitly states the tool makes no API call. This goes well beyond what annotations alone convey.

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 four sentences with no wasted words. It front-loads the core purpose, then adds the motivating scenario, the version-bump caveat, and the API-call exclusion. Every sentence earns its place and the structure is easy to scan.

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, no-output-schema diagnostic tool, the description is complete. It fully specifies what the tool returns, why it exists, and what it deliberately does not do, so an agent has everything needed to invoke and interpret 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 tool has zero parameters, so parameter documentation is unnecessary; the baseline is 4. The description adds no parameter syntax but compensates by clarifying the exact nature of the returned diagnostic data, which is the only semantic content an agent needs.

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 and resource: 'Reports exactly which build of this MCP server is currently running.' It clearly distinguishes this tool from the sibling tools, which all concern iDrive account/file operations, by identifying this as server-level diagnostic 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 explains when to use it: to tell a stale, already-running server process apart from the current build because semver alone cannot distinguish them. It also gives an explicit exclusion: it is purely local diagnostic info and does not call iDrive's API, which differentiates it from the surrounding data-oriented sibling 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 establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context: the EVS endpoint, the prerequisite of a prior listing call, and the fact that there is no default or guessable timestamp. It does not describe the exact response body, but that is a minor gap for a read-only preview endpoint.

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 deliver the central behavior, endpoint, and the two critical constraints with no filler. The content is front-loaded and every clause adds necessary context.

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?

Together with the richly documented schema and readOnly annotation, the description gives an agent the prerequisites and constraints needed to call the tool correctly. The only missing piece is an explicit description of the response format (e.g., binary image vs URL), which is not present since there is no output schema.

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

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

The input schema already documents all three parameters at 100% coverage, including path format examples and timestamp provenance, so the description does not need to carry the burden. It reinforces the lmd_web requirement but does not add meaning beyond the schema. Baseline 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 names a specific operation ('Fetches a thumbnail preview image') and a resource ('a backed-up file'), and identifies the exact endpoint. It is clearly distinct from siblings like download_file and list_files because it targets preview images only.

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 tells the agent that path must be in EVS format and that timestamp must be the lmd_web value from a prior list_files or browse_folder call, adding the warning that a timestamp cannot be guessed. It does not explicitly compare against download_file or other alternatives, so it earns 4 rather than 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 transparently indicates a read-only listing operation and specifies the exact scope ('every device backed up under the authenticated iDrive account') and the fields included. It omits details like pagination or rate limits, but for a zero-parameter enumeration that is a minor gap.

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 front-loads the core action and resource, then appends the precise list of returned fields. Every word earns its place and there is no redundant or vague phrasing.

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 parameterless enumeration tool with an output schema present, the description is complete: it states scope, result fields, and the account context. There is nothing else an agent needs to know to invoke this 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?

The tool has zero parameters, so the schema already fully covers parameter semantics. The description goes beyond the schema by clarifying what data is returned for each device, which is useful context even though no parameters exist.

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 ('Lists') with a clear resource ('every device backed up under the authenticated iDrive account') and enumerates the exact data returned. It is immediately distinguishable from sibling file-focused tools like list_files or browse_folder.

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 when to use this tool: when an agent needs to enumerate all backed-up devices and their basic attributes. It does not explicitly name alternatives or exclusions, but the device-level scope makes the intended use unambiguous given the file-centric siblings.

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

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

The description discloses a non-obvious behavioral detail: transparent retry with alternate Unicode normalization (NFC vs NFD) when path contains accented characters, including the confirmed device context (Mac/APFS-sourced devices). This goes well beyond the annotations (readOnlyHint=true, destructiveHint=false) and materially helps the agent understand and trust a fallback mechanism that would otherwise be invisible.

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, front-loaded with the core purpose and followed by a dense but essential behavioral note. No filler or repetition of schema fields; every word contributes to understanding or safe invocation.

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 non-recursive list operation with clear annotations, the description covers the prerequisite (deviceId), the edge case (Unicode normalization), and the mental model (iDrive restore console). No output schema is provided, but the return value is reasonably inferable for such a listing tool, and the description does not leave an obvious gap for correct invocation.

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?

Although the input schema already documents all three parameters (100% coverage), the description adds meaningful context: path's accented-character handling during retries and deviceId's origin from list_devices. It reinforces what 'deviceId' means and adds a behavioral nuance for 'path' that the schema alone does not convey.

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 a specific action — 'Lists the files and folders backed up for a given device at a given path' — and identifies the resource as the device's backed-up file tree. It also differentiates from list_devices by naming that sibling as the source of deviceId, but it does not explicitly distinguish itself from the sibling browse_folder, which may overlap in 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: use this to browse a backed-up file tree at a given path, and explicitly instructs to use the sibling list_devices tool to obtain a deviceId. However, it does not mention when not to use this tool or cite alternatives such as browse_folder, so it stops short of a full usage-routing explanation.

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 indicate mutation, but the description adds meaningful context: it is a single batch call, it has been confirmed live against a real device, restored items reappear in `browse_folder`/`list_files`, and it only reverses a prior trash-move. It does not discuss potential conflict behavior at the original location, but this is a minor gap given the annotation coverage.

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 dense but not bloated, with the mutating flag and core action front-loaded. The caveats about known paths and live validation justify their length because they prevent incorrect calls. Minor redundancy exists between the endpoint name and the action description, but overall it is 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?

Given the rich input schema, annotations, and sibling context, the description covers the critical behavioral facts needed to call the tool safely: mutating nature, batch handling, prerequisite knowledge of paths, and observed effects. It does not spell out the return value shape, but the schema's per-path result note partially covers that, and no output schema exists.

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%, with each parameter already documented in detail. The description adds the batch-call behavior and the prerequisite that `paths` must be pre-known, but it does not need to restate parameter formats. This is the baseline case where the schema carries the semantic load.

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 precise action (restore trashed files/folders to original location), names the underlying endpoint, and clarifies batch scope across all `paths`. It clearly differentiates from the sibling `delete_file` tool by focusing only on undoing a prior trash-move.

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?

Explicitly says when to use it — after a trash-move with `delete_file` and `permanent: false` — and warns that there is no confirmed way to enumerate trash contents, so callers must already know `paths`. This gives actionable selection and exclusion criteria.

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