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

With no annotations, the description carries the full burden and does well: it discloses the return value (clip id), the async completion pattern (ready when wait_for_job(model='audio-clip') reports done, usually seconds), the character cap, and how to handle long scripts. It omits cost/auth expectations, but for a creation tool this is unusually informative.

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

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

Three sentences, front-loaded with purpose and mode selection, then return value and follow-up. The opening 'The soundtrack every video model takes as input' is slightly promotional but still functional as positioning; overall every sentence 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?

No output schema and no annotations, yet the description covers the return type (clip id) and the readiness-check workflow via wait_for_job, plus the downstream consumption pattern. An agent has everything needed to invoke it and handle the result.

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% so baseline is 3, but the description adds real meaning beyond it: it makes explicit that text requires exactly one voice (voice_id or voice_user_id), that file_path is an alternative to text rather than a supplement, and that voice_user_id is specifically the cloned voice from list_voices with include_cloned. That mutual-exclusivity constraint is not obvious from the schema alone.

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+resource ('create_audio_clip' producing speech from text or uploading a recording) and immediately frames its role as 'the soundtrack every video model takes as input.' An agent can distinguish it from sibling creation tools like create_craftstory2_video 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?

Explicitly lays out the two mutually exclusive modes — text (<=2000 chars) plus exactly one voice, OR file_path for an upload — which is exactly the decision an agent must make. It also routes onward to wait_for_job for completion and to create_craftstory2_video for multi-clip scripts, naming siblings by 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?

No annotations exist, so the description carries the full burden, and it delivers: credits are charged on create (with a pointer to preview_cost), refunded on failure, the job returns an id and initial status, and generation takes 8-15 minutes requiring repeated polling. This is exactly the operational context an agent needs before committing.

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

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

A single dense paragraph that is front-loaded with what the tool produces, then input formats, then cost and lifecycle. Every clause is substantive, though the run-on structure packs many distinct facts into one block rather than separating them.

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

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

For an 11-parameter async generation tool with no output schema and no annotations, the description covers the return values (job id + initial status), the async polling pattern, cost/refund behavior, and input alternatives. Nothing essential to 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 coverage is already 91%, so the baseline is 3. The description adds useful semantics on top: resolution is WIDTH_HEIGHT with portrait vs landscape values, audio can be any length and plays in order, and the photo may come from image_url, image_path, or a scene_id custom avatar. The format hint for resolution goes beyond the bare enum.

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?

Starts with a specific verb and resource ("Start a craftstory-2 generation") and immediately describes the input modes: a person's photo, a custom avatar scene via scene_id, speaking audio clips with lip-sync and gestures. The named model (craftstory-2) implicitly separates it from the sibling create_minimax_h3_video, so an agent can pick correctly.

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?

Describes the full invocation workflow: start the job, poll with wait_for_job(model='craftstory-2') until done, then get_job_result, and use upscale_video for 1080p afterwards. It does not give an explicit exclusion rule against create_minimax_h3_video, but the model naming and the described pipeline give clear 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 burden and delivers: cost of 3.3 credits per billed second charged at create time, first-15s billing cap in reference mode, 768 px short-side output, orientation inherited from the photo, and a 1-3 minute runtime with the required follow-up poll. These are exactly the operational traits an agent cannot infer from the schema.

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

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

A single dense paragraph, but it is front-loaded with the purpose and every clause carries information (cost, limits, duration, follow-up). It is slightly packed — cost, resolution, and latency are interleaved with mode semantics — but no sentence is filler.

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

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

For a 9-parameter generation tool with no output schema and no annotations, the description covers the full lifecycle: required inputs per mode, reference caps, billing, output format, the returned job id, and the polling step. An agent can invoke and follow through correctly without opening anything else.

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 only 56%, and the description compensates well: it specifies user_prompt is required in basic but optional in reference, that audio_clip_id drives lip-sync in reference mode, the per-type reference_files limits (8 image / 3 video / 2 audio) with reference_captions matched by order, and the 5-15s range and default of 8 for requested_duration_s. Only name, image_url, and image_path are left unexplained.

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 ('Start a minimax-h3 generation from one photo') and immediately names the two operating modes, so the agent knows exactly which generation pipeline this is versus siblings like create_craftstory2_video. The scope (one photo, up to 15s) is concrete and 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?

Explicitly routes between mode='basic' and mode='reference' with the condition that selects each (soundtrack generated by model vs. audio_clip_id driving lip-sync), and tells the agent to call wait_for_job(model='minimax-h3') afterward. It does not, however, state when to prefer this tool over a sibling video generator, so it stops short of full alternative 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?

