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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the safety profile is covered. Beyond that, the description adds meaningful context: the operation is FREE, it produces an async task (task_type 'print-analyze') whose status field drives next steps, and the analyze task itself carries no model, so a healthy result means downloading the source task's model. It does not explain polling/async completion timing, which keeps this from a 5.

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

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

Front-loaded with the core purpose, followed by the conditional routing as scannable bullets and a compact example call. Every sentence earns its place: the FREE note, the status semantics, and the download caveat all change agent behavior.

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?

Despite having no output schema and zero required parameters, the description explains the report field the agent must act on (printability.status), its three values and the branch each implies, and where the model comes from after a healthy result. An agent has everything needed to invoke the tool and interpret its outcome.

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 100%, including enum semantics for printer_type (1.0/0.8/2.0 mm minimum walls) and the size defaults, so the schema does the heavy lifting. The description only restates that thin-wall analysis is added when printer_type and/or a size is supplied, plus a single example object. That is a marginal gain over the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Check whether a model is printable') and enumerates exactly what is analyzed: watertightness, non-manifold edges, holes, degenerate faces, volume, and conditional thin-wall checks. It explicitly positions itself as 'the authoritative answer to "is it printable?"', which distinguishes it from the sibling meshy_repair_printability and from the generation 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?

Gives explicit when-to-use routing keyed on the reported status: error routes to meshy_repair_printability (with the instruction to pass this analyze task as input_task_id), warning means repair is optional, healthy means download the analyzed source task's model. It names the alternative tool and the exact condition that selects 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?

Annotations already cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description adds genuinely useful context the annotations don't: the 3-credits-per-action cost and the fact that file URLs come from a separate download tool, implying a task-based async flow. It stops short of stating task/polling behavior explicitly.

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

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

Three short, front-loaded blocks: core action and cost first, the mode constraint second, then the sibling workflow note and a compact example. No sentence is redundant.

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 an output schema present and 100% schema description coverage, the description needn't explain return values, and it does supply the key non-schema facts (cost, mutual exclusion, download path). It could be slightly more explicit that the call creates an asynchronous task, but coverage is otherwise complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value beyond the schema by declaring the mutual exclusion of the three animating inputs and explaining why action_ids bundles clips into one file. The example object reinforces the intended call shape.

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: 'Animate a rigged character (rig_task_id)'. It distinguishes itself from siblings by referencing meshy_rig (which produces the rig) and meshy_download_model (which retrieves files), so an agent can tell what this tool is responsible for without opening the schema.

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

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

Gives an explicit either/or constraint ('exactly ONE of action_id, action_ids or motion_task_id') that selects the correct mode, and it clarifies the workflow boundary with meshy_rig (walking/running are already free) and how to retrieve results via meshy_download_model.

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?

Adds substantial context beyond the annotations: cost (10 credits), the fact that texture is not preserved, and the architectural constraint that cuts follow mode/prompt rather than printer geometry. Annotations cover the write/openWorld profile, but the description carries the cost and output-fidelity disclosures the annotations cannot express.

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-loads purpose and motivation in the first sentence, then prerequisite workflow, then a concrete example object. Every line earns its place; no filler or restatement of the title.

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

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

For a 10-parameter mutation tool, it covers cost, side effects, prerequisites, downstream steps, and a call example, while an output schema already handles return values. An agent has everything needed to invoke it correctly in the right sequence.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds real value by explicitly noting the absence of a bed-size parameter and how mode/prompt jointly determine the cuts, reinforced by a full worked example. It stops short of explaining every connector/layout nuance, which the schema already handles.

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

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

States a specific verb+resource ('cut a model into separately printable parts') and lists the three concrete conditions that motivate it (too big for bed, differing colors/materials, assembly). It is clearly distinguishable from sibling operations like meshy_resize, meshy_remesh, and meshy_convert without opening any schema.

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

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

Gives explicit when-to-use triggers, plus a before/after workflow: resize first with meshy_resize because there is no bed-size parameter, check part sizes and re-split by_parts, then meshy_download_model and meshy_send_to_slicer. Alternatives and ordering constraints are named directly rather than left to inference.

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

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

Annotations declare destructiveHint=true and non-idempotency; the description goes well beyond that by disclosing refund outcomes per state, that deletion removes files permanently, that terminal Creative Lab tasks cannot be canceled or deleted even with confirm_delete, and the exact response shape. This is exactly the extra context annotations cannot carry.

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-loads the two-sentence summary, then uses a compact per-type state table. Every line carries a distinct behavioral fact; nothing is redundant with the schema or annotations.

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

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

