CloudBridge

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

Annotations already declare idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description contributes the dual semantics — cancelling a running transfer versus hiding a finished one from history — which explains why the tool is non-destructive, but it does not say what happens to partial data, whether cancellation is reversible, or what the caller gets back.

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 short sentence with the primary action first and the secondary mode parenthesized, so nothing is wasted. It is terse to the point of leaving behavioral details unstated, but that is a completeness gap rather than verbosity.

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 mutation tool with no output schema, the definition covers the two intents but leaves the mechanics opaque: no return/error behavior, no note on what state the transfer ends in, and no explanation of the id. Adequate as a minimum, not sufficient for confident 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?

Schema description coverage is 0% and the single parameter has no description, so the definition must carry the meaning itself. It only implies the parameter through the noun 'перенос'; it never says which identifier is expected or where to obtain it. One obvious required integer keeps this from being a 1.

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 ('остановить' / stop) and resource ('перенос' / transfer), and adds a second, non-obvious mode ('скрыть завершённый из истории' / hide a completed one from history). This clearly separates it from create_transfer, get_transfer and list_transfers, which appear only implicitly through the shared resource name.

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

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

Two usage situations are stated: an in-flight transfer and a completed one. There is no guidance on edge cases — what happens when the transfer is already cancelled, when it is pending rather than running, or whether some other sibling (e.g. list_transfers) should be called first to obtain the id.

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 openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is partly covered; the description adds meaningful behavior on top by identifying that the output is publicly reachable, that access can be gated with `password`, and that links expire via `ttl_days`. It does not state what happens when ttl_days is omitted (permanent link?) or what the call returns, which keeps it below a 5.

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 core action followed by a compact, semicolon-delimited enumeration of modes, and no sentence is filler. The dense punctuation and the trailing backticked parameter list are slightly less scannable than a structured layout, but nothing is wasted.

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 12-parameter creation tool with no output schema and no parameter-level documentation, the description covers the mode-specific wiring well but omits the side parameters (name, size, mime_type) and says nothing about the returned link or error conditions. It is adequate to invoke the common cases but not complete for the whole surface.

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

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

Schema description coverage is 0% across 12 parameters, so the description carries the full burden and largely succeeds: it assigns semantics to kind, key, path, connection_id, target_connection_ids, download_id, password, ttl_days and title. The remaining parameters (name, size, mime_type) are left unexplained, so a handful of fields are undocumented in both places.

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 resource ('Создать публичную ссылку') and then disambiguates the three modes it can produce (file / inbox / archive). An agent can distinguish it from list_share_links and revoke_share_link purely from this text, since those names clearly cover listing and revocation rather than 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?

The description gives clear per-mode context by binding each kind value to the parameters it needs ('file' → connection_id + key or path from list_files; 'inbox' → connection_id + optional target_connection_ids; 'archive' → download_id), which functions as when-to-use guidance among the modes. It stops short of stating what not to use it for (for example private transfers via create_transfer) or any prerequisite checks.

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 honestly discloses that 'mirror' deletes extra files on the target and that 'update' overwrites changed files, plus that auto_retry requires a paid plan and the job runs in the background. That directly conflicts with the supplied destructiveHint=false, so an agent trusting the annotation alone could invoke mirror mode without warning the user; the disclosure is correct, the annotation is not.

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, front-loaded with the operation and its background nature, then parameter guidance in the order an agent needs it. The uppercase warning on mirror deletion is well placed and no sentence is 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 an 8-parameter asynchronous job with a nested `entries` object and no output schema, the description covers the essential call mechanics and the async hand-off to get_transfer. It is only incomplete on the unmentioned `exclude` filter and the unexplained 'new' sync mode.

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 0% schema description coverage the description carries the full burden and mostly succeeds: it explains `paths` (relative, empty/[''] = whole storage), `entries` (dict shape with is_dir/key/size/mime_type), `target_path` ('' = root), `sync_mode` values, and `auto_retry`. Gaps: `exclude` is never mentioned, and the enum value 'new' is left undefined while 'copy' is described as new-only.

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?

Opens with a specific verb and resource: 'Запустить перенос файлов между двумя облаками (server-to-server, фоном)'. It also names the follow-up tool (get_transfer) so the agent can tell it apart from list_transfers/cancel_transfer in the sibling set.

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?

