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

No annotations are provided, so the description must carry the full behavioral burden. It discloses the rigging prerequisite and the optional post-processing structure, but omits whether the tool creates an asynchronous task, what it returns, and whether there are permission, cost, or rate-limit concerns.

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

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

The description is front-loaded with the core action and then documents parameters efficiently. Every sentence carries useful information, and the link for action_id is a helpful addition without bloat.

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 create-task tool with no annotations, no output schema, and a nested object parameter, the description covers the inputs adequately. However, it does not explain the return value or task lifecycle, which an agent would need in order to poll with retrieve_animation_task or stream_animation_task.

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 document the parameters itself. It successfully explains all three: rig_task_id as a completed rigging task ID, action_id as an animation library identifier with a reference link, and post_process as an optional object with operation_type and fps details.

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

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

The description states a specific verb and resource: applying an animation to a rigged character. It implicitly distinguishes from rigging by requiring a completed rigging task, but it does not explicitly contrast with sibling tools like retrieve_animation_task or stream_animation_task.

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 one important prerequisite: rig_task_id must be from a completed rigging task. However, it does not say when to use this tool versus alternatives (e.g., retrieve or stream animation tasks) or mention any exclusions.

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

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

With no annotations, the description carries the full behavioral burden and does add useful details: accepted image input formats, allowed enum values, and the effect of skipping texturing. However, it does not disclose that this is likely an asynchronous task creation endpoint, what it returns, or any auth/rate-limit/cost behavior.

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

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

The description is front-loaded with the core action and then compactly enumerates key constraints without filler. It is dense but appropriately sized for a 14-parameter tool, though it could be more scannable if structured.

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 14-parameter creation tool with no annotations and no output schema, the description is incomplete: it omits task lifecycle details, expected return behavior, and half the parameters. An agent can make a basic call but lacks enough context to use the tool reliably across its full option set.

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 14 parameters, so the description must compensate. It explains 7 parameters including image_url format constraints and enum values for ai_model, topology, symmetry_mode, pose_mode, and origin_at, but leaves auto_size, enable_pbr, should_remesh, target_formats, texture_prompt, target_polycount, and texture_image_url undocumented.

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

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

The description states a specific verb and resource: generate a 3D model from an input image. It is clear enough to distinguish from text-to-3D, but it does not explicitly differentiate from sibling tools like create_multi_image_to_3d_task or name alternatives.

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

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

There is no explicit guidance on when to use this tool versus create_text_to_3d_task, create_multi_image_to_3d_task, or the streaming/retrieval siblings. The mention of should_texture=false is a parameter behavior note, not a when-to-use guideline.

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 real behavioral detail: per-model allowed aspect ratios, the default '1:1', the mutual-exclusion rule, and that remove_background yields a transparent RGBA PNG. It omits the async task model (that a task id is returned and must be polled with retrieve_image_to_image_task) and any auth/cost constraints, 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?

It is front-loaded with the core action and then walks parameters in a logical order with no filler sentences. It runs as one dense block rather than a structured list, which costs a little readability on first parse but nothing is wasted.

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

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

For a 6-parameter creation tool with no output schema and no annotations, the description covers inputs, constraints, defaults, and one output-format nuance (RGBA PNG). What is missing is the task lifecycle — that this enqueues work and must be polled via retrieve_image_to_image_task — which matters given the create/retrieve/list/stream family.

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

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

With 0% schema description coverage the description must do all the work, and it does: it enumerates the ai_model values, constrains reference_image_urls to 1–5 public URLs or base64 data URIs, and gives valid aspect_ratio values per model family with a stated default. Every parameter is given meaning beyond its bare type.

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 a new image') and adds the defining scope clause 'based on reference images and a text prompt', which is exactly what separates it from the sibling create_text_to_image_task. An agent can pick it out of a 50-tool list 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?

The required reference_image_urls plus 'prompt describes the transformation' makes the use case (image-to-image editing/restyling) clear, and it states a hard exclusion: 'Cannot combine aspect_ratio with generate_multi_view'. It does not name an alternative sibling or spell out when NOT to use it, so it falls 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses one useful trait (should_texture=false yields a mesh only), but never says this is an asynchronous task creation that returns a handle requiring retrieve_/stream_/list_ calls, nor mentions cost, credit consumption, or what happens on failure.

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 purpose is front-loaded, then the remaining sentences are terse value enumerations with no filler. It reads as a compact parameter reference, which suits a 14-parameter tool, though the tail can feel like a dump.

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 14-parameter creation tool with no annotations and no output schema, the description omits half the parameters and says nothing about the async task lifecycle an agent must handle after calling. What is present is accurate, but the definition is not complete enough to call the tool correctly without opening the schema and guessing.

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 schema declares no enums, so the description's enumerated values for ai_model, topology, symmetry_mode, pose_mode, origin_at, and the image URL constraints are genuinely valuable. However, 7 of 14 parameters (auto_size, enable_pbr, should_remesh, target_formats, texture_prompt, texture_image_url, target_polycount) get no mention at all, leaving half the surface undocumented.

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

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

Opens with a specific verb and resource: 'Generate a 3D model from 1–4 input images.' The 1–4 image range implicitly differentiates it from the single-image sibling, but the description never names create_image_to_3d_task or create_text_to_3d_task, so the differentiation is left to inference.

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

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

Usage is only implied by '1–4 input images' — an agent can infer this is the multi-image variant, but there is no explicit when-to-use/when-not guidance against the many sibling creation tools (single-image, text-to-3D, remesh).

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 a meaningful behavioral mode (format-only conversion skips remeshing) and enumerates accepted input formats, but says nothing about the async task lifecycle, whether the source model is modified or preserved, cost/credit implications, or what create returns. Enough to call it correctly, not enough to predict consequences.

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 dense sentences, purpose first, then input sourcing, then enum vocabularies, then the special mode. No filler and no repetition of anything a structured field already provides.

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 unannotated creation tool with no output schema, the description should at least hint at the return value (a task ID to poll) and that the operation is long-running. Inputs are fully covered, the result contract is not, and the mismatch with the empty input schema is left unexplained.

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 declared schema has zero properties, so the description is the only source of parameter meaning: it names five inputs, gives two enum vocabularies ('quad'/'triangle', 'bottom'/'center'), lists file extensions, and flags the either/or constraint. The only deduction is that these parameters are absent from the schema, leaving an agent unsure whether to trust the description or the empty object.

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 verb+resource pair is precise: 'Remesh and optimize an existing 3D model', with the operand further narrowed to either a completed task ID or a model URL. That cleanly separates it from the many create_* siblings that originate models (text-to-3d, image-to-3d) rather than post-processing an existing one.

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 states the two mutually exclusive input paths (input_task_id OR model_url) and when to choose the degenerate mode (convert_format_only=true for format conversion without remeshing). It stops short of naming the follow-up tools (retrieve_remesh_task / stream_remesh_task) or any when-not-to-use condition, so no explicit alternative routing.

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

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

With no annotations, the description carries the burden and does disclose defaults (enable_original_uv default true) and enum values for ai_model, plus the exclusive-parameter constraints. It omits key behavior: this appears to be an asynchronous task creator whose result must be fetched via retrieve_retexture_task/stream_retexture_task, and it says nothing about cost, balance, or failure modes.

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

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

Dense and front-loaded: purpose first, then input sourcing, then style guidance, then tuning flags. Every sentence adds facts; there is no filler, though the wall of semicolon-separated clauses is a little hard to scan.

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

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

