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

Annotations already declare destructiveHint and idempotentHint, but the description adds real value beyond them: exactly what is destroyed (the asset record plus its Etchv-managed file availability), the auth requirements, and the caveat that customer bucket objects are governed by separate storage deletion rules rather than being removed here.

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 with the destructive nature and prerequisites front-loaded, so nothing needs re-reading. It loses a point because 'This is destructive' merely restates the destructiveHint annotation rather than adding 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 single-parameter destructive tool with no output schema, the description covers the key operational facts an agent needs: what disappears, who may call it, and the boundary with customer-owned storage. The only real gap is guidance on the asset_id value itself.

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 is one parameter with 0% schema description coverage, so the description carries the burden of explaining it, yet asset_id is never mentioned. The schema's 'ast_' prefix/64-hex-char pattern is the only hint of format, and the description adds nothing about what identifier to supply.

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 ('Delete an asset record') and immediately scopes it ('and its Etchv-managed file availability'), which cleanly separates it from get_asset, update_asset, list_assets, and store_asset. An agent can identify the operation 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?

It gives clear operating context: the call is destructive and requires the assets:delete permission plus an owner/admin role. That tells the agent when the call is appropriate and likely to succeed, but it never names an alternative operation or an explicit 'do not use this when' condition.

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 cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true), and the description adds meaningful context beyond them: it consumes API credits, has sync/async behavior with async default, returns two different result shapes, and names the required auth scope. It does not say whether the job receipt carries an id or how long jobs 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?

Five short sentences, front-loaded with what the tool does, followed by cost, mode, return shape, and scope. Every sentence carries information an agent needs; nothing is redundant with the title or restates the name.

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 describes the two possible return shapes (detection JSON vs job receipt), which is the key missing structured info. It still omits how to proceed after an async receipt is returned, which matters for a tool whose default is async.

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 only 20% (only idempotency_key is documented), so the description must compensate. It explains mode semantics ('sync and async (default)') and maps media values to 'image, PDF or video', but leaves input_path format and webhook_id unaddressed beyond their schema types.

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 ('Detect a watermark in an image, PDF or video'), which is clear and distinguishable from the sibling watermark_media (which presumably applies/embeds a watermark). It does not explicitly name that sibling, but the detect-vs-apply distinction is inferable from the verb.

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 notes sync and async modes with async as the default and that the response is either detection JSON or a job receipt, which implies when a follow-up (get_job) is needed. However, it never states when an agent should choose sync over async, nor references the get_job/get_job_result siblings that consume the receipt.

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 only declare the generic safety profile (non-read-only, non-destructive, non-idempotent, open-world). The description adds genuinely useful behavior: it never overwrites existing files, which resolves the tension between readOnlyHint=false and destructiveHint=false, and it names the required scope assets:read.

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?

Four short sentences, purpose front-loaded, and each sentence carries distinct information (target, storage source, overwrite policy, scope). Minor waste in the internal 'Etchv storage' jargon that an agent may not recognize.

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 target, storage backend, overwrite policy, and auth scope, which is decent for a write-to-disk tool with no output schema. It still omits the return value (e.g., resulting file path) and the meaning/format of both parameters, leaving real 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 0% and neither asset_id nor output_path is described. The phrase 'into a new local file' only hints at output_path and says nothing about the asset_id format, path constraints, or what happens if the path exists.

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?

Specific verb+resource (download an asset) plus a distinguishing detail: it writes to a new local file, unlike get_asset which presumably returns metadata. It never names a sibling explicitly, so it lands just short of the top tier.

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 statement of when to choose this over get_asset, list_assets, or store_asset, and no prerequisites beyond the permission scope. The storage-source sentence describes mechanism, not usage 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 declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered elsewhere. The description adds two genuinely useful behavioral facts: that returned metadata is untrusted data (a prompt-injection caution) and the required OAuth scope. It still omits any statement about error behavior for a nonexistent asset_id.

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, no filler, with the core action front-loaded and the caveat and scope appended compactly. Every clause carries 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 two-parameter read tool with no output schema, the description does cover the return surface (version, storage, download availability) and injects a security note. It falls short on the include_metadata flag and asset_id expectations, leaving the 0%-covered schema to carry semantics it does not actually document.

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 description says nothing about either parameter. In particular, include_metadata (default true) is undocumented anywhere, so an agent cannot tell that it can suppress metadata retrieval, and the asset_id format constraint lives only in the regex pattern.

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 ('Read an asset record') and enumerates what the read returns: version, storage and download availability. That is enough to separate it from list_assets and download_asset without opening a schema, though it never names a sibling to contrast against.

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?