Gives concrete context: use `entries` for key-based clouds such as Google Drive, obtain them from list_files, and monitor progress via get_transfer. It has no explicit exclusion against the other transfer/upload siblings (remote_upload, list_transfers), so it falls short of a full when/when-not statement.

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/openWorldHint, the description adds genuinely useful behavioral facts: the link expires in 10 minutes, opens without authorization in a browser or curl, is scoped to a single file, and is not an API key. That last point preempts a likely misuse. It does not say what happens on expiry or whether regenerating is permitted.

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

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

Three compact sentences with the key fact (signed, 10 min, no auth) front-loaded. Nothing is redundant, though the parameter-origin note is tacked on rather than integrated into a structured form.

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

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

With no output schema, the description usefully conveys the return value (a signed URL with a 10-minute lifetime). But for a five-parameter tool with zero schema documentation, the missing explanation of connection_id and the name/mime_type parameters leaves the definition under-specified for callers.

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

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

Schema description coverage is 0% across five parameters, so the description must carry the burden. It only clarifies key/path and their origin; name, mime_type, and especially the required connection_id are left entirely unexplained, leaving an agent to guess what connection_id identifies and whether name/mime_type are optional overrides.

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 artifact: a signed temporary (10-minute) URL for downloading a file straight from cloud storage. An agent immediately understands the output is a URL, not file bytes. It stops short of naming sibling create_share_link, so the boundary between 'temporary download URL' and 'share link' is left to inference.

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 clause '`key`/`path` — from list_files' gives a concrete entry point, implying you list files first and then call this. However, there is no explicit when-to-use vs create_share_link or read_text_file, and no stated preconditions 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context by enumerating the status lifecycle values and the returned data dimensions (progress by files and bytes, current file, errors). It stops short of describing not-found or failed-lookup behavior.

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

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

One compact sentence with the resource named first and the returned fields front-loaded after the colon. No filler, no repetition of the tool name, and the parenthetical status list is dense information rather than padding.

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

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

There is no output schema, so the description is responsible for describing return values, and it does so concretely with statuses, progress metrics, current file, and errors. Only the failure/not-found path and the source of the ID are left unstated, which is a minor gap for a simple read-only lookup.

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 0%, so the description carries the burden for the single parameter, and it never mentions transfer_id at all. The parameter name is self-explanatory as an identifier, which keeps this at a minimum-viable 3, but no guidance is given on obtaining or formatting the ID.

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 ('Детали одного переноса') and enumerates the exact contents (status, file/byte progress, current file, errors). It implicitly contrasts with list_transfers by scoping to a single transfer, but never names the sibling explicitly.

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

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

Usage is only implied: the singular 'одного переноса' suggests this is the per-item lookup versus a listing, but there is no explicit 'use this when…' or 'use list_transfers instead when…'. Nothing says where transfer_id comes from or what happens if the transfer does not exist.

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 annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds what the agent otherwise cannot know because there is no output schema: the response covers the tariff plan, the quota limit with bonuses included, and the consumed amount. It does not cover units beyond GB, reset period semantics, or whether overage is possible, so it is not fully exhaustive.

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

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

One compact sentence with no filler, front-loading the resource ('tariff and monthly traffic quota usage') before the enumeration of returned values. Nothing could be removed without losing 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-only tool with no output schema, the description supplies the key missing piece: the shape of the returned data. What remains unstated are secondary details such as units for the plan fields or quota reset timing. Those are helpful but not required to invoke 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 tool takes no parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly spends no space on arguments and instead describes what the call returns.

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 resource and its contents: the plan, the monthly traffic quota (GB, including bonuses), and how much is already consumed. Although it is a noun phrase with no explicit verb, 'get_usage' plus the resource list makes retrieval unambiguous. It is also clearly distinct from the file/transfer/link siblings, which operate on objects rather than account-level 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?