Covers inputs thoroughly but not the calling contract: no output schema exists, yet the description never says a task ID is returned or that the job is asynchronous and must be polled via the retrieve/stream siblings. For a create-task tool in a large async task family, that is the main missing piece.

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

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

The input schema exposes zero properties, so the description is the only source of parameter meaning, and it supplies names, accepted values, formats (.glb/.gltf/.obj/.fbx/.stl), length limits (600 chars), and defaults. It carries real weight, though coverage may be incomplete relative to the documented parameter 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?

States a specific verb and resource: 'Apply new textures to a 3D model using text or image style guidance.' An agent can distinguish this from create_text_to_3d_task or create_text_to_texture_task on the concept level, though the description never names or contrasts 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?

Gives useful input-combination rules (either input_task_id or model_url; either text_style_prompt or image_style_url, mutually exclusive), which is genuine selection guidance. But it says nothing about when to choose retexture over the sibling create_text_to_texture_task or text-to-3D pipelines, and no prerequisites are stated.

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

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

With no annotations, the description carries the full disclosure burden. It does add real behavioral context — the either/or input contract, the 'completed Meshy task' prerequisite, the height default and 0.1–15 range, and a quality caveat about humanoid topology. But it never states that this is an asynchronous job that returns a task ID to be polled via retrieve_rigging_task/stream_rigging_task, whether credits are consumed, or whether it is idempotent.

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, each doing distinct work: purpose, input routing, parameter semantics, and a quality caveat. The core action is front-loaded and there is no filler or restatement of the tool name.

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

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

With no annotations and no output schema, the description should cover the full call contract. It handles inputs well but is silent on the return value (presumably a task ID), the async lifecycle, and how the result is later fetched, leaving the agent to infer the polling pattern from sibling names. Adequate for a first call, incomplete for the whole workflow.

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

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

The input schema declares zero properties, so the description is the only source of parameter meaning — and it supplies genuine detail: input_task_id vs model_url exclusivity, height_meters default 1.7 with a 0.1–15 range, and texture_image_url being optional PNG base color. The gap is that these four documented parameters do not appear in the schema at all, so an agent validating against the schema would see an empty object.

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+resource: 'Auto-rig a 3D character model for animation.' Combined with the create_/retrieve_/list_/stream_/delete_ rigging family of siblings, an agent can tell this is the task-creation entry point without opening any schema. It stops short of naming a sibling explicitly, so it doesn't earn 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?

It gives concrete input routing: 'Provide either input_task_id ... or model_url', which tells the agent the two mutually exclusive paths and which input type each expects. It also flags the best-fit scenario ('works best on humanoid characters with a clear limb/body structure'). It does not say when to prefer this over the sibling create_* tools or what to do when the source task is not yet complete.

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 load and does it well: it discloses that the operation is a two-step asynchronous task (draft then texture), imposes a prerequisite state (SUCCEEDED) and enumerates model-specific restrictions (ultra_mode preview-only for meshy-7, art_style deprecated for meshy-6). It does not mention credit cost or that the task must be polled via the retrieve/stream siblings, which an agent would need to know.

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 workflow, then the mode-specific requirements, then a compact enum list. Dense but every sentence carries information; 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?

Rich on inputs and workflow, but there is no output schema and the description never says what is returned (presumably a task id) or that the caller must then use retrieve_text_to_3d_task / stream_text_to_3d_task. Given the empty schema and missing output contract, the description leaves a real gap for an agent trying to complete the operation.

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

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

The input schema declares zero properties, so the description is the sole source of parameter meaning and it delivers enum values for ai_model, model_type, art_style, topology, symmetry_mode, pose_mode and origin_at plus cross-parameter constraints. Gaps: no defaults, and it names many parameters that do not appear in the schema at all, leaving the agent unsure what it can actually pass.

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 a 3D model from a text prompt') and front-loads the two-step workflow. The phrase 'from a text prompt' implicitly separates it from the image-based siblings (create_image_to_3d_task, create_multi_image_to_3d_task) that otherwise share the same verb.

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

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

Explicitly sequences the two modes: preview first, then refine gated on a SUCCEEDED preview_task_id. It doesn't cover when to use this tool versus the image-to-3D or retexture siblings, but the internal workflow guidance is clear and actionable.

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 real behavioral facts (mutual exclusion between generate_multi_view and aspect_ratio, and that remove_background yields a transparent RGBA PNG). It is silent on whether the call is asynchronous, whether it returns a task ID, credit cost, and whether failures are retryable — significant omissions for a creation endpoint.

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 dense per-parameter constraints with no filler or repeated information. Every clause adds a fact an agent would otherwise have to guess.

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?

Parameter-level coverage is excellent, and with no output schema the RGBA PNG note usefully hints at the return. But a create_*_task tool in a suite full of retrieve/stream/list siblings should tell the agent how to obtain the result, which it does not.

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

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

Schema coverage is 0% and all six parameters are undocumented in the schema, so the description does the heavy lifting well: it enumerates ai_model values, gives per-model aspect_ratio valid sets with a default, lists pose_mode values, and explains the two booleans' effects. Only `prompt` is left uncharacterized, which keeps it short of a 5.

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 an image from a text prompt." The phrase "from a text prompt" implicitly separates it from create_image_to_image_task, but it never names that sibling or any other alternative, so the differentiation is inferred rather than stated.

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

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

The description says nothing about when to pick this over create_image_to_image_task, nor about the task lifecycle implied by the name — the many retrieve_/list_/stream_/delete_ siblings suggest an async job that must be polled, yet no guidance is given on that workflow.

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 burden. It usefully discloses that the endpoint is actually /v1/retexture and how parameters are remapped, which is valuable. However, it omits that this is an asynchronous task-creation operation and says nothing about permissions, cost, or lifecycle.

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?

Purpose is front-loaded, followed by the alias caveat and parameter-mapping notes. Sentences are dense and mostly earn their place, though the forwarding detail is slightly verbose relative to what's explained.

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

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

For an 8-parameter, no-annotation, no-output-schema mutation tool, the description covers the tricky mapping and required param but leaves three parameters undocumented and never clarifies the async task semantics. Adequate but with clear gaps.

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

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

Schema coverage is 0% across 8 parameters, so the description must compensate. It explains model_url is required, the style_prompt/object_prompt aliasing, and enable_original_uv/enable_pbr forwarding, covering several params. But art_style, resolution, and negative_prompt are left completely undocumented.

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

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

States a clear verb and resource: 'Apply textures to a 3D model using text prompts.' It also reveals it's a compatibility alias backed by the retexture API, which meaningfully distinguishes it from the plain retexture siblings. It stops short of explicitly directing agents between this and create_retexture_task.

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 'Compatibility alias' framing implies this exists for backward compatibility and uses the retexture endpoint, but it never states when to prefer this over create_retexture_task or what input conventions differ. Usage context is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full disclosure burden and fails it. It does not say whether deletion is permanent or reversible, whether the task's artifacts (meshes, outputs) are also destroyed, what happens if the task is still running, or what permissions/ownership are required.

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

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

The description is a single clean sentence with zero padding and the verb front-loaded, so it is concise. However, this is brevity by omission rather than efficiency — there is no content to be well-structured.

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 destructive mutation tool with no annotations, no output schema, and 0% parameter coverage, the definition is far too thin. An agent cannot determine reversibility, side effects on related resources, or return behavior before committing to an irreversible call.

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

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

Schema description coverage is 0% — task_id is an undocumented string — and the description adds no meaning about its format, source (from create/list calls), or behavior on an unknown/unowned ID. The single parameter is guessable but entirely unelaborated.

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 sentence 'Delete an animation task' is a near-verbatim restatement of the tool name delete_animation_task, adding no scope or differentiation. It does identify the verb and resource, but a reader learns nothing they couldn't infer from the name alone, and nothing distinguishes it from the ~10 sibling delete_* 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?