'Scope: assets:read' tells the agent the required permission but not when to choose this tool over siblings like list_assets or download_asset, nor any precondition (e.g. needing an ID already obtained from a list call). No when/when-not guidance is 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: this is a non-blocking read ('without waiting') and it requires the matching watermarks:embed or watermarks:detect scope, which is an authorization requirement not visible in the schema or 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 short sentences, zero filler, with the core behavior ('without waiting') front-loaded before the invocation constraints. 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?

With no output schema, the description should say what 'job state' returns (status only? result included?) and how it relates to get_job_result, but it does not. The scope requirement partially compensates, but the result-shape gap is significant for a polling-style 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 must carry the parameter burden. It does clarify that 'operation' must match the original submission (a coupling constraint beyond the bare enum), but it says nothing about the request_id format or source, leaving half the parameters undocumented.

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 ('Read job state') plus a distinguishing behavioral trait ('without waiting'), which separates it from a result-fetching sibling like get_job_result. It does not name that sibling explicitly, so an agent must infer the boundary, keeping this just short of a 5.

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

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

Offers one concrete usage rule ('Use the operation from the original submission'), which tells the agent how to populate a required field. However, it never states when to call this versus get_job_result or how often to poll, leaving the primary routing decision 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds genuinely useful behavior: a pending 202 receipt is possible instead of a result, results expire after 24 hours, and embedding demands output_path. It never explains why 'collect' is flagged non-read-only (consumption of the result), leaving 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?

Four short sentences, front-loaded with the core action and the pending-receipt branch, then constraints, then expiry. Nothing is 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?

With no output schema, the description must convey what comes back, and it does at a high level (JSON for detection, a 202 receipt when pending). Richer return-shape detail is absent, but for a 3-parameter tool the coverage is adequate.

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: it explains the operation enum's two branches and the conditional requirement of output_path for embedding. request_id semantics are left to the pattern in the schema, but that is self-evident.

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 ('Collect a job result') and clarifies the dual outcome (result vs pending 202 receipt), which separates it from get_job, the sibling that presumably reports job status. It stops short of naming that sibling explicitly, so differentiation is implicit rather than stated.

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 real usage constraints: 'Does not poll' tells the agent this is not the tool for waiting on a job, and the operation-specific notes ('Embedding requires output_path; detection returns JSON') guide invocation. There is no explicit when-to-use-vs-alternative routing to get_job, which keeps it out of the top band.

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, idempotentHint, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds the required auth scope (storage:read), which is genuinely useful context beyond the annotations, but says nothing about error behavior for a missing or malformed delivery_id.

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, front-loaded with the action and followed by the scope. No waste, though it is arguably under-specified rather than optimally concise.

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 single-resource read with full safety annotations and no output schema, the definition is close to adequate, but the unexplained delivery_id format/prefix and the absence of any usage context for choosing it over list_storage_deliveries leave 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?

One parameter at 0% schema description coverage. The schema only constrains delivery_id with a regex pattern (^std_[a-f0-9]{64}$); the description never mentions the parameter, its expected prefix format, or what happens on a bad value, so it 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+resource: read the current storage delivery status. It is reasonably distinguishable from list_storage_deliveries (plural, listing) and retry_storage_delivery (mutation), though it never explicitly names those siblings as alternatives.

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

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