With no output schema, the description still documents the return object, and it covers the full state machine, refund rules, and confirmation requirement for a destructive 3-parameter tool. An agent has everything needed to call it safely and correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that task_type is optional because the server resolves the real type, and it maps confirm_delete to the specific states where it is required and where it is useless. That is genuine semantic value beyond the enum list.

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 pair and resource ('Cancel a queued task, or delete a finished one') and immediately distinguishes the two modes. It is clearly separable from siblings like meshy_get_task_status and meshy_list_tasks, which do not mutate task state.

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 an explicit when-to-use matrix keyed on task_type and status, including when the operation is refused (IN_PROGRESS non-Creative-Lab tasks) and what to do instead ('Wait until it finishes'). It also states the precondition that confirm_delete requires prior user agreement.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds two useful traits not in structured data: calling it consumes no credits ('Free'), and for team members the returned balance is the shared team pool rather than a personal one.

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

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

Three short sentences, zero waste, with the core action stated first and the qualifiers after. Every sentence earns its place.

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

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

An output schema exists, so return values need not be explained, and the single parameter is fully documented in the schema. What remains missing is only a routing note against the usage-listing sibling, making this near-complete for a simple read 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?

Only one parameter exists and schema description coverage is 100% with a documented enum and default, so the schema fully carries this burden. The description adds nothing about response_format, which is the correct baseline-3 outcome here.

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

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

States a specific verb+resource ('Check the Meshy credit balance') that an agent can act on directly. It is clear and unambiguous, but it never differentiates itself from the nearby sibling meshy_list_usage, which an agent may reasonably confuse it with.

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?

'Free' implies usage (safe to call repeatedly, e.g. before expensive generations), but no explicit when-to-use, prerequisites, or alternative is named. The team-scope note is contextual rather than a routing rule, so guidance is only implied.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely new context the annotations lack: the exact cost (1 credit) and the economic trade-off versus remesh, which matters for agent budgeting.

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

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

Two sentences, purpose front-loaded, cost and the remesh comparison immediately after, then a compact example. Every element earns its place, though the example is mildly redundant given the 100%-covered 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 100% schema coverage and an output schema present, the description does not need to enumerate parameters or return values. Purpose, cost, and a call example are sufficient for a conversion tool; only explicit source-precondition guidance is missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including the enum values for target_formats and the precedence of input_task_id over model_url. The description adds only a worked example, which is illustrative but not additive semantics beyond the schema — baseline 3.

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 ("Convert a model to other file formats") and scopes it as format-only, which implicitly distinguishes it from geometry-altering siblings like meshy_remesh and meshy_retexture. It stops short of naming those siblings directly, so the differentiation is inferable rather than explicit.

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?

"cheaper than remesh for a format-only change" gives an implied when-to-use signal by contrast with meshy_remesh, but there is no explicit when-not guidance, no prerequisites (e.g. that the source must be a SUCCEEDED task or a public URL), and no routing to alternatives for other transformation needs.

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

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

Annotations cover the safety profile (non-readonly, non-idempotent, non-destructive), and the description adds much more: the call blocks for 2–5 minutes per stage with progress, returns only the final model, never surfaces the concept image, refunds FAILED stages, and charges still-running stages after timeout. The multicolor handoff constraint (task id not accepted) is a genuinely useful operational disclosure.

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

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

Front-loaded with the one-line purpose, then organized into scannable labeled sections (Products and cost, Outputs, Examples). It is long, but for a 14-parameter tool with nine product variants and an internal multi-stage pipeline, nearly every line carries load; only the outputs paragraph is borderline 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?

There is no output schema, so the description carries the return-value burden itself by enumerating output artifacts per product (GLB, lamp_stl/base_stl, 3MF, STL+GLB) and naming the download path. Combined with timeout semantics and the multicolor follow-on, an agent has everything needed to call and chain this correctly.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description goes further by attaching credit costs to each product enum value and clarifying product-specific parameter scoping (name_text keychain-only ≤10 chars, base_model keycap-only, pixel_subject required for fidget-pixel). The worked examples also demonstrate non-obvious parameter combinations.

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 — 'Turn a photo into a finished Creative Lab product 3D model, end to end' — and immediately establishes scope (photo input only, no text prompt). The product enum list with per-product descriptions makes its distinctness from generic siblings like meshy_image_to_3d obvious to an agent.

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 strong routing guidance: 'confirm before calling' on cost, pass the reported task_type to meshy_download_model, and use meshy_process_multicolor with the GLB URL (explicitly noting the task id is not accepted). It does not, however, explicitly compare itself against the alternative generation tools (meshy_image_to_3d etc.), leaving the 'why this over that' inference to the agent.

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

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

Annotations only declare idempotent/non-destructive/openWorld, but the description adds substantial behavioral context: that files land on local disk, that a format only exists if generated at creation time (3mf prerequisites), and that a failed download returns the URL instead of erroring. These are non-obvious traits an agent could not infer from the schema or annotations.

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

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