There is no guidance on when to delete versus retrieve/list/stream an animation task, no preconditions (must the task be completed or cancelled first?), and no statement of consequences. The agent must infer everything from the tool 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 are provided, so the description carries the full behavioral burden and discloses nothing: not that the operation is destructive and irreversible, what happens to an in-progress generation, whether the task data is recoverable, or what an error/response looks like. Only the word 'Delete' implies mutation, and that comes from the name.

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 zero padding, but its brevity reflects under-specification rather than efficiency — it is front-loaded with nothing but a restated name.

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

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

For a destructive single-parameter tool with no annotations, no output schema, and zero schema description coverage, the description leaves an agent without the information needed to call it safely or correctly; it should at minimum state irreversibility and where task_id comes from.

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, task_id. The description says nothing about its format, where to obtain it (presumably from create_/list_image_to_3d_tasks), or whether unknown IDs error out, so it fails to compensate for the undocumented 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 names a specific verb and resource ('Delete an image-to-3d task'), which lets an agent separate it from delete_remesh_task or delete_rigging_task by resource type. However, it is essentially the tool name with spaces added — no scope, no effect, no distinguishing detail beyond what the name already conveys.

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 statement of when to use this versus retrieve_image_to_3d_task, list_image_to_3d_tasks, or when deletion is appropriate. No prerequisites (e.g., task must be complete or can be in-flight) and no mention that deletion is irreversible.

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 full behavioral burden. It implies a destructive operation by using "Delete," but does not disclose irreversibility, side effects, required permissions, failure behavior, or what happens to a non-existent task.

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

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

The description is a single front-loaded sentence with no wasted words. It is concise and structurally clean, though extremely minimal for a destructive task 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?

Given no annotations, no output schema, and 0% parameter description coverage, the description is incomplete for a deletion tool. An agent would not know whether deletion is permanent, what the return value is, or how to handle errors.

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

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

Schema description coverage is 0%, and the description says nothing about task_id. It does not explain where the task_id comes from, its format, or what happens if it is invalid. With only one required parameter, the identifier is somewhat inferable, but no semantic value is added.

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

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

The description states a specific verb and resource: "Delete an image-to-image task." This clearly distinguishes it from sibling delete tools such as delete_image_to_3d_task and delete_text_to_image_task. It lacks broader scope details, but the core purpose is unambiguous.

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

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

There is no guidance on when to use this tool versus retrieving or listing tasks, no prerequisites, and no warning about deletion consequences. The agent can infer it is for deletion, but no usage context is provided.

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 full burden of behavioral disclosure. For a destructive operation it says nothing about irreversibility, whether the task must be idle/completed, or what happens to associated artifacts — only the word 'Delete' signals mutation.

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?

It is a single front-loaded sentence with no waste, but that brevity comes from under-specification rather than efficiency — the one sentence conveys no information beyond the tool's name.

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

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

For a destructive tool with no annotations, no output schema, and an undocumented parameter, the description is far too thin. An agent would not know the consequences of the call, the ID format, or the failure modes.

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 has 0% schema description coverage and the description adds nothing about its format or how to obtain it (e.g., from list_multi_image_to_3d_tasks or create responses). With low coverage the description should compensate but 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?

The description states a specific verb ('Delete') and the exact resource ('a multi-image-to-3d task'), which does let an agent distinguish it from retrieve/list/create siblings of the same family. However, it is essentially a restatement of the tool name with no elaboration on what deletion entails.

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 use this instead of the other delete_* siblings, nor on prerequisites (must the task be complete? does it need to be stopped first?). The agent is left to infer everything from the name alone.

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 for a destructive operation, yet it says nothing about permanence, whether deletion is reversible, what happens to an in-progress task, or what error is returned for an invalid task_id. 'Delete' does signal mutation, so it is not misleading — just severely under-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?

One short, front-loaded sentence with zero filler. It is efficiently worded; the problem is omission, not verbosity.

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

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

A destructive, single-parameter tool with no annotations and no output schema needs the description to cover irreversibility, error conditions, and id provenance. None of that is present, so an agent cannot call it confidently in edge cases.

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 single task_id parameter is undocumented in structured data. The description adds no format, source (where to obtain the id), or validity constraints, leaving the agent to guess whether this is the id from create_remesh_task or a different handle.

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

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

The description states a specific verb and resource (delete a remesh task), which separates it cleanly from retrieve_remesh_task, list_remesh_tasks, and create_remesh_task in the sibling set. It stops short of explicitly naming those siblings as the alternatives, so it is clear but not maximally differentiated.

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

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

There is no guidance on when to call this versus siblings, no prerequisites (does the task need to be finished or stopped first?), and no mention of what happens to a running task. The usage context is only inferable 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?

No annotations are provided, so the description carries the full disclosure burden, and it says nothing beyond the verb. It does not state whether deletion is permanent, whether in-progress tasks can be deleted, whether output files are purged, or what happens if the task_id is unknown — all critical for a destructive tool.

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

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

The single sentence is front-loaded and waste-free, but at four words it is undersized for a destructive operation rather than genuinely efficient. Nothing is buried, yet nothing useful is added either.

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 annotations, no output schema, and an undocumented parameter, the description is the only source of behavioral information for a destructive tool and provides none of it. An agent cannot tell whether the call is recoverable or what it 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% and the single required parameter task_id is documented neither in the schema nor in the description. The description does not say where to obtain the id (e.g., from create_retexture_task or list_retexture_tasks) or what format it takes.

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 ('Delete') and resource ('retexture task'), which cleanly separates it from the retrieve_/list_/create_/stream_ retexture siblings in the tool list. It stops short of saying what exactly is removed (task record only vs. generated assets), but the operation itself is unambiguous.

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

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

There is no guidance on when to call this rather than letting a task expire, no prerequisites, and no stated alternatives. The only implied usage is 'you have a task_id and want it gone', which the agent must infer.

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 full burden, and it discloses nothing: not whether deletion is permanent, whether in-flight/streaming tasks can be deleted, whether associated assets are removed, or what permissions are needed. For an irreversible mutation this is a serious 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?

A single short sentence with no filler and no buried information, which is structurally fine. However, the brevity reflects under-specification rather than economy of expression, so it only earns a middling score.

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 zero annotations, no output schema, and undocumented parameters, a destructive tool needs the description to explain consequences and preconditions; none are present. An agent would be guessing about irreversibility and valid task states.

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 there is a single required parameter, task_id, whose meaning and accepted format the description does not explain. The parameter name is largely self-evident, which prevents a 1, but nothing is added.

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 restates the tool name almost verbatim: "Delete a rigging task" for delete_rigging_task. It does identify the resource (rigging task) and the action (delete), so an agent can guess intent, but it adds no scope or distinguishing information against the many sibling delete_* 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?

There is no guidance on when to use this tool versus the other delete variants (delete_animation_task, delete_retexture_task, etc.) or versus leaving a task alone. No prerequisites, no state conditions, no mention of when not to use 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?