No when-to-use guidance, no conditions, and no alternatives named. The agent must infer from the name that this is the single-delivery lookup versus list_storage_deliveries.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description usefully adds two things beyond that: the pagination model (cursor) and the required permission scope (assets:read). It says nothing about return contents, default page size, or how pagination terminates.

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, front-loaded sentences with zero filler: the action and resource come first, then the pagination behavior and the permission scope. Nothing is repeated from the name or schema.

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 filtered collection tool with 5 optional parameters, no output schema, and no parameter documentation, the description is too thin. An agent cannot tell what a returned asset looks like, how to page through results, or what the filter parameters select, all of which the definition must supply here.

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

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

Schema description coverage is 0% across 5 parameters, so the description carries the full explanatory burden and does not meet it. 'Cursor pagination' loosely gestures at cursor and limit, but the kind enum (source/watermarked), media_type, watermark_id, and the 1-100 limit bounds are entirely undocumented anywhere.

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 ('List organization assets') and adds the pagination mechanism, so the agent knows this is a collection read rather than the single-resource get_asset. Sibling tools like list_webhooks and list_storage_deliveries are implicitly distinguished by resource, but no sibling is named 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?

There is no when-to-use guidance and no routing against alternatives such as get_asset or download_asset. The only contextual statement, 'Scope: assets:read,' is an auth prerequisite rather than usage direction, so the agent must infer when this tool is 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds only the pagination behavior and scope, but nothing about pagination semantics (e.g., cursor format), rate limits, or what is returned. Minimal added context.

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, front-loaded with the action and resource, followed by scope. No wasted words, though could be slightly more informative without becoming verbose.

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

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

Given a simple read-only tool with no output schema, the description covers the basic purpose but omits return value structure, pagination mechanics, and cursor handling for the 'after' parameter. It's adequate but incomplete.

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% – neither parameter is described in the schema. The description mentions 'destination' which maps to destination_id but says nothing about 'after' (the pagination cursor). This leaves the most non-obvious parameter undocumented.

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 (delivery status for a destination) with pagination scope. Clear enough to distinguish from get_storage_delivery (singular) and list_storage_destinations, though it doesn't explicitly name a sibling alternative.

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 scope hint 'storage:read' implies a read operation, and 'for a destination' implies the required destination_id, but no explicit guidance is given on when to use this vs. get_storage_delivery or list_storage_destinations.

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 readOnly, idempotent, non-destructive and open-world behavior. The description goes beyond them by disclosing that credentials are withheld from results and that the required scope is storage:read — both are genuine operational details an agent needs before calling.

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, led by the core action and scope of the resource; nothing is padded. It is slightly telegraphic, but every clause 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?

There is no output schema, so the description partially compensates by telling the agent what comes back (destination listings minus credentials). With zero parameters and full annotation coverage, the agent has everything needed to call 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 takes zero parameters, so the baseline is 4. The description correctly implies the tool is unfiltered and takes no arguments, leaving nothing to misinterpret.

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 ('configured S3, Google Cloud Storage and Azure destinations'), and adds the meaningful qualifier 'without credentials'. It distinguishes itself from verify_storage_destination and list_storage_deliveries by clearly being a read-only enumeration of configured destinations, though it never names those siblings 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?

'Configure destinations in the dashboard' implies this tool is for viewing only and that creation/editing happens elsewhere, which is useful routing context. However, it gives no explicit when-to-use, when-not-to-use, or named alternative, so usage is only implied.

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 readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds two things annotations do not: cursor-based pagination behavior and the required auth scope (webhooks:read). It stops short of describing ordering or default page size.

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, front-loaded with the resource and pagination model, closing with the auth scope. No filler or restated boilerplate.

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 two-param list tool with no output schema, the description should say what a delivery record contains and how the cursor/identifiers behave. Annotations cover safety, but return semantics and parameter formats remain 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 0%, so the description carries the full burden for two parameters. 'Cursor pagination' only loosely implies the 'after' cursor and never names it or explains the evt_/wh_ identifier formats; webhook_id is entirely unaddressed.

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?

Names the resource precisely ('webhook events and delivery attempts') and distinguishes it by scope from the sibling 'list_webhooks', which is a different resource. The verb 'inspect' is slightly softer than the tool name's 'list', but the intent is 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?

