550W Watermark & Text Eraser

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact not in the schema: deletion does not refund charged credits. It omits whether deletion is permanent/undoable or what state the task must be in.

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

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

Two short sentences with the action front-loaded and the consequential credit warning immediately after; 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 one-parameter delete with annotations already conveying destructiveness, the description covers purpose and the key non-refund caveat. It could still mention irreversibility or the taskId source, but nothing critical for invocation is missing.

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

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

Schema description coverage is 0% and the single parameter (taskId) is undocumented in both schema and description. The description does not say what the ID refers to, its format, or how it is obtained, 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 and resource ('Delete ... subtitle removal task'), which an agent can distinguish from read siblings like get_subtitle_task or list_subtitle_tasks. It is clear but does not explicitly contrast itself with any sibling tool.

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

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

There is no guidance on when to delete versus when to leave a task alone, no preconditions (e.g., task must exist/be in a finished state), and no alternative named. The credit note is a side-effect warning, not usage direction.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds genuinely new information beyond those: the estimate is not binding because 'Admission rechecks price and balance' at submit time. Missing is any statement about units or error behavior for invalid dimensions.

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 inputs, followed by the one caveat that matters. 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?

There is no output schema, so the description should at least hint at the return shape (a credit count), and it does say 'credits'. However, units for the three required numeric parameters and the non-binding nature of the result relative to submit_subtitle_task are only partially covered, leaving real gaps for a 3-required-param 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 only echoes the property names ('video width, height and duration'). Critical semantics — whether width/height are pixels and duration is seconds, and in what unit the resulting credits are expressed — are absent from both schema and description.

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

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

States a specific verb (Estimate) and resource (subtitle-removal credits) and names the inputs that drive it (width, height, duration). It is clearly a pre-flight cost calculator, distinguishable from submit_subtitle_task, though it never names that 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?

The phrase 'before submitting' implies the usage context, but no alternative tool is named and no when-not-to-use condition is given. An agent can infer this precedes submit_subtitle_task, but must do the inferring.

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 this as a safe, idempotent, non-destructive read, so the description's main added value is disclosing the return content (status, result, failure reason), which matters because no output schema exists. It stops short of describing polling cadence, task retention, or auth needs.

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 sentence, front-loaded with the operation and resource, with each listed item (status, result, failure reason) earning its place. No filler or redundancy.

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

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

For a simple read-only getter with no output schema, the description covers the essentials of what comes back. It is slightly thin on taskId provenance and failure handling, but nothing critical for correct invocation is missing.

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

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

Schema description coverage is 0% for the single required parameter, and the description never explains what taskId is, its format, or where the agent obtains it. With a low-coverage schema the description is expected to compensate, and it does not.

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

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

States a specific verb (Get) and resource (image watermark task) and enumerates exactly what is returned: status, result, and failure reason. This cleanly separates it from the sibling get_subtitle_task, so an agent can pick correctly without opening either 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?

The phrase 'your image watermark task' implies this is used to poll a task previously submitted, but there is no explicit when-to-use, no prerequisite (e.g. 'call after submitting a task'), and no mention of what to do on failure. Usage is implied rather than 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 cover safe-read semantics (readOnly, idempotent, non-destructive, closed-world), and the description adds real value beyond them by disclosing the response contents, notably the 'refund state' — useful signal for a task that consumed credits. It stops short of explaining what refund states mean or how polling should be paced.

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 conveys the verb, the resource, and the payload with zero filler. 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 correctly enumerates what comes back (status, result, refund state), which is the key gap it needed to fill. Only minor gaps remain, such as what the refund states signify or whether results are available while status is still pending.

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

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

Schema coverage is 100% for the single taskId parameter, so the schema already documents it. The description adds no format or provenance detail (e.g., where the ID comes from) beyond what the structured field provides, which is the expected baseline.

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 ('Get ... subtitle removal task') plus a preview of what is returned (status, result, refund state). It is clearly distinguishable from list_subtitle_tasks and submit_subtitle_task, though it never names a 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?

The phrasing 'your subtitle removal task' hints this is called after submit_subtitle_task, but there is no explicit when-to-use, when-not-to-use, or mention of the list_subtitle_tasks alternative. An agent must infer that this is a point lookup by task ID rather than a listing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only that results are paginated, without stating the default page/size, the cap (100), or ordering, so added value is limited.

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 with no filler. It is efficient, though arguably too terse given the undocumented pagination semantics.

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 describe the returned task list shape and pagination behavior (defaults, limits, ordering), but says nothing. For a listing tool with two undocumented params, this leaves substantial 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 'page' nor 'size' has a description in the schema. The phrase 'with pagination' gestures at these params but does not explain defaults, valid ranges, or how size interacts with the 100 maximum, leaving the agent to read the schema raw.

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 (subtitle removal tasks), making the operation clear. It is reasonably distinguishable from get_subtitle_task (singular retrieval) and submit/delete siblings, though it never names or contrasts them 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?