No annotations are supplied, so the description carries the full burden for a destructive mutation, yet it discloses nothing about irreversibility, permission requirements, or whether in-progress work is cancelled or the resulting asset is purged. Two words of content for a destructive operation is effectively zero transparency.

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 definition is a single short sentence with no padding or redundancy, so it is not verbose. However, its brevity stems from under-specification rather than efficiency, so it earns only a middling score.

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 annotations, no output schema, an undocumented required parameter, and dozens of sibling delete tools, the description needs to do real work and does none. An agent cannot determine consequences or correct invocation from it.

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 required task_id has 0% schema description coverage and the description says nothing about its format, where it is obtained (presumably create_text_to_3d_task or list_text_to_3d_tasks), or what happens with an invalid or already-deleted id. The one-parameter case falls below the zero-parameter baseline because the parameter is entirely undocumented.

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

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

The sentence 'Delete a text-to-3d task' restates the tool name almost verbatim and adds no scope, target, or distinguishing detail. The verb and resource are identifiable, but only because of the name, not because the description contributes anything.

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 invoke this versus the many sibling delete tools (delete_animation_task, delete_rigging_task, etc.), no prerequisites, and no mention of when deletion is inappropriate, such as while a task is still streaming or running.

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 full burden, yet it omits critical traits for a destructive operation: whether deletion is permanent or reversible, whether it requires ownership or auth, what happens to an in-progress or completed task, and the response on success or failure.

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 single sentence is front-loaded and contains no waste, but its brevity reflects under-specification rather than efficient information density; it fails to earn its place as sufficient documentation.

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 destructive, annotation-free mutation tool with no output schema and an undocumented parameter, the description leaves out irreversibility, error behavior, and parameter meaning, making it inadequate for confident invocation.

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

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

Schema coverage is 0% and the sole parameter task_id has no description in either schema or description, so the tool does not clarify whether it refers to a task ID from a create_* response or a list_* entry. With one required parameter undocumented anywhere, the description does not compensate for the coverage gap.

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

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

The description states a specific verb and resource ('Delete a text-to-image task'), which is marginally more than the tool name alone, but it adds no distinguishing detail about what deleting entails or how it differs from sibling delete tools beyond the resource name already in the tool identifier.

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 use this tool versus the many sibling delete_* tools, no prerequisites, and no mention of when deletion is appropriate or when a retrieve_* call should precede it. Usage is only implied by the verb.

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 full burden. It says 'Delete' but not whether the operation is permanent and irreversible, what happens to an in-flight task, what error is returned for an unknown or already-deleted task_id, or whether the response is empty. For a destructive call with zero annotation coverage this is a meaningful 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?

A single short sentence with the action front-loaded; nothing is padded. The only questionable content is the endpoint path reference, which adds little for an agent choosing a tool and slightly blurs the sibling distinction.

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 irreversible mutation with no annotations, no output schema, and an undocumented parameter, the description should at minimum cover irreversibility and error conditions. It covers none of these, so an agent lacks the information needed to call it safely.

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

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

There is one parameter (task_id) with 0% schema description coverage, so the schema contributes nothing about its expected format or provenance. The description only implies 'a text-to-texture task' is identified, without saying whether task_id is the ID returned by create_text_to_texture_task or some other handle, nor giving any format hint.

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 (Delete) and resource (text-to-texture task), which maps directly to the tool name and separates it from retrieve/list/stream siblings. However, the trailing reference to the '/v1/retexture API' muddies the distinction from the sibling delete_retexture_task and create_retexture_task, leaving some ambiguity about which endpoint family this actually targets.

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 use this versus delete_retexture_task, no note that it should be called only on tasks no longer needed, and no mention of prerequisites such as the task having completed or being in a deletable state. The agent must infer all selection logic from the name alone.

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. The verb 'Retrieve' implies a read-only, non-destructive operation, which is useful, but the description does not mention authentication requirements, rate limits, or what the balance represents (e.g., credits vs. currency). For a simple getter, this is adequate but incomplete.

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

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

The description is a single, front-loaded sentence that communicates the action and target directly. There is no wasted verbiage.

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 the low complexity, empty schema, and no output schema, the description is minimally sufficient. However, it does not explain what the returned balance includes or its format, which would be helpful since no output schema exists to clarify return values.

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 there are no parameter semantics to document. The baseline for zero parameters is 4, and the description appropriately does not introduce unnecessary parameter details.

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 ('Retrieve') and resource ('your Meshy AI account balance'), making the tool's function immediately clear. It is readily distinguishable from all sibling tools, which are task creation, retrieval, listing, streaming, or deletion operations.

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 the user wants to check their account balance—but it does not explicitly state when to use it versus alternatives or provide any exclusions. Since no sibling tool serves the same purpose, the implied usage is adequate but not fully elaborated.

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 full burden and does not meet it: it says nothing about default ordering, result limits, whether all historical tasks are returned or only recent ones, or auth requirements. The one useful disclosure is the per-user scoping ('you have previously created'), but the rest of the behavior is opaque.

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, and the core purpose is front-loaded. The second sentence is somewhat redundant with the enum but is harmless.

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 paginated list tool with no output schema, no annotations, and zero parameter documentation, the description should explain what a result looks like and how paging behaves; it does neither. An agent knows roughly what the tool is for but not how to call it well or what it will get back.

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 three parameters, and the description only restates the sort_by enum values that the schema already defines, adding no meaning. page_num and page_size — the parameters most in need of explanation, such as defaults and maximums — are entirely undocumented.

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

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

States a specific verb (list) and resource (animation tasks) and scopes it to tasks the caller previously created. It is distinguishable from retrieve_animation_task by the verb, though the description never names 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?

Offers no guidance on when to use this list versus retrieve_animation_task or the stream variants, and no advice on pagination strategy or how many results to expect. The only hint at usage is the phrase 'previously created', which quietly implies a per-user scope.

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 full disclosure burden and largely drops it. It says nothing about pagination behavior, default sort order, result caps, or what fields each task record contains. Only the sort_by value syntax is surfaced.

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, and the core action is front-loaded. The second sentence is slightly redundant with the schema enum but is cheap and reinforces usage.

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 paginated list tool with no output schema and no annotations, the description should explain paging conventions and result shape. Neither is covered, leaving the agent to guess how to retrieve subsequent pages.

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 3 parameters. The description restates the sort_by enum values already present in the schema (adding no new meaning) and leaves page_num and page_size entirely undefined — no defaults, no maximums, no base index.

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 ('image-to-3d tasks'), which cleanly separates it from the retrieve_*, create_*, and stream_* siblings. It stops short of explicitly naming the retrieve_image_to_3d_task or list_* alternatives, but the resource scoping is unambiguous.

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

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

No indication of when to use this list versus retrieve_image_to_3d_task for a single task, nor any mention of ordering defaults or how to page through results. The agent must infer usage purely from the verb 'List'.

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 full burden of behavioral disclosure. It implies a read-only enumeration of existing tasks and mentions sort options, but omits pagination defaults, ordering defaults, permissions, and the side-effect profile. That leaves significant gaps for a tool with zero annotation coverage.

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 purpose. The second sentence is slightly redundant with the schema enum but remains compact and useful.

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 three-parameter paginated list tool with no output schema and no annotations, the description omits the pagination contract and what each listed task contains. It is callable but underspecified.

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 define all three parameters. It covers only sort_by and merely repeats the enum already present in the schema, leaving page_num and page_size entirely unexplained with no defaults, limits, or semantics.

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') and resource ('image-to-image tasks') scoped to previously created items, which clearly separates it from create/retrieve siblings by name and intent. It does not explicitly name alternatives or contrast with them, 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?

There is no explicit when-to-use guidance, no distinction from retrieve_image_to_image_task or the other list_* siblings, and no note about when to paginate. Enumeration is only implied by 'List previously created'.

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 full behavioral burden. 'Previously created' hints at read-only persistence, but it never states that listing is non-destructive, how pagination behaves, what defaults apply, or what a result entry contains.

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 tool's purpose, with the sort detail following. Every sentence carries information, though the sort sentence largely duplicates the enum in the schema.

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

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

