CleanVector

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

With no annotations provided, the description carries the full behavioral burden. It does disclose the output format (ZIP), contents, and the 2048px cap with a workaround, but it omits whether the operation is read-only, whether it requires a completed task, or what happens if the task is not yet ready. The schema already enforces the width maximum, making that part partially redundant.

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

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

The description is two sentences with no filler, front-loading the primary return value before the constraint and fallback. Every sentence adds necessary information without 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 download tool, the description covers the return type, contents, and size limit, which are the core operational details. However, it lacks parameter definitions, prerequisites like task completion, and error behavior—gaps that are more significant given the absence of annotations and output schema.

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

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

Schema description coverage is 0%, so the description must explain both task_id and width. It only indirectly refers to width via the 2048px cap and never mentions task_id at all. A caller might infer task_id refers to a generation task from the tool name, but explicit parameter documentation is missing.

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

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

The description clearly states the tool returns a completed logo kit as an embedded ZIP resource and enumerates its contents, which differentiates it from siblings like download_png and download_svg that return individual formats. However, it does not explicitly name those siblings or state the exact selection criterion, leaving some discrimination 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 phrase 'completed logo kit' implies this is for fetching the full set of assets, and the size-cap/zip_url note provides a concrete fallback. Yet there is no explicit when-to-use versus alternatives like download_png or download_svg, nor any stated exclusions or prerequisites.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It adds useful context: the endpoint is free, it should only be used after task success, authentication for larger exports uses the same Bearer key, and there is a size ceiling that routes users to png_url. It does not fully explain response format or error behavior, but it covers the key operational traits.

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

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

Two sentences with no redundancy. The main purpose is front-loaded, followed by usage timing and a clear alternative for larger exports. 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?

For a simple 3-parameter download tool with no output schema, the description is mostly complete: it states the return type, when to call it, the size-limit exception, and hints at authentication. More detail on the exact response body or explicit auth requirement for this endpoint would improve completeness, 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?

Schema coverage is 67%, with width and variant already described in the schema. The description adds only indirect meaning to task_id by saying to use it after a task succeeded, and it indirectly references width limits by suggesting png_url for larger exports. This is adequate but not particularly rich beyond the schema.

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

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

The description clearly states the tool returns a finished artwork as a PNG image, which distinguishes it from the sibling download_svg and download_logo_kit by format and scope. The phrase 'finished artwork' is slightly generic, but the overall purpose is specific and actionable.

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

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

It explicitly says to use this tool after a task has succeeded, and it gives an alternative path for larger exports by using the png_url from the task result. It does not explicitly contrast with download_svg or download_logo_kit, but the when-to-use and the primary alternative are clearly 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?

With no annotations present, the description carries the full burden of behavioral disclosure. It does reveal the output form (SVG markup) and a usage precondition, but it does not describe side effects, error handling, or what happens if called before the task completes.

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

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

Two short sentences with no filler or repetition. The core behavior is front-loaded, and the usage guidance is provided in the second sentence without wasting words.

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

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

The tool has two parameters, one with an unexplained enum, no parameter descriptions, no annotations, and no output schema. The description is too sparse to fully support correct invocation, especially with regard to 'variant' and expected return behavior.

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 does not compensate by explaining either parameter. 'task_id' and especially the 'variant' enum (original/black/white) are left entirely undefined, so the agent must guess their meaning.

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

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

The description states a specific verb ('Return') and resource ('finished artwork as SVG markup'), making the tool's function immediately clear. The explicit SVG markup format distinguishes it from sibling tools like download_png and download_logo_kit.

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?

'Use after a task succeeded' provides clear timing for when this tool should be called. It does not explicitly name alternatives or exclusions, but the task-success precondition gives useful 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?

With no annotations, the description carries the full disclosure burden and does it well: it reveals the tool is asynchronous ('returns a task... call wait_for_task'), costs 4 credits, and produces real vector paths on a transparent background rather than an embedded bitmap. It does not cover failure modes, auth, or rate limits, but the most decision-relevant behaviors are disclosed.

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 sentences, all load-bearing: purpose, output-format distinction, async flow, and the mascot parameter. The key scoping information is front-loaded before operational details, and there is 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 tool that is asynchronous, credit-priced, and integrated with a mascot system, the description covers the full call flow: trigger, poll via wait_for_task, and optional mascot reuse. It falls slightly short by not clarifying the relationship to download_svg/download_png siblings or typical failure behavior, but the essential contract is complete.

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

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