No annotations exist, so the description carries the full burden and largely does: it discloses the model-dependent field location of the asset, that URLs are signed and expire in 7 days, that re-calling yields a fresh link, and that parameters and credits are returned. It omits the important edge case of what happens if the job is not yet finished.

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 dense sentences, front-loaded with what is returned and then the per-model field mapping. Every clause carries information; the only cost is that the run-on structure makes the 7-day expiry easy to skim past.

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 no annotations, the description does the work of explaining the return payload (video/video_url/file, parameters, credits) and the URL lifetime. The notable gap is the failure/pending-state behavior, which matters for a job-result retrieval tool alongside get_job_status.

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. It effectively enumerates the meaningful `model` values and maps each to an output field, which adds real meaning, but the required `id` parameter is never explained (UUID of the job, accepted formats, source of the value).

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

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

Opens with a specific noun phrase ('Full record of a job') and the title narrows it to a finished job, so the resource and the completion condition are clear. It does not explicitly differentiate itself from siblings get_job_status / wait_for_job, which an agent must infer.

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

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

Usage is only implied: the title says 'finished job' and 'call again for a fresh link' hints at re-fetching, but there is no explicit when-to-use-versus-get_job_status/wait_for_job routing. An agent likely infers the right moment, but nothing in the text confirms it.

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 full burden and does disclose meaningful behavior: the returned fields (status, status_percentage, status_failed, credits_refunded) and the terminal-state semantics, including the failure variants failed*, rejected_* and not_pass_moderation for audio. It omits auth requirements or rate limits, but covers the operationally critical 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?

Three dense sentences with the status/return information front-loaded and the alternative routing last. No filler, though the terminal-state enumeration is terse enough that readability suffers slightly.

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?

No output schema or annotations exist, so the description compensates by enumerating returned fields and terminal states, which is what an agent most needs. The main gap is parameter guidance given the 0% schema coverage, but the core polling-vs-check decision guidance is present.

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 both parameters, yet it explains neither the 'id' (job UUID) nor the 'model' enum semantics beyond loosely implying 'video job or audio clip'. The enum values are somewhat self-descriptive, but the description adds little beyond what the schema naming already conveys.

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 (job status) and scopes the resource precisely as 'a video job or audio clip'. It also names the sibling wait_for_job, so an agent can distinguish this from alternatives without opening any schema.

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

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

Explicitly names the alternative ('Prefer wait_for_job, which polls for you'), giving clear routing logic. However, it does not state the positive condition under which this tool should be chosen (e.g., non-blocking checks), leaving that 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?

With no annotations, the description carries the full burden: it does disclose the mode-switching behavior of avatar_id and the voice_kind routing semantics ('user' vs 'library'), which is real behavioral context. However, it never states the operation is read-only/side-effect free, nor mentions pagination, result size, or auth requirements, leaving gaps an unannotated list tool should cover.

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 that are front-loaded with the core purpose before moving to id-routing detail; every clause about voice_user_id/voice_id/scene_id earns its place. It is dense but not padded.

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?

No output schema exists, so the description must describe returns, and it does: avatars carry a default voice {id, voice_kind} and scenes expose scene_id. Minor omissions remain (no pagination or error behavior), but the cross-tool id plumbing is complete enough to call the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining the downstream consumption of avatar_id and the voice_kind enum-like semantics for the returned voice object. That added meaning about how ids are used justifies a 4.

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 (custom avatars trained in CraftStory) and additionally covers the dual mode where avatar_id returns scenes instead of the list. An agent can distinguish this from list_voices and list_models because the description names the avatar/voice/scene domain 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 conditional guidance: omit avatar_id to list avatars, pass avatar_id to list that avatar's scenes, and explains how the returned ids feed create_audio_clip and create_craftstory2_video. It does not explicitly say when to prefer a sibling (e.g. list_voices) over this tool, so it stops short of a full 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?

No annotations are provided, so the description carries the burden. It discloses the returnable fields (status, modes, limits, credit prices) and, importantly, that a model can be in a 'paused' state, which is operational context an agent needs before invoking a generation sibling. It never explicitly states this is a read-only/no-input operation, so it stops short of full disclosure.

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 purpose, then the routing advice. The parenthetical model summaries are somewhat long, but each clause carries decision-relevant detail (length ranges, audio vs description driven) that helps pick the right sibling tool.

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, but the description enumerates the returned content (status, modes, limits, credit prices) plus per-model capability summaries, so an agent knows what it will receive and how to act on it. Nothing needed to call a zero-param listing tool 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, which is the baseline-4 case. The description reasonably implies a no-argument listing call and adds no misleading parameter claims.

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 resource (catalogue of video models behind this server) and enumerates exactly what each entry contains: status, modes, limits, credit prices. The two named models (craftstory-2, minimax-h3) let an agent distinguish this from sibling creation tools like create_craftstory2_video.

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 routes the agent: 'Call this first when unsure which model fits, or to check that a model is not paused.' That is both a when-to-use and a stated alternative-selection rationale, with no inference required.

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, and it does disclose real behavioral context: the two distinct ID namespaces (voice_id vs voice_user_id) and the out-of-band cloning limitation. It omits pagination, ordering, and whether library voices are account-scoped, which are the remaining gaps for a read-only list.

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 with zero filler, lead sentence front-loads what is returned, and each subsequent sentence covers exactly one new fact (the flag, the cloning limitation). Nothing is redundant with the tool name or title.

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 read tool with no output schema, the description compensates by naming the returned fields and the two ID namespaces. Only pagination/ordering behavior and error cases are unaddressed, which is a minor gap at this complexity level.

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%, so baseline is 3, but the description adds meaning the schema does not: that the cloned voices surfaced by include_cloned are addressed by voice_user_id rather than voice_id. That mapping is operationally essential and is absent from the boolean's own 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+resource (list library voices) and immediately enumerates the returned fields (id, name, language, gender), then ties each ID type to its downstream consumer (voice_id in create_audio_clip, voice_user_id for cloned voices). An agent can distinguish this from list_avatars and list_models without opening any schema.

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

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