With no annotations, no output schema, and 0% parameter documentation, the description leaves too much unspecified for a paginated listing tool — result shape, default page size, and total-count semantics are all absent.

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 all three parameters. It only addresses sort_by, and even that mostly restates the enum ('+created_at'/'-created_at'); page_num and page_size receive no mention, so default page size and paging limits remain unknown.

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

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

States a specific verb and resource ('List ... multi-image-to-3d tasks') with the scope qualifier 'previously created'. The list/retrieve/create/stream/delete family is distinguishable by the verb alone, so an agent can route correctly, though the description 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 verb 'List' implies a collection-browsing use case, and the tool filling a role between retrieve_multi_image_to_3d_task and delete_multi_image_to_3d_task is inferable. There is no explicit when/when-not guidance or stated prerequisite (e.g., that the user must already have created tasks).

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 full disclosure burden, yet it says nothing about pagination defaults, maximum page size, result ordering when sort_by is omitted, or permission/auth requirements. The only behavioral detail is the sort_by value set, which is already in the schema enum.

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, and the core purpose is front-loaded. It is under-specified rather than padded, so brevity is not the problem.

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?

A three-parameter list tool with no annotations and no output schema needs the description to cover pagination semantics and return shape, neither of which is addressed. An agent cannot confidently choose paging values or interpret 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 description coverage is 0% and the description only restates the sort_by enum values without explaining that '+'/'-' mean ascending/descending. page_num and page_size are entirely undocumented in 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 clear verb+resource ("List previously created remesh tasks"). The list_* vs retrieve_*/create_* naming pattern among siblings makes the scope obvious, though the description never explicitly distinguishes itself from retrieve_remesh_task.

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 says what the tool does but never when to use it instead of retrieve_remesh_task or how paging should be driven. No exclusions, no prerequisites, no hint about how listing relates to the stream/retrieve siblings.

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 full burden. It reveals that tasks pre-exist and can be sorted, but says nothing about pagination behavior, default sort order, result limits, or what happens when no tasks exist.

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 brief sentences, no filler, with the core purpose front-loaded. Slightly thin rather than padded, but nothing is wasted.

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

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

For a paginated list tool with no output schema, no annotations, and zero schema descriptions, the description should cover pagination defaults and rough return shape. It supplies almost none of that, leaving the agent guessing about the two pagination parameters.

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

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

With 0% schema description coverage and no annotations, the description must explain all three parameters. It only mentions sort_by, and even then merely repeats the enum values without explaining that '+' vs '-' means ascending/descending; page_num and page_size are entirely undocumented.

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

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

States a specific verb and resource: 'List previously created retexture tasks'. It is clearly a collection-listing operation, distinguishable from retrieve_retexture_task and create_retexture_task by the verb, 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?

There is no when-to-use, when-not-to-use, or alternative-tool guidance. The phrase 'previously created' vaguely implies it is for browsing existing tasks, but the agent must infer that on its own.

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 at all, the description carries the full disclosure burden. It says nothing about pagination defaults, maximum page size, what happens when page_num is omitted, whether results are capped, or what the response looks like — all critical for a list tool. The only behavioral hint is the accepted sort values.

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 core purpose and wasting no words. The sort_by sentence is arguably redundant with the enum but is at least placement-appropriate rather than verbose.

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

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

No output schema and no annotations, so the description must explain both the result shape and pagination behavior. It explains neither, and two of three parameters are semantically empty. An agent could call it, but would not know what to expect back or how to iterate pages.

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 only restates the enum values for sort_by (already visible in the schema) and leaves page_num and page_size completely undefined — no defaults, no ranges, no page-size cap. Two of three parameters are undocumented in both places.

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

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

States a specific verb and resource ("List previously created rigging tasks"), which is clearly distinguishable from retrieve_rigging_task and the create/stream siblings in the family. It stops short of naming an alternative explicitly, but the list-vs-retrieve distinction is unambiguous from the name and description.

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: "List previously created" suggests enumeration rather than fetching a single task, and the presence of retrieve_rigging_task makes the split inferable. There is no explicit statement of when to use this versus retrieve_rigging_task, and no mention of whether it returns all tasks or a page.

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 full burden. 'List previously created' lightly implies a read-only, non-destructive operation, but nothing is said about pagination behavior (defaults, max page_size, whether page_num is 1-based), result ordering defaults, or whether the list is scoped to the caller's workspace.

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 primary purpose front-loaded and no filler. The second sentence is slightly redundant with the schema enum, but it is cheap and draws attention to the only documented parameter.

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 paginated list tool with three parameters, no annotations, and no output schema, the description is thin: it never explains what a page of results looks like, how to page through them, or what the default ordering is. An agent could call it, but not confidently or efficiently.

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 only sort_by is addressed, and even then the description merely restates the two enum values already present in the schema. page_num and page_size — the parameters most likely to be misused — get no meaning, defaults, or constraints in either the schema or the description.

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

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

The description names a specific verb+resource (list text-to-3d tasks) and scopes it to previously created tasks, which an agent can separate from the many retrieve_/create_/stream_ siblings by naming convention alone. It stops short of explicitly contrasting itself with retrieve_text_to_3d_task or list_image_to_3d_tasks, so it is clear but not fully differentiated.

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

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

There is no guidance on when to call this versus retrieve_text_to_3d_task (single task) or any other list_* sibling, and no mention of how pagination should be used. Usage is only implied by the verb 'List'.

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 full burden, yet it discloses nothing about pagination behavior, default ordering, result limits, or whether all tasks or only the caller's tasks are returned. The only behavioral hint is the sort_by ordering values, which the enum already conveys.

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 core action, with no filler. It is efficient, though the second sentence restates information already encoded in the sort_by enum and could have been spent on the undocumented paging parameters.

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 annotations, no output schema, and no parameter descriptions, the description is the only source of truth and it covers only the ordering argument. An agent still cannot tell how results are paged, what the response shape is, or how this differs from sibling list_* tools.

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 three parameters. The description explains sort_by values (restating the enum) but says nothing about page_num or page_size — no defaults, no max page size, no zero- vs one-based indexing — leaving half the surface undocumented anywhere.

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

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

The description gives a specific verb and resource ("List ... text-to-image tasks") and narrows scope with "previously created". It does not explicitly distinguish itself from siblings such as retrieve_text_to_image_task or list_image_to_image_tasks, but the list/retrieve distinction is at least implicit in the wording.

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 statement of when to use this tool versus retrieve_text_to_image_task (single task lookup) or stream_text_to_image_task. No prerequisites, no mention of what happens with no page arguments, and no exclusions are given.

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

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

No annotations are provided, so the description carries the full burden. It never states the default sort order, default page size, maximum page size, whether results are scoped to the caller's account, or how an empty result is represented — all material for a paginated read tool.

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

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

Two short sentences, front-loaded with the action and resource. The second sentence partly duplicates the schema enum, which keeps it from being maximally efficient, but 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?

With no output schema and no annotations, the description is the only source of behavior, yet it omits pagination semantics, result shape, and ordering defaults. For a paginated list tool in a crowded sibling family, this leaves the agent guessing on essentials.

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 3 parameters. The description spells out sort_by values, which largely repeats the enum in the schema, while page_num and page_size receive no defaults, ranges, or size limits at all.

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

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