No guidance on when to use this versus get_subtitle_task or the other task tools, no preconditions, and no mention of filtering or ordering. The agent must infer usage entirely from the name.

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

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

Beyond the annotations (write, non-idempotent), it discloses the upload auth mechanism (X-550W-Upload-Ticket header, no OAuth on upload), that an image upload triggers a paid task, retry semantics (8-64 char operationId, same file), and that failed/deleted/expired operations are not recreated. This is rich context an agent could not infer from the annotation block.

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 core action is front-loaded, and each sentence adds operational detail (auth header, paid task, follow-up calls, consent, retry rule). It is dense and longer than typical, but nearly every clause earns its place; only the operationId/retry sentence feels slightly compressed into the flow.

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

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

With no output schema and only generic annotations, the description still conveys the full lifecycle: ticket issuance, upload mechanics, the returned uploadUrl/taskId, terminal-status polling, and the video hand-off. Nothing an agent needs to invoke and follow through is missing.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It explains the mediaType branches and the operationId constraint, but fileSize is never explained, and operationId is referenced yet absent from the schema, leaving some ambiguity. It compensates partially but not fully.

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 first sentence names a specific verb and resource ('Get a short-lived upload ticket') and immediately differentiates the two media branches, routing image uploads to get_image_watermark_task and video uploads to submit_subtitle_task. An agent can distinguish this from every sibling without opening a 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 explicit when-to-use routing for both media types, states a precondition (obtain user consent for upload and paid processing first), and names the follow-up tool for each branch. The no-separate-image-creation-tool note removes a common wrong turn.

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, fully covering the safety profile. The description adds nothing beyond that (no mention of freshness, caching, or rate limits), so it neither helps nor contradicts.

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 with no redundant or filler text. Every word earns its place.

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

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

For a simple zero-parameter read with no output schema, the description is nearly complete; it implies the balance is returned. It could briefly state the return shape, but nothing critical is missing.

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

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

The tool takes zero parameters, so there is no parameter semantics to convey. Baseline 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?

States a specific verb (Query) and resource (current account credit balance), so the operation is unambiguous. No sibling differentiation is needed because the sibling list contains no other credit/account tools.

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 read-only, zero-parameter nature of the tool, but the description never states when to call it or any alternatives. For such a narrow tool this is only a minor gap.

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=true and destructiveHint=false, so the safety and idempotency profile is covered structurally. The description adds genuinely useful billing context (1 credit per successful resolution) and a client-side fallback procedure, but does not discuss retry semantics, failure modes beyond download timeout, or what happens on a failed resolution re: credits.

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 action, then limitations, alternative routing, fallback, and cost. Four tight sentences, none redundant, 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?

With no output schema, the description usefully states the return value (a resolved watermark-free URL) and covers cost, prerequisites, and failure handling. It is nearly complete, though it omits credit-refund behavior on failure and any timing or rate-limit expectations.

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 load: it clarifies that videoUrl is a share URL from a supported app/site (not a direct media URL) and that operationId is required alongside a credit spend. However, operationId's purpose and lifecycle are never explained, leaving half the parameters semantically thin.

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 concrete verb and resource: resolve a share URL to a watermark-free data.video URL, naming supported sources (TikTok, X). It also distinguishes itself from submit_subtitle_task, so an agent can tell the two apart without opening either 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?

Explicitly scopes when it applies (remote share URLs from supported apps/sites), when it does not (hardcoded subtitles or burned-in overlays), and names the alternative path for that case (upload then submit_subtitle_task). It also prescribes fallback behavior for client download failure.

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 and destructiveHint=false, but the description adds real value beyond them: billing is by duration and resolution, and an uncertain result should be retried with the same inputs and idempotency key. It does not explain what happens to the source video or async task lifecycle, keeping it from 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?

Three dense sentences, front-loaded with the core action and no filler. Every clause carries information, though the middle sentence about coordinates is slightly terse.

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 13-parameter submission tool with no output schema and 0% schema coverage, the description is materially incomplete: it never mentions the videoUrl/mediaId oneOf requirement, removeAudio, coverUrl, or fileName, nor what the submission returns or how to track it. Given the complexity, this leaves the agent guessing on several required decisions.

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 13 parameters, so the description must carry the load but explains only x1/y1/x2/y2 (all-or-nothing rectangle) and idempotencyKey. Major inputs like videoUrl vs mediaId selection, coverUrl, fileName, and removeAudio are left 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+resource: submitting a video to erase hardcoded subtitles or visual watermarks. This is clearly distinguishable from siblings like estimate_subtitle_cost or get_subtitle_task. It does not explicitly name the sibling it is not, so it falls 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?

Provides conditional usage for the rectangle params ('full-frame by default; provide all x1, y1, x2, y2 only for a user-supplied rectangle') and retry guidance, but never says when to choose this over estimate_subtitle_cost or remove_video_watermark, nor any prerequisite ordering. Usage is implied rather than routed.

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