Usage is implied by the resource (fetch delivery history for a webhook), and the required scope 'webhooks:read' is disclosed. However, it never states when to use this versus list_webhooks or how it pairs with redeliver_webhook, so the agent must infer the call context.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds two critical behavioral facts beyond annotations: signing secrets are omitted from output, and the operation requires the webhooks:read scope.

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 with purpose front-loaded, followed by usage context and required scope. Every sentence earns its place with 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?

For a zero-parameter list tool with rich annotations and no output schema, the description supplies auth scope, secret omission, and the creation workflow. Nothing an agent needs to call this tool correctly 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 and 100% schema description coverage. Per calibration, a zero-parameter tool has a baseline of 4; the description does not need to add parameter semantics, and it does not introduce misleading parameter references for this tool.

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: 'List configured webhook endpoints'. Adds the important qualifier 'without signing secrets' and the required scope 'webhooks:read', clearly distinguishing it from delivery-oriented siblings like list_webhook_deliveries and redeliver_webhook.

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 clear workflow context: endpoints are created in the dashboard, then webhook_id is used with async submissions. This tells the agent when and why to use the tool. It does not explicitly name when-not-to-use or an alternative listing tool, but the usage condition is sufficiently 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=false, idempotentHint=false, openWorldHint=true, so the mutation/safety profile is partly covered. The description adds genuinely useful context beyond that: the side effect ('can trigger customer automation again') and the exact auth requirements (webhooks:write, owner/admin). It stops short of warning about duplicate/irreversible effects from non-idempotency.

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 that leads with the action, then the consequence, then the permission prerequisite. No filler and every clause carries 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 non-idempotent write with an external side effect and no output schema, the description conveys the effect and auth needs but leaves both parameters unexplained and gives no hint of the response or failure behavior. Adequate but with 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?

Schema description coverage is 0% — both webhook_id and event_id are documented only by name and regex pattern. The description explains neither the identity of the webhook nor which event may be re-sent, so it 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?

The description states a specific verb+resource: 'Send an existing event again to its configured endpoint'. It is clearly distinct from siblings like list_webhooks, list_webhook_deliveries, and retry_storage_delivery (a different domain). It does not explicitly name a sibling, but the action is unambiguous.

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

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

It implies the use case (re-triggering a delivery) and gives a strong precondition via 'Requires webhooks:write and owner/admin', but never states when to choose this over alternatives or when not to use it. Guidance 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?

Annotations already declare it is a non-read-only, non-idempotent operation; the description adds genuinely new context — that it writes to the selected bucket and requires storage:write plus owner/admin privileges. It stops short of noting side effects on existing delivery state or retry limits.

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, front-loaded sentences with no filler; the action, effect, and auth requirement each appear once and earn their 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 single-parameter mutation tool with annotations and no output schema, the description covers the operation, its write target, and auth requirements. The only gap is the delivery_id parameter, which the schema only partially covers via its pattern.

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 burden of explaining delivery_id but says nothing about it beyond the tool's subject. The schema's regex pattern is the only source of format information, so the description adds no 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?

"Requeue a failed or cancelled delivery" is a specific verb plus resource with a stated scope (failed/cancelled only). It clearly distinguishes itself from siblings like get_storage_delivery, list_storage_deliveries, and redeliver_webhook.

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 condition "failed or cancelled delivery" implies when to use it, but there is no explicit when-not guidance and no named alternative (e.g. redeliver_webhook or re-creating the delivery). Usage is inferable but not routed.

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 flag this as destructive and non-idempotent, and the description adds real value on top: the staged output is removed after delivery succeeds, downloads read from that bucket, and it requires storage:write plus owner/admin. It does not describe failure behavior or whether re-invocation with a new destination 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 short sentences, front-loaded with the action, then side effects, then permissions. No filler, though the permission sentence could be folded into a prerequisite clause.

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 should carry return/result semantics, and it only partially does (downloads read from that bucket). It covers the destructive side effect and auth well, but leaves parameter meaning and error/retry behavior undocumented for a mutation 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% and the description explains none of the three parameters. The optional 'key' parameter is completely opaque, and asset_id vs destination_id roles are only inferable from the prose nouns, not defined.

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: choosing a verified destination for an existing watermarked asset. An agent can distinguish this from verify_storage_destination or list_storage_destinations, though the description never names those siblings 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?