Usage is only implied: an agent can infer this is the call for account plan and quota status, since all siblings deal with files, transfers, or share links. There is no explicit when-to-use statement, no mention of alternatives, and no exclusion such as 'for per-file size limits use X'. For a zero-parameter informational tool that ambiguity is minor, but it is still absent.

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 safety profile is covered. Beyond that, the description discloses the shape of the response (id, provider, account, quota), which is genuinely useful because no output schema exists; it does not mention empty-list behaviour or auth requirements, which keeps it short of a 5.

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, front-loaded with the verb and resource, then the returned fields. Every clause carries information the agent needs; nothing is redundant.

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 trivial zero-param list tool with no output schema, listing the returned fields plus the cross-tool id dependency covers what an agent needs to call it and use the result. Minor omissions (empty list, no-pagination confirmation) prevent a 5, and the Russian-language text may read inconsistently against English sibling definitions.

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 and the schema is empty, so the baseline is 4. The description correctly implies no input is needed, adding nothing misleading about arguments.

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 ('Список подключённых облачных хранилищ пользователя') and enumerates the returned fields (id, provider, account, quota). It implicitly separates itself from siblings by noting the id is required by all other tools, though it never names an alternative explicitly.

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 parenthetical 'id (нужен всем остальным инструментам)' tells the agent this is the entry-point call whose output feeds every sibling, which is strong usage context. There are no explicit when-not conditions, but for a zero-parameter discovery tool the selection logic is effectively unambiguous.

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, so the safety profile is covered. The description adds meaningful behavior beyond that: results are non-recursive direct children only, the exact return shape {key, name, rel_path, is_dir, size, modified}, and the dependency that key must be harvested from a previous call. Pagination, size limits, and error behavior remain undisclosed.

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?

Front-loaded with the core purpose, then parameter guidance, then return shape and downstream use — a logical ordering with no filler. The semicolon-and-dash compression makes it dense but still parseable; a little breathing room would not hurt.

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

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

With no output schema, the description correctly spells out the returned record fields, and it flags the non-recursive scope and the key-chaining requirement that would otherwise cause failed calls. Missing connection_id semantics and any notion of result limits keeps it short of complete for a 3-parameter listing tool.

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

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

Schema description coverage is 0%, so the description carries the burden, and it does well for two of three parameters: path is a relative path with '' meaning root, and key is the provider-side folder id with its provenance explained. connection_id, the only required parameter, is never mentioned, leaving a real gap given zero 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+resource: listing files and folders that are direct children of a cloud directory, and explicitly rules out recursion with '(прямые дети)'. An agent can distinguish it from list_clouds, list_transfers, and read_text_file without opening any schema.

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?

Gives concrete operating context: empty path means root, key must come from a prior list_files result on key-based clouds like Google Drive, and the returned entries feed create_transfer. It lacks an explicit when-not (e.g., what to call for nested trees or for reading file content), so it stops short of full alternative routing.

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=false, so the safety profile is covered. The description adds useful behavior beyond that: results are limited to active links and scoped to the calling user, and the per-entry attributes (including the kind enumeration) are disclosed even though no output schema 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?

A single front-loaded sentence: the resource and its scope come first, then the returned fields as a compact list. No filler and nothing redundant.

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, the description covers scope and the shape of returned entries, which is the main thing an agent needs. It is not fully complete on pagination/ordering or whether links across all clouds are included, but those are minor for a simple listing 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?