Front-loaded with the core action and destination, then organized into scannable bullets grouped by task type, closing with a concrete example call. Every sentence carries operational information; nothing is filler.

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

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

For an 8-parameter tool with no output schema, the description covers destination behavior, format prerequisites, per-task-type exceptions, failure handling, and includes a worked example. An agent has everything needed to invoke it correctly without further inference.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description genuinely adds meaning beyond the schema: it explains the format selection trade-off (never download all), the conditional relevance of format per task type, and the difference between print_ready's free local transform versus meshy_resize's credit-consuming server rescale.

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 ('Save a finished task's output') and names the exact destination semantics (meshy_output/ with project folders, or save_to). It clearly distinguishes itself from siblings like meshy_convert, meshy_resize, and the generation tools by being the terminal save step.

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 explicit when-to-use rules per task class: 3D tasks require choosing ONE format (with a mapped rationale per format), Creative Lab omits format, images/motion clips ignore format, and rigging/animation tasks are not saved at all. It even instructs the agent to ask the user before downloading, which is actionable routing guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial behavior beyond them: polling at the API's suggested interval with 5s→30s backoff, retry of failed status checks (timeout, 429, 5xx) at the next poll, the TIMEOUT outcome, and the fact that the task keeps running server-side with Meshy advising up to 60 minutes. This is exactly the extra context the annotations cannot carry.

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

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

Two dense paragraphs, front-loaded with the wait=true/false distinction before the polling mechanics. Every sentence carries operational information, though the polling detail is fairly heavy for a definition.

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 an output schema present, return-format details are unnecessary, and the description still covers the mode switch, polling/timeout semantics, and the recommended follow-up tools. Nothing needed to invoke this correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3; the description goes further by clarifying that task_type is advisory only (if omitted or wrong the server finds the real type), and that timeout_seconds bounds only this call, not the underlying task. It adds real meaning about parameter behavior rather than restating the schema.

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

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

The description states a specific verb and resource — wait for / check a task's status — and immediately distinguishes the two modes (wait=true default vs wait=false single check). It also notes it reports the real task_type, which separates it from siblings like meshy_list_tasks and meshy_cancel_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 gives clear conditions for each mode (poll until finish vs one-shot check) and routes the agent onward by telling it to pass the returned task_type to the download and cancel tools. It does not explicitly contrast itself with meshy_list_tasks for bulk status inspection, so the alternative-selection guidance is not fully closed.

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?

Goes well beyond the annotations (which only mark it non-read-only/non-idempotent) by disclosing runtime (~2–3 minutes), per-model credit costs and the Ultra +5 surcharge, default texturing behavior, and model-specific limits like 2K-only textures on meshy-6-lite. These cost/latency/default facts are exactly what an agent needs before committing to a paid, slow 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?

Front-loads the core action, then cost, then input constraints, then an example — a sensible priority order for a 28-parameter tool. It is dense but every block earns its place; the only slack is the parenthetical repetition of default-vs-bare-mesh behavior.

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 an output schema exists (so return values need not be described) and annotations cover the safety profile, the description supplies the remaining gaps: latency, pricing, input exclusivity, defaults, and deprecation warnings. An agent has everything required to invoke this correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds a constraint that is not encoded structurally: that exactly ONE image input must be supplied, plus a concrete invocation example. It does not re-explain most parameters, which is appropriate when the schema already carries them.

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

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

States a specific verb+resource ('Generate a 3D model from one image') and immediately scopes it against siblings by naming the multi-view alternative (meshy_multi_image_to_3d) for multi-image inputs. An agent can distinguish this from meshy_text_to_3d and meshy_multi_image_to_3d without reading 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 'IMAGE INPUT (exactly ONE)' block tells the agent which input modes exist and explicitly recommends file_path over self-encoded base64, plus routes multi-view output to a named sibling. It falls short of 5 because it never states when to prefer this tool over meshy_text_to_3d or when a refine step is warranted beyond the inline note.

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

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

Annotations only cover the read/write/idempotency profile; the description adds genuinely new operational context: a per-model credit cost table, a precedence rule ('Wins over the other sources'), an exclusivity constraint, and a safety instruction never to base64-encode files yourself. These are exactly the traits annotations cannot express.

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 purpose, then cost, then the reference-source constraint, then the 3D pointer, then an example. Dense but every sentence carries a distinct actionable fact with no filler.

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

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

With an output schema present, return values need no explanation. For a 9-parameter tool with model selection, cost, and source-exclusivity rules, the description supplies everything an agent needs to construct a correct 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 coverage is 100%, so 3 is the floor, but the description adds meaning the schema cannot encode: the cross-parameter exclusivity of the three reference sources, the precedence of input_task_id, the per-value cost of each ai_model, and the file-handling instruction for reference_file_paths.

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 ('Edit or restyle images with a text prompt') and implicitly separates itself from the generation sibling meshy_text_to_image. It also names the downstream sibling meshy_image_to_3d and its multi-view variant, so an agent can place the tool in the pipeline without opening any schema.

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

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

Explicitly tells the agent to give exactly ONE reference source and enumerates the three mutually exclusive options with their differences (task id vs local files vs URLs). It also gives the routing rule for 3D follow-up work and closes with a concrete invocation example.

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

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: the operation is free, an unfiltered call returns a very long result set, and it documents the return shape including that preview_url is an animated GIF. Only the flag of 'ids that no longer exist are simply absent' (in schema) and pagination behavior are unaddressed.

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

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

Three dense sentences with zero filler; the identity and cost are front-loaded, the filtering caveat second, and the return shape last. Every sentence earns its place, especially the return-shape line since there is no output 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?

Covers identity, cost, interaction with the sibling that consumes the ids, filter behavior, and the return fields despite no output schema. Nothing an agent needs to invoke this safely and correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema cannot: filters combine, and omitting them all returns the entire library. That materially changes how an agent should construct the call.

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

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

Specific verb+resource ('Look up preset animations') tied to a named sibling: 'the action ids meshy_animate takes'. An agent immediately knows this is the lookup companion to meshy_animate and can distinguish it from the other listing 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?

Gives real usage guidance: 'Filters combine; with none the whole (long) library comes back, so prefer search or category.' It steers the caller toward filtered queries and discloses cost ('Free'). It stops short of explicit when-not/alternative routing, but the context is clear.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely useful behavioral context beyond that: newest-first ordering, the fields returned (task_id, task_type, formats), and the request-cost implication that each task_type is 'one more request.'

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

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

Three sentences, front-loaded with the core purpose, then the default/widening behavior, then the sibling disambiguation. No filler or redundancy.

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

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

With no output schema, the description carries the return-value burden and does so by naming the returned fields and their downstream use (ready for meshy_download_model). Routing, defaults, and pagination (in schema) are all covered.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds contextual meaning: the image-to-3d default and the request-cost consequence of widening task_types. It slightly exceeds the schema text by tying the parameter to an operational cost model.

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 (finished 3D models), adds scope clarification ('not AI models'), and distinguishes itself from meshy_list_tasks by name. An agent can route between the two list tools without opening either schema.

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

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

Explicitly names the alternative (meshy_list_tasks) and the condition that selects it ('tasks of any status instead, images included'). Also states the default query behavior and how to widen it via task_types, leaving little to inference.

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

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

Annotations declare readOnly/idempotent/openWorld, and the description adds substantive behavior beyond them: filtering happens after fetch so pages can be shorter than limit, iteration via next_offset/has_more, per-type requests meaning partially failed queries surface in failed_types, and the cross-surface caveat that API-created tasks never appear in the web app.

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-loads the default behavior and type coverage, then routes alternatives and pagination caveats. Dense but every sentence carries information; the enum-heavy schema not the prose is where the bulk lies, so the description itself is appropriately sized.

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

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

No output schema exists, yet the description names the key return fields an agent needs (failed_types, has_more, next_offset) and explains the pagination caveat for a list tool with 8 params. Nothing material is missing for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: task_type names are the same as meshy_get_task_status, and task_types is merged with task_type with a documented default set. It stops short of clarifying the interaction between status/phase and limit beyond the pagination note.

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 tasks') plus scope ('any status', 'merged across the types queried', 'newest first by default'). It explicitly contrasts itself with meshy_get_task_status and meshy_list_models, so an agent can distinguish it from siblings without opening schemas.

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

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

Names two alternatives with the exact conditions that select them: 'With a task_id in hand, use meshy_get_task_status instead' and 'For finished 3D models only, meshy_list_models is cheaper.' It also documents the default type set and how to reach rigging/animation/print/Creative Lab 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?

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, yet the description adds substantial non-obvious context: the 403 gating for non-qualifying teams, that FAILED tasks are refunded and show 0 credits, that in-flight tasks are excluded, and the default 30-day / max 1-year window. This is exactly the kind of extra behavioral detail annotations cannot convey.

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-loads purpose and the free/gated status, then layers coverage rules, defaults, return shape, and an example in short scannable sentences. No sentence is filler despite the length.

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

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

There is no output schema, but the description fully compensates by enumerating the return object fields (task_id, endpoint, status, consumed_credits, api_key_name, etc.), pagination keys, and a concrete request example. An agent has everything needed to call and 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 coverage is 100%, so parameter syntax and defaults are already documented in the schema (including the note that 'text-to-3d' covers preview and refine). The description restates the default time window and provides a worked example but does not reveal meaning beyond the structured fields, so the baseline 3 applies.

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

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

States a specific verb (list), resource (team's finished API tasks), and scope (credits consumed, newest first), which cleanly distinguishes it from siblings like meshy_list_tasks and meshy_list_models. An agent can tell what it returns and how it is ordered without opening the schema.

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

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

Explicitly names the use case ('break down spend per endpoint or API key'), the eligibility gate ('only for API keys on a Studio or Enterprise team (others get 403)'), and what is in/out of scope (SUCCEEDED and FAILED listed, running tasks not listed). Nothing is left to inference.

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

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

Annotations already cover the safety profile (non-read-only, open-world, non-idempotent, non-destructive), so the bar is lower. The description nonetheless adds real behavioral value: credit costs per model, texture defaults, and the constraint that images must not be base64-encoded by the caller. It stops short of describing task lifecycle/async 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?

Front-loaded with purpose, then cost, then input selection, using clear headers. Efficient, though the cost sentence is dense and the section labels ('IMAGE INPUT') consume space without adding semantics.

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

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

For a 29-param tool with full schema coverage, existing output schema, and safety annotations, the description supplies the one thing the schema can't: how to choose among the three image-input routes and how cost varies. Nothing essential for a correct first call is missing.

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

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

Schema description coverage is 100%, so baseline is 3 and the schema already documents all 29 params. The description adds meaning beyond it by grouping the three input methods as mutually exclusive and flagging that cost scales with model choice, plus a worked example 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?

States a specific verb+resource ('Generate a 3D model') and pins the scope precisely: '1–4 views of the same object'. The parenthetical '(better reconstruction)' implicitly contrasts it with the single-image sibling, but it never names meshy_image_to_3d or meshy_text_to_3d, so sibling routing 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?

'IMAGE INPUT (exactly ONE)' lays out the three mutually exclusive input routes (file_paths / image_urls / input_task_id) with a concrete example, which is genuine when-to-use guidance. It falls short of 5 because it never states when to pick this tool over the single-image or text-to-3D 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?

Annotations already declare this is a non-read-only, non-destructive, non-idempotent, open-world operation, so safety is covered. The description adds genuinely new behavioral context: a 10-credit cost, the fact that the artifact arrives slicer-ready, and the brand-specific limitation where certain slicers cannot be auto-detected and the raw 3MF path must be handed to the user.

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-loads the purpose and cost in the first sentence, then moves to a short confirm-list and the download/hand-off step. Every sentence is actionable, though the parameter restatements slightly duplicate 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 7 all-optional parameters, no output schema, and three enums, the description supplies the missing glue an agent needs: credit cost, the required preconditions to confirm, the follow-up tool call, and the slicer-detection fallback. It stops short of describing pagination or return payload details, but no output schema exists to lean on, so a minor gap remains.

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

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

Schema coverage is 100%, so the schema already documents every parameter including the AMS/MMU meaning of max_colors and the realistic-only constraint on max_depth. The description's parameter notes (max_colors as AMS/MMU capacity, max_depth realistic-only) largely restate what the schema says, adding no new syntax, format, or defaulting guidance.

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 transformation ('turn a textured model into a multi-color 3MF') and names the concrete output artifact plus its readiness state ('opens ready to print in the slicer'). This clearly distinguishes it from siblings like meshy_convert (generic conversion), meshy_send_to_slicer (delivery), and meshy_retexture.

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 an explicit pre-flight checklist of values to confirm (max_colors, style, printer_brand, max_depth) and a concrete follow-up workflow ('Download with format "3mf", then open it with meshy_send_to_slicer'). It also handles the not-detected slicer case (Flashforge, QIDI, Snapmaker, AnkerMake) with an alternative action. No explicit when-not-to-use case is stated, so it falls just 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?

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, non-idempotent, open-world), so the description doesn't need to restate safety. It adds genuinely new behavioral context the annotations cannot express: a 5-credit cost, positioned against the 1-credit alternatives. It does not explain the async/task-based nature of the operation, which is the remaining behavioral 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?

Two sentences plus one example, with zero filler. The core action is front-loaded, the cost and routing guidance follow, and the example is placed last where an agent that already understands the tool can skip 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?

For a 13-parameter tool with a full-coverage schema, an output schema, and annotations, the description covers purpose, cost, and alternatives well. The one real gap is source selection: the schema marks nothing required, so the description never states that a model source (input_task_id or model_url) must be supplied and that the two are alternatives.

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 100% schema description coverage, the schema already defines every parameter, so the baseline would be 3. The worked example adds value beyond the schema by showing a realistic, valid combination (input_task_id + topology + target_polycount + target_formats) that demonstrates how the source and output-shaping parameters are used together.

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 ("Remesh an existing model") and immediately narrows scope to the two things it changes: polygon count or topology. It also explicitly names the sibling tools it is not (meshy_convert, meshy_resize), so an agent can route correctly without opening schemas.

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

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

Gives explicit when-not guidance with named alternatives and the discriminating condition: format-only changes go to meshy_convert, scaling goes to meshy_resize. Costs are attached to each option, which makes the routing decision actionable rather than merely descriptive.

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?

Despite existing annotations, the description adds substantial behavioral detail: 10-credit cost, that textures are removed, the input→output format mapping, the OBJ-preservation trick, conditional wall thickening, and scale preservation. This is exactly the extra context annotations can't convey.

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 behaviors, then the output-format mechanics. Dense but every sentence carries information; no filler. Slightly paragraph-heavy but structurally sound.

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 7-parameter tool with no output schema, the description explains the return format (input_task_id → GLB, model_url → input format), cost, side effects, and conditional behavior. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: the output format for model_url, the note 'to keep as OBJ, pass model_urls.obj', and how printer_type interacts with a print size to trigger wall thickening.

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 ('Repair a model for 3D printing') and enumerates exactly what it fixes (non-manifold edges, degenerate faces, holes, watertightness). It also distinguishes itself from siblings by naming meshy_resize and retexture.

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?

Explains the printing use case and the follow-up route ('retexture afterwards if needed'), plus when wall-thickening kicks in (with printer_type/size and >5% thin surface). It doesn't explicitly contrast against meshy_remesh or meshy_analyze_printability, but context is clear.

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

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

Annotations are non-committal (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so extra context matters. The description adds real value: a 1-credit cost, the exactly-one-of constraint, and that downstream tasks inherit the new size. It stops short of saying whether a model can be resized repeatedly or how it affects existing derived tasks.

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 cost, then the exclusivity constraint, then the alternative and an example. Every sentence carries distinct 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?

With an output schema present, return-value explanation is rightly omitted, and the cost, exclusivity, and downstream effects are covered. A minor gap remains: no guidance on choosing between resize_height and resize_longest_side when either would apply.

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

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

Schema coverage is 100%, so the per-field meanings are already documented, setting a baseline of 3. The description adds a genuine cross-parameter rule the schema does not encode -- give exactly one of resize_height, resize_longest_side or auto_size -- plus a worked example showing meters (0.05 for 5 cm).

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 (rescale) and resource (model to real-world size), and the title reinforces the scope. It implicitly distinguishes itself from meshy_remesh (geometry change) by framing the operation purely as rescaling with preserved aspect ratio.

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

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

Explicitly names the cheaper alternative (meshy_download_model with print_ready + print_height_mm) and the condition that selects it. It also states the mutually-exclusive input constraint and the downstream consequence that later tasks like Auto Split use the new size.

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

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

Annotations cover the safety profile (openWorld non-idempotent write), so the description's added value is the pricing disclosure (10 credits, 15 at 8K) and the input-combination rejection behavior, both of which are unavailable from structured fields. It does not say what happens to a model's prior textures or whether the source model is replaced, a modest remaining gap.

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

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

Front-loaded with the core action, then the constraint list, then an example call — a sensible order. The indented bullet block and embedded example are slightly verbose for the amount of information conveyed, but every line carries real 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 14-parameter tool with an output schema and full annotation coverage, the description supplies the highest-risk missing piece (style-input exclusivity) and pricing. It stays silent on the two source modes (model_url vs input_task_id), though those are documented per-parameter in the schema.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by documenting a cross-parameter constraint the schema cannot express, namely that text_style_prompt, image_style_url and multiview_image_urls are mutually exclusive, and by supplying a concrete example 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 first sentence states a specific verb and resource ('Apply new AI textures to an existing model'), which cleanly separates it from generation siblings like meshy_text_to_3d or meshy_image_to_3d. An agent can identify the operation without opening the schema.

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

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

It gives a hard usage rule ('EXACTLY ONE style input', tool rejects combinations) and enumerates the three mutually exclusive alternatives, which is genuinely actionable. It does not however explicitly compare against siblings such as meshy_uv_unwrap or meshy_remesh, so routing between tools is left partly to inference.

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

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a concrete cost (5 credits), included walk/run animations in GLB+FBX, the face-count precheck, and the .glb orientation constraint. It does not describe async/polling behavior for the resulting task, which is the one gap.

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

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

Front-loaded with purpose, cost, and included outputs, then a clearly delineated REQUIREMENT block and a Next steps block. Efficient and scannable; slightly verbose with the chained next-step arrows, but every clause earns its place.

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

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

For a create-style rigging tool with an output schema and full annotation coverage, the description supplies the prerequisites, cost, deliverables, and the routing to download/animate tools. Nothing an agent needs to invoke it correctly appears missing.

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

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

Schema coverage is 100%, so the schema already documents all five parameters including the model_url format and the texture_image_url pattern ref. The description reinforces the .glb/+Z constraint and mentions pose_mode, which is not even present in the schema (a minor mismatch). Baseline 3 is appropriate since the schema carries the parameter burden.

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

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

States a specific verb+resource ("Auto-rig a humanoid character for animation") and immediately constrains it (textured humanoid/biped). An agent can distinguish this from meshy_animate, meshy_text_to_motion, and the *_to_3d siblings without opening any schema.

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

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

Explicitly states upfront requirements (textured biped, ≤300k faces, .glb facing +Z, pose_mode t-pose for best results) and names routing alternatives: meshy_download_model with task_type "rigging", meshy_list_animations → meshy_animate, and meshy_text_to_motion → meshy_animate. This is textbook when/when-not/alternative guidance.

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

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

Beyond the readOnlyHint/idempotentHint annotations, it discloses operational constraints the agent could not infer: multiple models must be opened one-at-a-time ~2s apart (with an example command), parts of one model should be opened together, and it names the exact multicolor-capable slicers detected. This is meaningful behavior-level context.

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

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

Front-loaded with the core action and reasonably tight for the amount of workflow guidance provided. The slicer enumeration and multi-model paragraph are slightly verbose but each carries actionable information.

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

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

No output schema exists, and the description compensates by explaining the return (launch commands containing {file}) and how to consume it. It could be more explicit about the full shape of the returned recommendation object, but coverage is strong for a no-output-schema tool.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters (including the model_url placeholder note and slicer enum). The description largely restates this and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

It states a specific verb+resource — 'Detect installed 3D printing slicers and return their launch commands' — and clarifies the crucial nuance that the tool returns commands rather than actually performing the send implied by its name. This lets an agent know the tool is a detector/command-provider, distinct from any sibling that performs slicing itself.

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

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

It gives explicit workflow positioning: 'Call it at the START of a print workflow and keep the result; at the END, replace {file}...'. It also handles the fallback case ('If you cannot run shell commands, give the user the command and the file path'), so the agent knows both when and how to use the output.

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

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

Annotations only cover the generic safety profile (not read-only, not idempotent, not destructive, open-world); the description adds the non-obvious operational traits: an untextured preview output that must be refined, a typical 2–3 minute runtime, and a per-model credit cost table including the +5 Ultra surcharge. That is exactly the latency/cost disclosure annotations cannot carry.

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 the alternate route, then compact example objects; no filler sentences. It is on the longer side and the cost parenthetical is dense, but each block (workflow, routing, examples) carries distinct decision 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?

For a 16-parameter creation tool with an output schema present, the description covers the workflow position (preview -> refine), the competing route, cost/latency expectations, and worked parameter combinations. Return values are handled by the output schema, so nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond it by mapping ai_model choices to credit costs and by giving three concrete parameter bundles (low-poly, max detail, 3D print) that demonstrate how enum values like model_type, ai_model, geometry_resolution and target_formats are meant to be combined.

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 precise verb+resource+qualifier: 'Generate an untextured 3D PREVIEW from a text prompt', and immediately names the follow-on sibling (meshy_text_to_3d_refine) and the contrasting sibling route (meshy_image_to_3d). An agent can distinguish this from every sibling without opening a schema.

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

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

Explicit when-to-use and when-not: 'PREFER THE IMAGE ROUTE ... for higher quality and more control', with 'Use direct text-to-3d for a quick draft or when the user explicitly asks for it.' It also states the sequencing requirement (texture afterwards with refine once the user approves).

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

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

Annotations already declare the non-read-only, non-idempotent, non-destructive profile, but the description adds material behavior the annotations do not carry: the credit cost, the requirement to obtain user approval first, and the model-inheritance rule when ai_model is omitted. It does not restate that each call creates a new task, though that is implied by the example.

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

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

Three tight sentences: the action, the cost/approval constraint, then the model-inheritance rule, followed by a compact example. No filler, and the most decision-relevant information (what it operates on, cost, approval) is front-loaded.

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

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

With an output schema present, return values need no explanation, and the description covers the pipeline stage, cost, approval gate and model inheritance for a 13-parameter tool. The only minor gap is that it does not state the call is asynchronous and yields a task to poll, though the sibling meshy_get_task_status and the output schema make this inferable.

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 100%, so the baseline is 3, but the description goes beyond it by surfacing the key default behavior ('omit ai_model to inherit the preview's model') and giving a concrete example payload that shows how preview_task_id, texture_prompt and enable_pbr are combined. That is useful guidance layered on top of an already complete 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 precise verb and resource ('Texture a SUCCEEDED meshy_text_to_3d preview') and pins the pipeline position by requiring a SUCCEEDED preview, which cleanly separates it from meshy_text_to_3d (creates the preview) and meshy_retexture. An agent can pick this tool without opening the schema.

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

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

Gives a clear precondition (preview must be SUCCEEDED), a cost gate (10 credits, 15 at 8K) and an explicit approval requirement before calling. It stops short of naming sibling alternatives such as meshy_retexture or meshy_remesh for existing assets, so it is strong but not exhaustive.

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

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

Annotations only declare the safety profile (readOnly=false, openWorld=true, idempotent=false, destructive=false); the description adds latency (~30 s), per-model credit costs, and cross-parameter behavioral constraints such as remove_background having no effect on multi-view output. This is meaningful behavior an agent cannot derive from the structured fields.

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

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

Front-loaded with the purpose and latency, then cost, then routing, then a compact example — every element is actionable and nothing is padded. The cost enumeration is dense but it is the information needed for model choice.

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?

An output schema exists so return values need no explanation; the description still covers the workflow chain (this task -> image_to_3d / multi_image_to_3d), cost tradeoffs, timing, and the multi-view/aspect-ratio interaction. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by pairing each ai_model enum value with its credit cost, which drives model selection, and by giving a concrete example object showing prompt, ai_model, generate_multi_view and pose_mode together. Cross-parameter exclusions are repeated from the schema rather than 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?

States a specific verb+resource ('Generate a 2D image from text') and frames the artifact as a 2D design stage preceding 3D, which distinguishes it from the 3D siblings in the same family. It does not explicitly contrast with the closer sibling meshy_image_to_image, so differentiation is good but not complete.

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

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

Gives clear context for when to reach for it (produces a design for user approval before 3D) and routes the next step explicitly to meshy_image_to_3d with input_task_id = this task, or meshy_multi_image_to_3d for multi-view output. Missing are exclusions ('use X instead when you already have an input image'), which would make it 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?

Goes well beyond the annotations by disclosing credit cost (10 prime / 3 swift), advising confirmation before spending, and stating a 3-day retention window. These are exactly the behavioral traits (cost, persistence, format coupling) an agent needs before invoking a non-idempotent, open-world 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?

Front-loads the core purpose, then cost, then downstream usage in three tight blocks with a concrete example. Nothing is padded, though the parenthetical format caveat is slightly dense and could be trimmed.

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 an output schema present, return values need no explanation, and the description still supplies the cost, retention, and downstream-integration context an agent needs. Nothing essential for a correct call is missing.

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

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

Schema description coverage is 100%, so the schema already documents mode, prompt, duration and response_format, including the prime/FBX vs swift/BVH mapping. The description's FBX/BVH note restates schema content and its example adds only a usage illustration, so baseline 3 is appropriate.

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 character motion clip') and immediately disambiguates the output type with '(skeleton motion, not a model)', which cleanly separates it from the text-to-3d siblings. An agent can distinguish it from meshy_text_to_3d without opening either schema.

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

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

Gives clear downstream routing: apply the result via meshy_animate (motion_task_id) or save it with meshy_download_model, and notes which format each mode yields. It lacks an explicit 'when not to use this' or a cost-based alternative comparison, so it stops just short of the top score.

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?

Adds substantial context beyond the annotations: a stated cost (5 credits), hard input limits with the rejection behavior and the required recovery step, and a precise description of the output transformation (geometry preserved, quads/n-gons triangulated, fresh UVs, grey placeholder material). The annotations only cover generic safety/idempotency hints, so this operational detail is genuinely additive.

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

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

Two tight paragraphs, front-loaded with purpose, then cost, then constraints and output behavior. Every clause carries information (limits, credits, transformation result) and nothing is repeated from the schema or title.

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

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

For a generation tool with an output schema, the description covers everything an agent needs to invoke it correctly: required input format, size ceiling with the fallback path, cost, and the shape of the returned asset. Return-value details can safely be deferred to the output schema.

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

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

Schema description coverage is 100%, so all three parameters (including the model_url vs input_task_id precedence and the response_format enum) are already documented in the schema. The description only reinforces the GLB-only constraint and the 'convert other formats first' step, adding marginal meaning beyond structured data. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('Make a clean, non-overlapping UV layout') and immediately clarifies the artifact produced (a 'UV white model' for texturing). It is easily distinguished from siblings like meshy_retexture, meshy_remesh, or meshy_convert without opening any schema.

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

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

Gives clear prerequisites (GLB input only, ≤40,000 faces) and a routing hint for the failure case ('denser meshes are rejected: remesh first'), which points at the meshy_remesh sibling. It positions the tool in the pipeline ('before texturing in Blender, Substance Painter or Unreal'), but never explicitly states when-not to use it or names alternatives beyond the remesh hint.

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