States a specific verb and resource ('List previously created text-to-texture tasks'), which is unambiguous on its own. However, it adds 'via the /v1/retexture API', an implementation detail that collides conceptually with the sibling list_retexture_tasks and provides no differentiation between the two.

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 statement of when to use this list tool rather than retrieve_text_to_texture_task, stream_text_to_texture_task, or the near-identical list_retexture_tasks. Usage is only implied by the verb 'List', leaving the agent to infer the routing in a family of ~50 siblings.

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 and no output schema, so the description carries the full burden. Beyond hinting that the response may be either a status or a final result, it says nothing about what happens with an unknown or expired task_id, whether the call blocks until completion, or whether results expire after retrieval.

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 efficient sentence with no padding, front-loaded with the verb and resource. It is concise but arguably too thin rather than wasteful.

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 annotations, no output schema, and an undocumented parameter, the description should explain the task_id source and the shape of the status/result response. Neither is covered, leaving the agent guessing about the return contract.

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

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

There is one required parameter, task_id, with 0% schema description coverage, and the description never mentions it. It does not say the ID comes from create_animation_task or what form it takes, so the description fails to compensate for the schema 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 (retrieve) and resource (animation task) plus what is returned (status or result). However, it does not distinguish this from the sibling stream_animation_task or list_animation_tasks, which an agent must disambiguate on its own.

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

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

Usage is only implied — an agent infers this is the polling call after create_animation_task. There is no explicit statement of when to use this versus stream_animation_task (which likely pushes progress) or list_animation_tasks, and no prerequisites or exclusions.

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

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

With no annotations, the description carries the behavioral burden. It conveys that this is a read/retrieval operation returning both status and result, which is useful. But it omits failure behavior (e.g., invalid task_id), whether polling is expected, and what status values or result shapes look like.

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 wasted words. It is appropriately sized for a simple retrieval tool, though it could be slightly more structured by mentioning polling context.

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 one-parameter retrieval tool, the description covers the core purpose. But with no output schema and no annotations, it should say more about return values and failure modes to be fully complete for an agent polling task 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% and the only parameter, task_id, is undocumented in both schema and description. The description does not explain where the task_id comes from or its expected format, so it fails to compensate for the coverage gap.

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

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

The description states a specific verb ('Retrieve') and resource ('image-to-3d task'), and clarifies that it returns status and result. This differentiates it from create/list/stream siblings, though it does not explicitly name those alternatives.

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

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

Usage is implied: it is the polling/status companion to create_image_to_3d_task. However, there is no explicit guidance on when to use this versus stream_image_to_3d_task or list_image_to_3d_tasks, and no prerequisites or exclusions 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 of behavioral disclosure. It implies a read ('Retrieve') but says nothing about what happens for an unknown task_id, whether status is terminal, or what the result contains.

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 wasted words. Efficient, though its brevity is partly the source of the coverage gaps.

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, so the description should describe the return shape (status values, result image reference) and error behavior. It does neither, leaving an agent unable to know what it will get back.

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 task_id has no description in the schema. The description adds no information about its format or provenance (e.g., as returned by create_image_to_image_task), leaving the gap unaddressed.

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

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

States a specific verb ('Retrieve') and resource ('status and result of an image-to-image task'), which is clearly distinguishable from the create_/list_/delete_/stream_image_to_image_task siblings. It does not explicitly contrast with the streaming or list variants, so it stops 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?

No guidance on when to use this instead of stream_image_to_image_task or list_image_to_image_tasks, and no mention of polling cadence or prerequisite that a task must already exist. The agent must infer usage purely 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?

No annotations exist, so the description carries the full disclosure burden, and it only says it returns status and result. It does not describe possible task states, what 'result' contains, whether the call blocks, what happens for an unknown/expired task_id, or any auth/rate-limit behavior.

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

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

A single tight sentence with the resource and returned data front-loaded. Nothing is wasted, though there is also very little content.

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 one-parameter status getter with no output schema, the description is minimally adequate, but it omits return shape and state semantics that an agent needs to act on 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?

One required parameter at 0% schema description coverage, and the description adds no meaning beyond implying task_id identifies a multi-image-to-3d task. It does not say where the id comes from (create response) or its format.

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 'Retrieve' plus resource 'multi-image-to-3d task' plus scope 'status and result'. The family naming convention (create_/list_/stream_/delete_multi_image_to_3d_task) makes it distinguishable from siblings, though the description never names an alternative explicitly.

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

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

Usage is implied rather than stated: an agent infers you call this after create_multi_image_to_3d_task to poll status. There is no explicit guidance on when to prefer stream_multi_image_to_3d_task over polling, nor on retry/backoff expectations.

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 full behavioral burden. It does not explain whether the call is read-only, how task states or results are reported, what happens if task_id is invalid, or whether polling is expected.

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

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for the task, though the terseness contributes to the missing behavioral and parameter details.

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 annotations, no output schema, an undocumented parameter, and many sibling task tools, the description is too thin. It should clarify polling behavior, expected task states, and when the result becomes available.

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 has 0% schema description coverage, and the description adds no detail about its format, source, or constraints. It only implies the ID belongs to a remesh task, which is already obvious from the tool name.

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

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

The description states a specific verb and resource: retrieve the status and result of a remesh task. It clearly distinguishes itself from create/list/stream/delete by naming the retrieval action, but it does not explicitly contrast with siblings like list_remesh_tasks or retrieve_*_task for other task types.

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 explicit guidance on when to use this tool versus alternatives such as list_remesh_tasks or stream_remesh_task. The implied usage (polling a previously created remesh task) is inferable from the description but not 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?

No annotations are provided, so the description carries the full behavioral burden. It does not say whether the call blocks until completion, what happens for an unknown or expired task_id, whether the result field is null while pending, or whether the operation is free of side effects — all material for a task-status endpoint.

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

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

One front-loaded sentence with no filler, which is good structure, but the brevity reflects under-specification rather than economy — nothing about state, errors, or return shape is included.

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 is the only source of truth, and it omits the lifecycle contract an agent needs: pending/in-progress/failed statuses, what 'result' contains, and whether repeated polling is expected. It gestures at the return concept but is not complete enough to call correctly in a multi-step pipeline.

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 parameter task_id, and the description never mentions it. It is left implicit that the ID comes from create_retexture_task, and no format expectations (UUID vs. opaque string) are given, so the description fails to compensate for the schema 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 ('Retrieve') and resource ('retexture task'), plus what is returned ('status and result'). It does not distinguish itself from siblings like list_retexture_tasks or stream_retexture_task, so an agent must infer the single-task vs. multi-task vs. streaming split from the name alone.

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 use this versus stream_retexture_task (live updates) or list_retexture_tasks (enumeration), nor any mention of polling cadence or whether the call blocks. The agent must guess the intended workflow from the sibling names.

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 are absent, so the description carries the full burden, yet it discloses only that a status is returned. It does not say whether the call is read-only and side-effect free (implied only by "retrieve"), what happens for an unknown or expired task_id, or what the possible status values are.

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

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

A single short sentence with no waste, but its brevity is under-specification rather than efficient packing — the one sentence is the entire definition. Front-loaded and parseable, so not a 2.

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 annotations and no output schema, the description should explain the return value (e.g., status field and terminal states). It does not, leaving the agent unable to interpret a result or know how to poll, which is inadequate for a task-status 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 coverage is 0% and the sole parameter task_id has no type context, format, or provenance in the description. It does not tell the agent where the task_id comes from (the create_rigging_task response) or how it is validated.

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 ("Retrieve the status of a rigging task"), which is clearly distinct from create_rigging_task, list_rigging_tasks and stream_rigging_task by the name pattern. It does not explicitly name those siblings or explain the retrieve-vs-list/stream distinction, 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?