There are zero input parameters and the schema is empty, so there is no parameter semantics to clarify; a baseline of 4 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 names a concrete resource (the user's active public share links) and enumerates what each entry carries (kind file/inbox/archive, URL, whether a password is set, expiry). This clearly distinguishes it from the create/revoke siblings, though the listing verb itself is only implied by the name rather than stated in the sentence.

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

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

Usage is implied: the word 'active' signals only currently-valid links are returned, and the possessive framing signals the caller's own links. There is no explicit when-to-use statement, no mention of alternatives such as create_share_link or revoke_share_link, and no stated preconditions or scope 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that — sort order (newest first) and the returned fields (status, progress, file counters, errors) — but says nothing about pagination limits, defaults, or result caps, which matter for a list 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?

A single dense sentence with the resource and scope front-loaded and zero filler. It is efficient, though the trailing field list reads as a run-on enumeration rather than structured information.

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

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

For a simple read-only list tool with no output schema, stating the returned fields is valuable and mostly sufficient. The remaining gap is pagination behavior for limit/offset, which an agent needs in order to page 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 description coverage is 0% and both parameters (limit, offset) are undocumented in both schema and description. 'Newest first' hints at ordering but gives no meaning, defaults, or bounds for limit/offset, so the description fails to compensate for the coverage gap.

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

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

States a specific verb (list) and resource (transfers) scoped to 'the user's latest transfers' with explicit ordering (newest first), which separates it from the singular get_transfer sibling. It does not name siblings explicitly, so it stops short of the top mark.

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

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

Usage is only implied: 'latest transfers' signals a recent-history listing, but the description never says when to prefer this over get_transfer (single item) or how it relates to cancel_transfer/create_transfer. No exclusions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond them: the output is decoded as UTF-8 text, there is a size limit with a stated default of 512 KB, and oversized files are rejected rather than truncated—an important failure mode. It does not mention authentication or permission requirements for the connection.

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

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

Three compact sentences, front-loaded with the core action and output format, followed by applicability and then the size constraint with its remedy. No redundant restatement of the tool name or filler wording.

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 adequately covers the return type (UTF-8 text) and the size-limit behavior. However, with six parameters at 0% schema coverage and a non-obvious overlap between key/name/path, the definition leaves an agent without enough guidance to construct a correct call.

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

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

Schema description coverage is 0% across six parameters, so the description must carry the burden, but it only explains max_kb and its default. The ambiguity between key, name, path, and mime_type, plus what connection_id selects, is left entirely undocumented—an agent cannot tell which identifier fields are needed or how they interact.

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: download a file and return its contents as UTF-8 text, scoped to text files such as configs, notes, and logs. It also implicitly distinguishes itself from get_download_url, which it names for the oversized case, so an agent can pick between them without opening the schema.

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?

Gives explicit use conditions (text files: configs, notes, logs), an explicit exclusion with the reason (files above max_kb are rejected), a pre-check recommendation (verify size via list_files), and the named alternative (get_download_url). Little is left to inference.

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 openWorldHint=true, idempotentHint=false and destructiveHint=false, so the description adds real value on top: it explains that the fetch happens server-side, that extra_connection_ids fans the file out to multiple clouds, and that this requires a paid plan. It does not mention whether the upload is asynchronous or what happens on a duplicate/repeat call, which matters given idempotentHint=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?

One front-loaded sentence states the operation and its benefit, followed by a compact backtick-delimited parameter gloss. Dense but every clause carries information; no filler or repetition.

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

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

There is no output schema and no annotation covering auth or permissions, and the presence of get_transfer/cancel_transfer/list_transfers among siblings suggests this produces a trackable transfer object — something the description never says. It is adequate for calling the tool but leaves the agent unclear on the result and on the meaning of the required connection_id.

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

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

Schema description coverage is 0%, so the description must carry all parameter meaning, and it does well for three of five: target_path ('' = root), file_name (defaults from URL/headers), and extra_connection_ids (multi-cloud copies, paid tiers). connection_id — the required integer identifying the destination cloud — is left completely unexplained, and url is only implicit in the mechanism sentence.

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 gives a specific verb and resource ('Загрузить файл в облако') plus the distinctive mechanism: the server fetches the URL and stores it, so the user's own bandwidth is not used. That mechanism clearly separates it from a client-side transfer, but no sibling tool (create_transfer, get_download_url) is named for contrast.

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 bandwidth-saving rationale implies the right situation to pick this over an ordinary upload, and the paid-tier note on extra_connection_ids hints at a cost constraint. However, there is no explicit when-to-use/when-not statement and no pointer to which sibling handles the follow-up (tracking, cancelling, or sharing the result).

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 annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is mostly covered. The description adds one useful fact that the annotations do not: the link stops opening forever, so the action is irreversible for third parties. It says nothing about required permissions, error behavior for unknown link_id, or what is returned.

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

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

The description is a single front-loaded sentence with zero filler. It pairs the action with its consequence immediately, so nothing needs trimming.

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?

It is a destructive single-parameter tool with no output schema, and the annotations carry the safety signals. Still missing is how to obtain link_id, what success looks like, and what happens on an unknown or already-revoked id, so it is adequate but has clear gaps.

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

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

The single parameter link_id has 0% schema description coverage, so the description needs to compensate and it gives no meaning at all: it does not say where link_id comes from (list_share_links, create_share_link) or what form it takes. This leaves the only parameter undocumented in both the schema and the description.

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

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

The description names a specific verb (revoke) and resource (public share link), which lets an agent distinguish it from the siblings create_share_link and list_share_links. It stops short of naming a sibling explicitly, so it is clear but not fully differentiated.

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

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

The description gives no when-to-use guidance, no prerequisites, and no alternative path such as using list_share_links to find the link_id. It does not say what to do if the link is already revoked or invalid, and the only implied guidance is the permanence note.

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