Schema coverage is 75%, below the 80% threshold, so the description must add some weight. It does: mascot_id is enriched with its semantic ('keep a consistent character across scenes') and its source (list_mascots), and the 'text prompt' phrase reinforces prompt. aspect_ratio gets no extra help, but its enum values are self-explanatory.

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: 'Generate professional, editable SVG artwork from a text prompt', and enumerates the artifact genres ('illustrations, icons, stickers and mascot scenes'). The 'not an embedded bitmap' clause plus the genre list implicitly separates it from generate_logo and vectorize_image, though 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?

Gives clear operating context: it names wait_for_task for the async result flow and list_mascots as the source for mascot_id. However, it stops short of explicit when-not guidance — it never routes logo requests to generate_logo or raster-to-vector jobs to vectorize_image, so 4 rather than 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by stating that execution is asynchronous, that credits are consumed (8 credits), and that the output must be retrieved via download_logo_kit. It does not mention failure modes, task retention, or auth requirements, but the essential runtime behavior is transparent.

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

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

The description is three focused sentences with no filler. It front-loads purpose and deliverables, then adds the reference option, async workflow, and cost. Every sentence contributes necessary invocation 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 tool with no output schema, the description covers the full lifecycle: what gets produced, how to consume the result asynchronously, which sibling to call next, and what it costs. It gives an agent enough to invoke the tool and follow through without additional discovery.

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 33%, so the description needs to compensate for undocumented parameters. It adds useful meaning for reference_role ('refine' vs 'inspiration') and brand_name (omit for symbol-only). However, it leaves request_id and the reference_image_url/base64 pairing unexplained, and does not clarify whether the image fields are required when a reference_role is set.

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: 'Generate a professional vector logo as editable SVG, delivered as a brand kit.' It enumerates concrete deliverables (mark, black/white variants, PNG exports, color palette), making the tool's purpose unmistakable and clearly distinct from siblings like generate_illustration or vectorize_image.

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

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

The description clearly explains the async workflow: call wait_for_task with the returned id, then download_logo_kit. It also explains when an optional reference is appropriate ('refine an existing identity' vs 'loose inspiration'). It does not explicitly name when a sibling tool should be chosen instead, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states what data is returned (plan and credit balance) and adds a helpful cost breakdown for related paid operations, which goes beyond the empty input schema. It does not explicitly state that the call is read-only and consumes no credits, but that is strongly implied by the tool's nature.

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

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

Two tight sentences: the first front-loads the purpose, the second delivers a compact, scannable pricing list. Every word earns its place with no filler.

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

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

For a zero-parameter, read-only account tool with no output schema and no annotations, the description is complete. It tells the agent what info it will receive and provides the pricing model needed to decide whether to proceed with paid operations. Nothing essential 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?

Zero parameters, so the baseline of 4 applies. The description appropriately contains no parameter info because there are no parameters to describe.

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 exactly what the tool returns: current plan and credit balance, which unambiguously identifies the account-info resource. It lacks an explicit verb but is not vague or tautological. Among the sibling tools (downloads, generation, tasks), it is clearly the only billing/account tool, so it is easy to distinguish.

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

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

The description does not explicitly say when to use this tool or name alternatives. However, listing credit costs (vectorize 1, generate/enhance 4, logo 8) strongly implies the tool should be used to check balance before consuming credits via those operations. The usage context is implied but not stated as 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?

With no annotations, the description carries the full burden. It usefully discloses the status vocabulary and that succeeded tasks include result download URLs, which is meaningful behavioral context. However, it does not describe the response shape for non-succeeded statuses, whether the call is non-blocking, or any operational behaviors such as task retention or errors.

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 tight sentences: the first states the core action and object, the second adds the status enum and success behavior. There is no filler, repetition, or unnecessary detail, and the most important information is front-loaded.

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

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

For a single-parameter read operation the description is mostly adequate, but with no output schema it should say more about what a non-succeeded response looks like and whether the agent should poll. It also does not position itself against wait_for_task, which is a significant sibling for this use case.

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 task_id is fully documented in the schema, including its provenance from generate_illustration or vectorize_image, so schema coverage is 100%. The description adds no additional parameter meaning beyond what the schema already provides, matching the baseline for high coverage.

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

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

Description uses a specific verb ('Fetch'), names the resource ('status of a task'), and enumerates the possible status values, which clarifies the tool's scope. It does not explicitly contrast itself with sibling tools like list_tasks or wait_for_task, so it stops short of full differentiation.

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

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

The description implies the tool is for checking a single task's status but provides no guidance on when to use it instead of list_tasks (listing all tasks) or wait_for_task (blocking until completion). No exclusions, prerequisites, or alternative conditions 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?

With no annotations, the description carries the full burden. It indicates a read-only listing operation and defines the scope ('ready-to-use'), but it does not describe the return format (e.g., array of objects with id and properties) or any potential side effects, rate limits, or authentication requirements. The behavior is implied but not fully specified.

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

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