No guidance on when to use this versus list_rigging_tasks or stream_rigging_task, and no mention of polling, wait/retry behavior, or prerequisites such as needing a task_id from create_rigging_task. The agent must infer the entire usage context 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?

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing beyond the bare action. It does not say whether the call is read-only and side-effect free, what status values are possible (pending/running/failed/succeeded), whether the result field is null while incomplete, or whether failures surface as errors or in the payload.

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 short sentence, front-loaded with the action and resource, with no filler. It is efficient but borders on under-specified rather than optimally concise.

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

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

This is an async task-polling tool with no output schema, no annotations, and an undocumented parameter, so the description is the only source of information about return shape and lifecycle. It never describes what 'status' looks like, how to detect completion, or what 'result' contains, which is exactly what an agent needs to drive a poll-until-done loop.

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

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

With a single parameter and 0% schema description coverage, the description must compensate, and it does not. The parameter name task_id is self-explanatory, but the description never says where the ID originates (presumably the create call's response) or what format it takes.

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 (retrieve) and resource (text-to-3d task), including that it returns both status and result. The naming convention makes it distinguishable from its create_/list_/stream_/delete_ siblings, though the text itself does not call out the distinction.

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 call this versus list_text_to_3d_tasks or stream_text_to_3d_task, nor any mention of polling cadence, retry behavior, or prerequisites. An agent must infer that this is the polling call for a task created via create_text_to_3d_task.

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 full behavioral burden. 'Retrieve' implies a read-only, non-destructive operation, and mentioning status and result gives some output context, but permissions, error behavior, polling semantics, and task state details are omitted.

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

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

The description is a single efficient sentence with the key operation and resource front-loaded. There is no redundant or wasted text.

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 one-parameter retrieval tool, the description gives the minimum needed to understand the operation. Since there is no output schema, it should say more about the returned status/result structure and task lifecycle context to be fully 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?

The schema has 0% description coverage and the description adds no information about the task_id parameter beyond naming the task type. It does not explain where to obtain the task_id, its format, or what happens if it is invalid.

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-resource pair: retrieve the status and result of a text-to-image task. This clearly separates it from create, list, stream, and delete siblings, as well as sibling task types, though it does not explicitly name alternatives.

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

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

The wording implies the tool is used after a task has been created, when an agent has a task_id and needs its status or result. However, it does not explicitly say when to use this instead of list_text_to_image_tasks or stream_text_to_image_task.

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 behavioral burden, yet it never states that this is a read-only call, what happens while the task is still running, whether result is null until completion, or whether errors surface as HTTP failures. It only repeats the operational semantics implied by 'retrieve'.

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 core action front-loaded and no filler. The trailing API-path sentence adds little and mildly muddies the identity of the tool, but overall it is tight.

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 polling endpoint with one required parameter, no output schema, and no annotations, the description should explain response shape (status/result fields) and completion states. It says only 'status and result', leaving the agent unable to know what to expect or how to interpret an incomplete task.

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 has 0% schema description coverage and the description says nothing about it—no format, origin, or lifetime. An agent must guess that it is the identifier returned by the create endpoint.

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 (retrieve) and resource (text-to-texture task) with scope covering status and result, which an agent can grasp immediately. It does not, however, differentiate itself from the very similar sibling retrieve_retexture_task, and the '/v1/retexture API' note blurs rather than sharpens that distinction.

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 call this versus retrieve_retexture_task, retrieve_text_to_3d_task, or the stream/list variants, and no mention that the task_id must come from create_text_to_texture_task. Usage is only inferable from the verb.

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. Naming SSE is genuinely useful, but it says nothing about what events arrive, whether the stream ends when the task completes, what the timeout parameter does, or whether an error mid-stream is surfaced in-band.

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 tight sentence with the mechanism front-loaded and no filler. It is efficient, though the brevity comes at the cost of the behavioral detail noted elsewhere.

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 long-lived streaming tool with no output schema, no annotations, and zero parameter documentation, the description should explain the event lifecycle and termination conditions. An agent cannot tell how to consume or when to stop reading the stream from this definition alone.

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 two parameters, so the description must compensate and does not. task_id is inferable from the resource name, but timeout — likely seconds, with undefined behavior on expiry — is entirely unexplained in 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 (stream) and resource (animation task) plus the transport mechanism (server-sent events), which clearly separates it from retrieve_animation_task and list_animation_tasks. It does not explicitly name those siblings as the non-streaming alternatives, so it stops 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?

There is no statement of when to stream versus when to poll with retrieve_animation_task, nor any prerequisite such as the task needing to exist or be in progress. The streaming-vs-retrieval choice is left entirely 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 behavioral burden. 'Stream updates' hints at an incremental/streaming response, but nothing is said about whether the call blocks until task completion, how updates are delivered or terminated, what happens on error, or how the timeout parameter behaves.

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?

It is a single front-loaded sentence with no waste, but that brevity comes at the cost of missing semantics rather than from trimming redundancy. Efficiently worded yet under-specified.

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?

A streaming tool with no annotations, no output schema, and 0% parameter coverage needs the description to explain the update stream and the timeout, and it does neither. An agent cannot predict the response shape or termination behavior from this definition.

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 both parameters (task_id, timeout) are undocumented anywhere. The description says nothing about which task identifier is expected or what the timeout controls, leaving one parameter entirely opaque.

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 ('Stream updates') and resource ('image-to-3d task'), which cleanly separates it from create/retrieve/list siblings in the image-to-3d family. It does not explicitly contrast itself with retrieve_image_to_3d_task, so the agent must infer the difference between streaming and one-shot retrieval.

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 statement of when to use this versus retrieve_image_to_3d_task or list_image_to_3d_tasks, no prerequisites, and no indication of when streaming is preferred. The only guidance is the implied 'stream' semantics of 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?

No annotations are provided, so the description carries the full behavioral burden and it says almost nothing: it does not describe the streaming mechanism, whether the stream terminates when the task completes, what happens on timeout, or whether the call is blocking or long-lived. "Stream" implies incremental delivery but nothing about error behavior or termination is 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?

A single front-loaded sentence with no filler, which is structurally clean. But for a streaming tool with a timeout parameter, one sentence is undersized rather than concise — the terseness costs the agent information rather than saving it.

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 annotations, no output schema, and 0% parameter coverage, the description needed to explain streaming semantics, termination, and timeout behavior. It supplies none of these, so an agent cannot call it correctly without guessing.

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 does not. task_id is self-explanatory, but timeout — its unit, default, and whether it bounds the whole stream or just the initial connection — is completely undocumented.

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

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

States a specific verb and resource ("Stream updates for an image-to-image task"), so an agent knows it is the streaming counterpart for image-to-image tasks. However, it does not distinguish itself from the closely related siblings retrieve_image_to_image_task and list_image_to_image_tasks, leaving the stream-vs-retrieve-vs-list choice to be inferred from the name alone.

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 use streaming versus retrieve_image_to_image_task, nor whether the task must be created first or already be running. The agent must infer the workflow entirely from the sibling names.

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 full behavioral burden, and it discloses nothing: not whether the call blocks, how the stream terminates, what happens on task failure, or what the timeout parameter governs. It restates the name and stops.

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

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

A single short sentence, front-loaded and free of padding. It is under-specified rather than verbose, so the brevity earns little credit.

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?

A streaming tool with no output schema, no annotations, and no parameter documentation needs the description to explain the stream's shape, termination, and error behavior. None of that is present, so an agent cannot call this reliably.

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

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

Schema description coverage is 0% and both parameters (task_id, timeout) are undocumented in the schema. The description adds no meaning to either — not even the timeout unit or whether it caps stream duration.

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 verb ("Stream updates") and a resource ("multi-image-to-3d task"), and the word "stream" does distinguish it from the sibling retrieve_multi_image_to_3d_task. However, it never explains what a "stream" is here (SSE, incremental polling, long-lived connection), leaving the core action vague.

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 stream versus calling retrieve_multi_image_to_3d_task, no preconditions, and no mention of what the caller should do with the updates. The sibling set makes an alternative obvious, yet the description never references 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 and no output schema, the description carries the full disclosure burden, yet only 'Stream updates' is offered. It does not say what an update contains (status, progress, result), whether the stream terminates on completion, or whether the call blocks, which are critical for a streaming tool.

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

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

A single front-loaded sentence with no waste, but it is under-specified rather than concise. The brevity costs more than it saves given the missing behavioral and parameter context.

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 streaming tool with no annotations, no output schema, and zero parameter documentation, the description leaves out everything an agent needs beyond the bare action: stream lifecycle, update payload shape, and timeout 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 description coverage is 0%, so the description must compensate and it does not. task_id is self-evident from its name, but timeout is completely unexplained — no units, no default, no statement of what happens when it elapses.

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: 'Stream updates for a remesh task.' An agent can tell it is the streaming variant of the remesh family, but the description never contrasts it with retrieve_remesh_task or list_remesh_tasks, so sibling differentiation is left to the naming convention.

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 stream rather than poll with retrieve_remesh_task or list_remesh_tasks, nor any precondition such as the task needing to already exist. The agent must infer the choice entirely from the tool 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 are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the verb: no indication of transport, whether the call blocks, whether it terminates at task completion, what the timeout parameter governs, or what happens on an unknown/expired task_id. One partial credit for at least establishing that output is incremental updates.

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, so it is not bloated. But the economy comes at the cost of substance rather than from efficiency — nothing unnecessary, yet not enough necessary content.

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 streaming endpoint with no annotations, no output schema, and zero parameter documentation, the description should cover at minimum termination semantics and what a consumer receives. None of that is present, so an agent cannot confidently invoke or interpret the call from this definition alone.

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

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

Schema coverage is 0% — neither task_id nor timeout is documented in the schema, and the description mentions neither. "For a retexture task" loosely implies task_id's meaning, but the timeout parameter (units, default, whether it bounds the whole stream or each poll) is completely unspecified in both description and 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?

States a specific verb ("stream") and resource ("retexture task"), which is more than a tautology. However it never distinguishes streaming from the sibling retrieve_retexture_task, nor explains what a "stream" returns (SSE, long-poll, incremental diffs), so an agent must infer the retrieval-vs-stream split from naming alone.

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

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

No statement of when to use this instead of retrieve_retexture_task or list_retexture_tasks, and no guidance on whether streaming is appropriate for one-shot status checks. The only hint is the word "stream" in the name/description.

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 full behavioral burden. 'Until it completes' hints at a long-lived blocking call, but nothing is said about how updates are delivered, whether the call blocks the agent, what happens on timeout, or behavior if the task already finished or failed.

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

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

A single short sentence with no filler, so nothing is wasted, but the terseness comes at the cost of necessary specification rather than being efficient completeness.

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 annotations, no output schema, and zero schema description coverage on two parameters, the description is far too thin for a streaming/blocking tool. An agent cannot tell what it will receive, how long it will wait, or how timeout affects the call.

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

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

Schema description coverage is 0% and neither parameter is mentioned in the description. The 'timeout' parameter is completely undocumented, and 'until it completes' arguably conflicts with the existence of a timeout knob, leaving the agent to infer its semantics.

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 ('stream updates for a rigging task'), which is clearly distinguishable from retrieve_rigging_task and list_rigging_tasks by the streaming verb. It never explicitly contrasts itself with those siblings, 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?

No guidance on when to stream versus calling retrieve_rigging_task repeatedly, nor any prerequisites such as the task needing to exist or be in progress. The only contextual hint is the trailing 'until it completes', which is incidental rather than a usage rule.

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 full burden, and it only discloses that the call streams until completion. It says nothing about what happens on failure, whether the stream can hang, how the timeout parameter terminates it, or what the update payloads look like - all critical for a long-running streaming operation.

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; nothing is wasted. Brevity is the issue in other dimensions, not verbosity here.

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 streaming tool with no annotations, no output schema, and no parameter documentation, the description is too thin. An agent cannot tell what updates it receives, how errors surface, or how timeout interacts with completion.

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 does not: 'task_id' is only obliquely referenced as 'a text-to-3d task', and the optional 'timeout' parameter is never mentioned at all despite directly controlling how long this stream blocks.

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 plus resource ('Stream updates for a text-to-3d task') and adds scope ('until it completes'). It is distinguishable from retrieve_text_to_3d_task and list_text_to_3d_tasks in practice, but the description never names the alternative, leaving the stream-vs-poll distinction implicit.

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 'until it completes' implies this is the blocking wait-for-finish option, which gives some usage context. However, it never says when to prefer retrieve_text_to_3d_task over streaming, nor whether it is required before retrieving results.

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 full behavioral burden, yet it says nothing about streaming semantics: how long the stream runs, what terminators exist, whether it blocks, or what happens on timeout/an invalid task_id. 'Stream updates' is the only behavioral signal offered.

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

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

A single short sentence with no wasted words, but the brevity reflects under-specification rather than efficiency; nothing is front-loaded beyond the bare purpose.

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 streaming tool with no annotations, no output schema, and undocumented parameters, the definition leaves critical gaps: stream lifetime, update payload shape, and timeout behavior are all unaddressed.

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 both parameters. The description never mentions 'timeout' at all, and task_id is only obliquely implied by 'for a text-to-image task' — no format, validity, or effect is described.

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 ('Stream') and a specific resource ('text-to-image task'), which separates it from the create/retrieve/list/delete text-to-image siblings. It does not, however, explain how 'stream updates' differs from retrieve_text_to_image_task or what an 'update' consists of.

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 choose streaming over retrieve_text_to_image_task, no mention of prerequisites (e.g., a task must already exist and be in progress), and no exclusions. The agent must infer the whole usage decision from the tool 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 are provided, so the description carries the full behavioral burden, and it discloses nothing about what 'stream' means here — whether it blocks until completion, emits incremental events, how it terminates, or what happens on timeout. For a streaming endpoint with zero annotation coverage this is a serious 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?

A single tight sentence with the action and resource front-loaded, no filler. It is concise, though the trailing API-path clause adds a little confusion rather than value.

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 annotations, no output schema, and no parameter documentation, the description is the only source of truth and it leaves streaming semantics, return shape, and the timeout parameter unexplained. An agent cannot reliably call this correctly from what is given.

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 two parameters, and the description names neither task_id nor timeout. The timeout unit and whether it bounds the whole stream or per-event wait are entirely undocumented, which is exactly the kind of ambiguity that causes misinvocation.

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

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

Names a specific verb (stream updates) and a specific resource (text-to-texture task), which tells the agent this is a live/progressive read rather than a one-shot fetch. However, it offers no differentiation from the sibling retrieve_text_to_texture_task or the similarly named stream_retexture_task, and the mention of the '/v1/retexture' API nudges toward the wrong sibling family.

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 statement of when to use streaming rather than polling via retrieve_text_to_texture_task, and no mention of preconditions such as a task already existing and being in progress. The agent has to infer the choice entirely from the tool name.

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