Explicitly tells the agent how to reach cloned voices (include_cloned=true) and which parameter to pass the resulting IDs into, plus a negative constraint: voices are cloned in the CraftStory app, not via the API, which prevents a futile search for a clone tool. It stops short of naming an alternative tool or exclusion conditions.

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 and does disclose key behavior: it is side-effect-free ('without creating anything') and it exposes the exact pricing rules, including per-second rates, the empty-lipsync discount, per-job rounding, and the MiniMax H3 flat rate. It does not state the return shape (a scalar credit total), which is the main remaining 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?

Front-loaded with the core purpose, then a dense but relevant rate breakdown; every sentence earns its place. The opening clause is slightly ungrammatical ('Credits a craftstory-2 job would cost'), costing a point.

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 pricing tool with no annotations and no output schema, the description explains the cost model thoroughly enough to predict the result. It falls short only on the unexplained sync_so mode and on not stating what the returned value looks like.

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, and it partially does by tying resolution values (480p/720p) and lipsync_mode=empty to concrete rates. However sync_so is never explained and audio_clip_ids semantics (what counts as a billed second) are left undefined, so the mapping is incomplete.

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: it returns the credit cost a craftstory-2 job would incur for given audio clips and settings. The phrase 'without creating anything' explicitly separates it from the create_* siblings, so an agent can pick the right tool without opening schemas.

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

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

Usage is implied rather than stated: 'without creating anything' suggests a pre-flight/dry-run estimate before calling create_craftstory2_video, but it never says when to prefer this over alternatives or that it must precede creation. Nothing is misleading, but the routing is left to inference.

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

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

With no annotations, the description carries the full burden and mostly does: it discloses non-destructiveness (original preserved), a concrete cost (0.2 credits per second), model-specific constraints, and the polling workflow. It does not mention authentication, rate limits, or failure behavior, which keeps 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?

Dense and front-loaded: the primary behavior, then model-specific rules, then cost, then the next step. Every fragment adds information. The telegraphic style ('craftstory-2: ...', 'minimax-h3: ...') is compact but slightly terse, requiring careful parsing.

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 3-parameter tool with no output schema and no annotations, the description covers the essential behavioral facts: cost, non-destructiveness, model constraints, and polling follow-up. It omits return-value specifics beyond the job id and any error or retry semantics.

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 only 33%, so the description must compensate, and it does: it explains that resolution applies only to craftstory-2 and maps the enum values to source resolutions (1080_1920 from 720_1280, etc.), plus that minimax-h3 needs no resolution. The 'id' parameter is only implied via 'Poll the returned id' rather than explicitly defined as the source or job identifier.

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 ('Creates a NEW job with the upscaled result') and immediately clarifies the non-destructive nature ('the original stays'), distinguishing it from create_craftstory2_video / create_minimax_h3_video siblings which generate rather than upscale.

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 per-model guidance: which models need a resolution, which resolutions are valid for craftstory-2, and that minimax-h3 is always 2x so 'no resolution needed'. Also routes to wait_for_job for polling. It stops short of an explicit when-to-use-this-vs-alternatives statement (e.g. when upscaling is preferable to regenerating).

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 and does well: it discloses the polling cadence, the timeout bounds, the rationale for the 55s max (MCP client 60s cut), the repeat-call loop behavior, and progress notifications. It stops short of describing timeout/error outcomes or auth requirements.

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, no filler, with the core polling contract front-loaded before the retry guidance and per-model timing. 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 must convey return semantics; it does by explaining the state='running' vs terminal distinction and the progress notifications. Coverage is good, with minor gaps around timeout exhaustion and error 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 coverage is only 33% (only timeout_s is documented in the schema), but the description compensates by restating the timeout default/max and, more valuably, attaching concrete runtime expectations to each model enum value. The id parameter remains unexplained but 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?

States a specific behavior: polls a job's status on an interval and returns as soon as it reaches a terminal state, with a bounded timeout. This clearly reads as the 'wait until done' counterpart to get_job_status/get_job_result, 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?

Explicitly tells the agent what to do when state='running' (call it again) and provides per-model expected durations so the agent can judge feasibility. It does not explicitly contrast with get_job_status for a one-shot check, which is the only real gap.

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