The description is two sentences long, front-loads the primary action, and each sentence adds meaningful information: definition, usage guidance, and origin. 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?

Although there is no output schema, the description gives enough context for a simple list tool: it clarifies what the tool returns (ready-to-use mascots) and how to use the results. It does not specify the exact structure of the return value, but the naming and typical conventions make it reasonably complete for an agent to invoke correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description correctly does not attempt to describe parameters since none exist. The schema is fully covered trivially, and the description adds relevant context about how the returned IDs are used, which indirectly explains the absence of parameters.

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

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

The description clearly states the action (list) and the resource (mascots), and defines what mascots are ('consistent characters'). It also distinguishes from siblings by focusing on ready-to-use mascots and mentioning how they are used elsewhere, making the tool's purpose unambiguous.

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

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

It provides clear context on how to use the tool's output ('Pass a mascot id to generate_illustration') and indicates that mascots are created in the dashboard, implying this tool is for listing only. However, it does not explicitly state when not to use it or name alternatives, so it lacks explicit exclusion criteria.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds the ordering behavior ('newest first') and recency scope, but does not explicitly state that the operation is read-only, what the return payload contains, or how empty/error cases behave. For a simple list operation this is acceptable but not complete.

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 with no redundant words. The action, target, and ordering are all present and front-loaded.

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

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

The tool is simple (one optional parameter, no output schema), and the description conveys the core purpose. However, it omits return-value expectations, parameter semantics, and any safety-related notes. An agent could still invoke it correctly, but some inference is required.

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%: the description never mentions the 'limit' parameter. The input schema documents type, default, minimum, and maximum, but the description adds no semantic meaning (e.g., 'limit controls how many tasks are returned'). Because coverage is below 50%, the description should compensate and fails to do so.

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 ('List'), a resource ('the user's most recent tasks'), and an ordering constraint ('newest first'). It distinguishes itself from siblings like get_task (single task) and generate_* (creation) without ambiguity.

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

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

The description implies when to use the tool (when a list of recent tasks is needed) but provides no explicit guidance about when not to use it or how it relates to alternatives. There is no mention of get_task or wait_for_task as better suited for specific scenarios.

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

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

With no annotations, the description carries the behavioral disclosure burden. It reveals that the operation is asynchronous, that credits vary by mode, that no_background defaults to true, and that enhance mode redraws with AI. Missing details like auth requirements or exact response shape are minor relative to the strong async and cost transparency provided.

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?

Every sentence earns its place: format/size constraints, input source, default behavior and cost, mode alternatives, and async polling. The most identifying purpose is front-loaded, and the description is compact without 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?

Given no output schema, the description covers formats, size, required input source, modes, credits, and async follow-up via wait_for_task. It could state the exact returned task/result shape, but the explicit polling instruction makes the workflow understandable and actionable.

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 80%, but the description adds meaning beyond the schema: it clarifies that image_url or image_base64 are the input alternatives, no_background defaults to true and isolates the subject, and mode direct vs enhance affects tracing behavior and credit cost. It does not elaborate on prompt, but the schema already documents it.

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

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

The description uses a specific verb and resource: 'Convert a raster image ... into a clean, editable SVG.' It enumerates supported formats and size limits, making the tool's purpose easy to identify. It does not explicitly compare to sibling tools like download_svg, but the conversion framing distinguishes it sufficiently.

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 practical usage direction: provide image_url or image_base64, choose no_background behavior, select direct or enhance mode, and poll with wait_for_task. It does not explicitly state this tool's alternatives or when not to use it, but the context is clear enough for an agent to select it appropriately.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It transparently states blocking behavior, terminal states, and timeout behavior. However, it does not disclose what happens on timeout (e.g., return value, error, or current status) or what the tool returns when the task settles.

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 no filler. The core behavior, the recommended usage, and the expected duration are all front-loaded and 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?

Given there is no output schema and no annotations, the description should explain the return behavior and timeout results. It covers blocking semantics and timing well but leaves the caller guessing about what a successful or timed-out invocation returns.

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 compensate for undocumented parameters. It only loosely references the timeout concept and does not explain task_id or timeout_seconds beyond what the schema constraints already show, making the parameters harder to reason about.

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

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

The description uses a specific verb and resource: 'Block until a task settles (succeeded/failed) or the timeout passes.' It clearly differentiates itself from get_task by framing this as a blocking wait rather than a polling call.

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

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

It explicitly names get_task as the alternative and says this tool is 'Preferred over polling get_task in a loop,' giving clear usage direction. It also provides timing context ('Generation typically takes 10-60 seconds'), though it does not state edge cases such as when a caller should avoid waiting.

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