'Verified customer destination' implies the destination must already be verified, which implicitly routes the agent away from unverified ones. But there is no explicit when-to-use, no prerequisites stated as conditions, and no named alternative for comparison.

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, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: the mandatory version parameter prevents lost updates, and metadata semantics ('replaces the whole object; null clears it') clarify an otherwise surprising destructive side effect.

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, front-loaded with the action and its concurrency requirement, then the destructive metadata semantics, then the auth scope. 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 4-parameter mutation tool with no output schema and annotations covering safety, the description supplies the critical missing pieces: concurrency model, replacement semantics, and required scope. It stops short of documenting asset_id/name behavior, which is a minor gap given the schema's pattern constraint.

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 full burden. It usefully explains the two non-obvious parameters, version (concurrency token) and metadata (full replacement, null clears), but says nothing about asset_id or name, leaving half the parameters undocumented anywhere.

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 ('Update an asset') and immediately adds the mechanism (current version). It is clearly distinguishable from read-oriented siblings like get_asset/list_assets, though it doesn't explicitly name delete_asset or store_asset as alternatives.

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

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

The description implies when this applies (mutating an existing asset, with an optimistic-lock version) and names the required scope assets:write, but gives no explicit when-not guidance or routing to alternatives such as delete_asset or store_asset.

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 show readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. Description adds critical context beyond these: it writes and removes a probe object, which explains the mutation and its transient nature, and specifies permission requirements. It doesn't explain side effects like what verification state is updated or failure modes.

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 action, then mechanism, then prerequisites. No waste.

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

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

Given 1 param, no output schema, and annotations, the description covers the key aspects: what it does, that it writes/removes, and permissions. Lacks details on return format or error behavior, but sufficient 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?

Schema coverage is 0% and there is 1 parameter. Description gives no details about destination_id format, but with only one required parameter, the agent can infer it needs a destination identifier. The baseline for 0 params is 4; here it's 0% coverage but 1 param, so description doesn't compensate but the parameter is self-explanatory from the tool context.

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

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

Clear verb+resource: 'Test access to a configured bucket.' Distinguishes from sibling list_storage_destinations by emphasizing verification rather than listing, though it doesn't explicitly name alternatives. The action is concrete and implies a probe operation.

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

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

States required permissions ('Requires storage:write and owner/admin') but provides no explicit when-to-use vs. alternatives. An agent can infer it's for checking destination health, but no conditions or exclusions are given.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false, and the description adds genuinely non-redundant behavior: it consumes credits, defaults to async, sync can yield a 202 job, and it requires the watermarks:embed scope. It omits failure modes and whether output is written to output_path vs returned inline, but the credit and auth-scope disclosures are real added value.

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 with zero filler, and the core purpose is front-loaded ahead of cost, mode, and scope details. Every clause carries distinct 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 9-parameter mutation tool with nested free-form data, 11% schema description coverage and no output schema, the description is too thin. It never explains how watermark content is supplied or where results land, which is exactly the gap the description should close.

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 only 11% — essentially just idempotency_key — across 9 parameters with 4 required. The description mentions mode values only (which the schema's enum and default already convey) and says nothing about media, input_path, output_path, storage_key, storage_destination_id, webhook_id, or the free-form data object that drives the watermark content. It 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 (watermark) plus resource and media scope (image, PDF, video) in a single front-loaded clause. None of the sibling tools perform watermarking, so an agent can route to it unambiguously 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 partial operational context: credit cost and the sync/async default with the note that sync may return a 202 job. It does not say when an agent should prefer sync vs async, nor when to pick this tool over detect_media/store_asset in a pipeline, so usage is only implied.

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