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

With annotations declaring destructiveHint=true, readOnlyHint=false, and idempotentHint=false, the safety profile is already covered. The description adds real value beyond that: it warns credits are spent, discloses the async pattern (returns task_id immediately rather than the result), and routes to wait_for_task. It does not say whether the source segment_mesh task is altered or how much credit is consumed by default.

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

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

Two tight sentences, front-loaded with what the tool does and followed by the cost/async caveat and next step. Every clause earns its place with no filler.

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

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

An output schema exists, so return-value detail is unnecessary, and annotations cover the destructive/async profile. The description supplies the credit-spend warning and the wait_for_task hand-off, leaving only minor gaps around which completion mode to choose and whether the source task is mutated.

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 every parameter already carries its own description including the credit costs in the completion_mode enum. The only added meaning is 'optionally only the named ones' for part_names, which the schema already conveys. Baseline 3 is appropriate when the schema does the heavy lifting.

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: 'Fill in the parts of a segment_mesh task.' It ties the tool to the segment_mesh sibling whose task_id it consumes, so an agent can place it in the pipeline without opening the schema. It stops short of explicitly distinguishing itself from smart_segment, so a 4 rather than 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?

'optionally only the named ones' signals the part_names use case, and 'then call wait_for_task' gives the essential follow-up step, which is strong workflow guidance. However, it never states when to prefer ai_completion vs quick_cap beyond the inline enum text, and offers no explicit 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?

Annotations already declare destructive=true, openWorld=true, and idempotent=false, so the safety profile is covered. The description adds genuinely new context beyond that: the operation spends credits and is asynchronous, returning a task_id immediately rather than the result. It does not detail reversibility or what is destroyed, but the added cost/async disclosure is substantive.

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

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

Two tight sentences, front-loaded with the core verb and formats, followed by the essential cost and follow-up call. Zero filler.

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

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

For a 19-parameter async tool with an output schema and rich annotations, the description covers purpose, cost, and the required follow-up step. It could note that conversion may be lossy or how input task IDs versus URLs behave, but nothing critical to correct invocation is missing.

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

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

Schema description coverage is 100%, so all 19 parameters are already documented in the schema. The description's phrase 'topology, scale, pivot, orientation or textures' loosely categorizes the parameter space but adds no syntax, defaults, or constraints beyond what the schema provides. 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 (convert) and resource (mesh) plus the exhaustive set of target formats, which no sibling tool offers. An agent can immediately tell this is the format-conversion tool rather than retopologize, texture_model, or complete_mesh.

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 the critical operational context: it creates a Tripo task, spends credits, and returns a task_id that must be followed by wait_for_task. That is clear when/how-to-use guidance for the async workflow. It does not, however, name alternatives (e.g., use retopologize if you only need quads), so it stops short of a 5.

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

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

Annotations already declare destructiveHint=false and idempotentHint=true; the description complements them by disclosing the concrete overwrite behavior on repeat downloads and the on-disk destination structure. It adds no auth, permission, or rate-limit context, but that is a minor gap given 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 tight sentences: the first front-loads the action and destination path, the second handles the format caveat and the alternative tool. Nothing is redundant and no sentence 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?

With an output schema present, return values need no explanation, and the description covers the success requirement, destination path, overwrite semantics, and the alternative tool. 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 description coverage is 100% and the outputs parameter already enumerates the valid values (model, rendered_image, etc.) with its 'default all' behavior. The prose adds only the indirect note that formats come from what the task produced, so the schema is doing the heavy lifting.

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 (save/download), the resource (outputs of a successful Tripo task), and the exact destination layout <output dir>/<task_id>/<output>.<ext>. It also distinguishes itself from convert_model in the same breath, so an agent can separate download_task from the format-conversion sibling immediately.

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 (the task must be successful) and explicitly routes other-format needs to convert_model. It does not spell out what to do when a task is not yet complete (e.g., wait_for_task), so it falls just short of full when/when-not coverage.

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 destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the mutation/unsafe profile is covered. The description adds genuinely new context beyond them: it spends credits and returns task_id immediately, requiring a follow-up wait_for_task call. It does not detail auth or what specifically gets overwritten, but the async/cost behavior is valuable.

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, zero waste: purpose first, then the operational sequence and cost. Front-loaded and immediately actionable.

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 2-param tool with full schema coverage, annotations covering safety, and an output schema, the description supplies everything required to call it: what it edits, the credit cost, and the required follow-up call. Only minor gaps remain (error behavior, edit limits on an existing 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 100%, so the schema already documents both parameters, including that input is a task ID and prompts are 1-4 per-view edits costing 5 credits each. The description's 'per-view prompts' restates this without adding syntax or format detail. Baseline 3 is appropriate when the schema carries the wording.

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: correcting individual views of an existing image_to_multiview task using per-view prompts. This cleanly distinguishes it from the sibling image_to_multiview, which creates the multiview in the first place. An agent can tell the two apart without opening either schema.

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

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

Gives clear workflow context: it operates on an existing multiview task and must be followed by wait_for_task. It names the input lineage (image_to_multiview/edit_multiview task) and the cost implication. It stops short of explicit when-not guidance or naming alternatives, but the operating 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 readOnlyHint=true, so the safety profile is covered. The description earns credit by adding domain behavior the annotations cannot convey: the 1 credit = US$0.01 conversion and the fact that frozen credits are tied up by running tasks, which explains why the two figures may differ. It does not, however, note anything about rate limits or freshness.

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, no filler, and the core action leads while the explanatory detail about frozen credits follows. Every clause carries information.

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

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

With an output schema present, the description need not explain return values, and it correctly stays brief for a zero-parameter read. The one omission is a pointer on how this relates to get_usage, which matters given the sibling 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?

The tool takes zero parameters, and the schema is fully specified with no fields to document. Baseline 4 applies since there is nothing for the description to clarify.

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 account's available and frozen credits. The scope is precise and the credit unit is defined, so an agent knows exactly what it returns. It does not differentiate itself from the sibling get_usage, which is the one nearby tool an agent might 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?

There is no statement of when to call this versus get_usage, nor any prerequisites or exclusions. The only contextual cue is the explanation of frozen credits, which helps interpret the result but not decide when to invoke the tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the field list but does not explain why idempotentHint=false on an apparently static read (mutable host/version), which is the one behavior an agent might be surprised by.

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 the returned fields front-loaded and no filler. Every word earns its place.

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

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

With an output schema present, return values need not be explained in prose, and a parameterless read-only tool needs little else. The description is sufficient, lacking only a hint about when this call is worthwhile.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter information is missing or misleading.

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 ('Show') plus a named resource ('config') with the exact fields enumerated: Tripo API host, output directory, server version. An agent can immediately distinguish it from get_usage and get_balance, which report different data.

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 what is returned but never says when to call it — no trigger condition (e.g., before constructing requests or diagnosing environment issues) and no relationship to siblings. For a diagnostic endpoint, the absence of any context is a missed opportunity rather than an error.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely new behavior — that returned URLs are signed and time-limited — which is exactly the kind of trait annotations cannot express. It leaves the idempotentHint=false distinction (repeated calls may return different progress/URLs) unexplained, which is a minor 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, zero filler. The return payload is front-loaded and the expiry caveat with its remediation follows immediately, which is the correct ordering for an agent deciding whether to act on the URLs.

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 described, and the expiry warning is the one behavioral fact an agent must have. The only omission is guidance on polling/waiting relative to wait_for_task, which matters for a long-running 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?

There is a single parameter with 100% schema description coverage, so the schema already documents task_id as 'Task ID returned by a task-creating tool'. The description adds no format, source, or validation detail beyond that, so the baseline 3 for a fully-covered schema 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 ('Get a Tripo task's status, progress, outputs and error'), enumerating exactly what the call returns rather than restating the name. It also implicitly distinguishes itself from the plural sibling get_tasks and routes the agent to download_task, so an agent can place it 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 clear conditional routing: output URLs are signed and expire, so use download_task to save them. It does not, however, mention when to prefer wait_for_task for polling versus calling get_task repeatedly, which is the other obvious alternative in this sibling set.

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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: the batch cap and, more importantly, the partial-failure contract that unresolvable IDs surface under 'missed' rather than erroring the whole call. Ordering guarantees and whether all-or-nothing semantics apply are still unstated.

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, both front-loaded and free of filler. The batch limit leads and the edge-case handling follows, so every clause carries information.

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

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

An output schema exists, so return-value documentation is not required, and the description still flags the 'missed' key an agent would otherwise have to discover. For a one-parameter batch getter distributed across a 27-tool surface, this is nearly complete; only ordering and duplicate-ID behavior are 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 coverage is 100% and the single parameter already documents 'Up to 100 task IDs', so the description's 'up to 100' largely repeats structured data. It adds only indirect semantics by tying bad IDs to the 'missed' output, a baseline 3 given the schema does the heavy lifting.

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 ('Get ... Tripo tasks') and quantifies the batch scope ('up to 100 ... at once'), which implicitly separates it from the singular get_task sibling in the list. It stops short of explicitly naming that sibling, so an agent must infer the batch-vs-single 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?

'At once' implies a batch retrieval use case, so the usage context is implied rather than stated. There is no explicit 'use this instead of get_task when...' routing, no mention of when the parallel call is preferable to looping the single-task tool, and no 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds that output includes per-task credit consumption, which is useful context, but says nothing about refresh cadence, rate limits, or whether 'recent' has a fixed window.

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

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

A single front-loaded sentence that states the resource and the distinguishing payload. It is appropriately sized for a two-parameter read tool and contains 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, the description need not explain return values, and annotations cover safety. The remaining gap is sibling disambiguation from get_tasks/get_balance, but for a simple paginated listing the description is otherwise sufficient to call the tool correctly.

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

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

Schema description coverage is 100%, so both limit and offset are already documented in the schema with their meaning and default. The description adds no parameter-level detail such as maximum page size or how offset interacts with 'recent', so it sits at the baseline.

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

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

The description gives a specific verb ('List') and resource ('recent Tripo tasks') and adds a distinguishing scope ('with the credits each one consumed'), which separates it from a plain task listing. It does not explicitly name or contrast with siblings such as get_tasks or get_balance, so it stops short of full sibling differentiation.

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

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

Usage is only implied: an agent can infer it is for inspecting per-task credit consumption, but there is no explicit when-to-use statement, no exclusions, and no routing to alternatives like get_tasks or get_balance. 'List recent tasks with credits' is enough to guess intent but not to choose confidently.

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 destructiveHint=true, idempotentHint=false and openWorldHint=true, so the bar is lowered. The description nonetheless adds genuinely new behavioral facts: the call spends credits and is asynchronous (returns task_id immediately, requires wait_for_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?

Two sentences with zero waste; the mutation/credit cost and async hand-off are front-loaded. 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?

An output schema exists so return values need not be explained, and schema coverage is complete. The description covers the cost model and the required task->wait_for_task chaining, which is what an agent most needs to call correctly; only sibling-vs-sibling selection guidance is 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 100% with per-parameter docs, enums, and defaults, so the schema carries the parameter burden and a baseline 3 applies. The description adds no parameter meaning beyond the schema — no guidance on model selection tradeoffs, input reference syntax, or prompt/template interplay.

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 ('Edit or derive an image') with the key scope qualifier 'from one or more reference images', which implicitly separates it from text_to_image. It does not explicitly distinguish image_to_image from the other image-input siblings (image_to_model, image_to_splat, image_to_multiview), whose differing output type is only inferable from the name.

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 async workflow is well covered ('returns its task_id immediately; then call wait_for_task'), which names the follow-up tool explicitly. However there is no guidance on when to choose this over text_to_image or the other image_* siblings, nor on which model/template to pick, so primary tool-selection guidance 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?

Adds behavior the annotations don't convey: the call spends credits and returns a task_id immediately rather than a finished mesh, establishing the async pattern. Annotations already flag it as a non-idempotent, destructive write, so the description isn't obligated to restate that; per-option credit costs live in the schema.

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

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

Two sentences: the first defines the operation and valid inputs, the second covers side effects and the required next call. No filler, and the most decision-relevant facts (what it makes, what it costs, what to do next) are front-loaded.

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

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

For a 21-parameter async generator with an output schema and full annotation coverage, the description supplies what the structured fields cannot: credit spend, immediate task_id return, and the wait_for_task handoff. It omits failure/precondition detail (e.g. minimum image size is only in the schema), which keeps it from a 5.

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% and every one of the 21 parameters is documented inline, including constraints, defaults and credit surcharges. The description adds no parameter-level meaning beyond restating the accepted input forms, so the 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 3D mesh from one reference image') and scopes it to a single image, which cleanly separates it from multiview_to_model and text_to_model. The enumerated accepted input forms make the boundary even sharper.

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 the upstream sources that produce valid input (text_to_image / image_to_image task IDs) and gives the explicit follow-up step: 'then call wait_for_task.' It doesn't contrast itself against sibling generators like multiview_to_model or image_to_splat, so it stops short of full when-not 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 annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true), the description discloses the two behaviors an agent most needs: the call spends credits and it returns asynchronously with a task_id rather than the finished result. It doesn't quantify cost or note failure/queue behavior, and it is consistent with the destructive/state-changing annotations rather than contradicting them.

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 compact sentences, front-loaded with what is produced, then downstream routing, then the async/credit caveat. Every sentence carries distinct, 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?

An output schema exists, so return-value documentation is unnecessary; the description still covers the async pattern, the credit cost, and the next tool to call. 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?

Only one parameter and schema coverage is 100%, so the schema already explains that 'input' accepts a local path, URL, file token or image task ID. The description adds no format or constraint detail beyond that, which is the expected baseline when the schema does the work.

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 output (generate front, left, back and right views) from a specific input (one reference image), which an agent can distinguish from image_to_model, image_to_splat, and text_to_image without opening another 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 routes the output task ID to multiview_to_model or edit_multiview and tells the caller to follow up with wait_for_task, so the pipeline position is clear. It does not say when this is the wrong choice versus image_to_model or edit_multiview, so no 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?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true. The description adds valuable beyond-annotation context: approximate credit cost, duration, the fact that credits are spent, and the asynchronous task-based flow requiring wait_for_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?

Three short sentences, front-loaded with the core action and output format. Each sentence carries distinct, useful information: artifact type, cost/time, and async follow-up.

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, the description need not document return values. It covers the key operational facts: what is generated, approximate cost and time, and the required follow-up call. It is complete enough for correct invocation, though it does not explicitly compare against sibling image 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 100%, so both parameters are fully documented in the schema. The description adds only the implicit constraint of a single image input and no additional detail about model_seed format or effect. 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 ('Generate'), a specific output format ('Gaussian splat (.splat)'), and a clear input constraint ('from one image'). This distinguishes it from siblings like image_to_model and image_to_multiview, which produce different artifact 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?

Explicitly instructs the agent to follow up by calling wait_for_task after the immediate task_id return. It also gives cost and time expectations, which help set usage context. It does not name alternative sibling tools or state when not to use this one.

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 non-read-only, destructive, open-world, non-idempotent behavior. The description adds behavior the annotations cannot convey: that credits are consumed and that the operation is asynchronous with an immediate task_id return requiring a follow-up wait_for_task call. This is genuine additive context, though it says nothing about failure modes or credit costs when an import is rejected.

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, no filler. The capability and formats come first, the cost + async contract second — properly front-loaded and every clause carries information.

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

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

With an output schema present, the description need not describe return values, yet it still explains the async pattern and the required follow-up call. Annotations cover the mutation/safety profile and the single parameter is fully documented, so nothing needed for correct invocation is missing.

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

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

Schema coverage is 100% with a single parameter, so the baseline is 3 per the rubric. The description slightly exceeds that by clarifying the accepted input forms (local path, URL with GLTF-only restriction) and reasserting the 150 MB cap in the context of the whole tool, reinforcing rather than purely duplicating 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 pairs a specific verb (import) with a specific resource (an existing mesh), enumerates the accepted formats, caps the size at 150 MB, and states the resulting artifact (a task ID usable by other operations). This cleanly separates it from siblings like convert_model, upload_file, and the *_to_model generators.

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 guidance — the call is asynchronous, returns task_id immediately, and the agent should then call wait_for_task — plus a cost warning about credits. It does not, however, contrast this tool against nearby alternatives (e.g., convert_model for changing format, upload_file for staging files), so the when-not case is left implicit.

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 read-only and non-open-world safety, but the description still adds real context: the result is static (no live lookup), it enumerates aliases/defaults/rejected options, and unknown versions are passed through with a warning rather than hard-failing. It does not explain why idempotentHint is false, which is the one unexplained annotation.

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 compact sentence, front-loaded with the core action and resource, with the parenthetical detail arriving after. It is dense but every clause carries information; nothing is padded.

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

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

An output schema exists, so return-value explanation is not required, and the description still previews what the list contains. Combined with full schema coverage for the single optional parameter, an agent has enough to invoke it correctly; only the idempotency caveat is left dangling.

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% and the sole 'operation' parameter is fully documented in the schema. The description's 'per tool' phrasing echoes that meaning without adding format, enum, or default details beyond it, so the baseline of 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+resource (list model versions) and scopes it clearly as 'per tool', with the payload contents named (aliases, defaults, rejected options). It reads distinctly from siblings like get_config or get_usage, though it never explicitly contrasts itself with them.

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 can infer it should call this before picking a model version, and the 'static; unknown versions are still sent to Tripo with a warning' line hints at validation semantics. There is no explicit when-to-use versus alternatives and no named alternative tool.

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 disclose the write/destructive/non-idempotent profile, so the bar is lower. The description adds genuinely useful behavior: it spends credits and is asynchronous, returning a task_id immediately with wait_for_task as the completion path. It could say more about failure/refund behavior on a failed 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?

Two sentences with no waste: inputs first, then the async cost/return contract. Fully front-loaded and appropriately sized for a 21-parameter 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?

With an output schema present and 100% parameter coverage plus annotations covering safety, the description supplies the one thing structured fields cannot: the create-then-wait_for_task workflow and that credits are consumed. Minor gaps remain around error handling, but nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100% and the schema already documents the mutually-exclusive input/inputs fields and the front-required rule, so the description adds no syntax or constraint detail beyond it. Baseline 3 is appropriate when the schema does all the heavy lifting.

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 ('Generate a 3D mesh') and names both input modes: 2-4 views of one object with front required, or the output of image_to_multiview / edit_multiview. This distinguishes it cleanly from siblings like image_to_model (single image) and text_to_model.

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 specifies the conditions for use (2-4 views, front required, or an upstream multiview task) and names the required follow-up tool, wait_for_task. It stops short of explicitly naming the single-image alternative (image_to_model) as a when-not-to-use, so an agent must infer the boundary.

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, idempotentHint=false, and openWorldHint=true, but the description adds crucial context beyond them: cost ('10 credits per animation'), that credits are spent, and the async contract (returns task_id immediately). It does not clarify whether the source rig task is mutated, which is the one gap given destructiveHint=true.

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

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

Two tight sentences with the operation and scope front-loaded, followed by cost and the async next step. Every clause earns its place with no filler.

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

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

An output schema exists, so return values need no explanation. With the prerequisite, per-unit credit cost, and the wait_for_task handoff all stated, an agent has everything needed to invoke and chain this tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents input, animation, animations, out_format, animate_in_place, and export_with_geometry. The description reinforces the 'up to 5' cap on animations but adds no syntax or format detail beyond the schema, so 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?

Specific verb+resource: 'Apply up to 5 preset animations to a rig_model task.' It names the input artifact (rig_model task) which distinguishes it cleanly from sibling tools like rig_model, retopologize, or texture_model.

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?

States the prerequisite (a rig_model task) and the follow-up step ('then call wait_for_task'), which routes the agent through the async workflow. It does not explicitly state when-not-to-use or contrast against alternatives, 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?

Annotations already declare destructiveHint=true and idempotentHint=false, so the mutation profile is covered. The description adds genuinely non-annotated traits: it 'spends credits' and returns a task_id immediately (async, non-blocking). It does not clarify what happens to the original mesh, but the cost and async disclosures are meaningful additions.

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, zero filler. The core purpose is front-loaded, followed immediately by the cost and async handoff, which is exactly the ordering an agent needs before deciding to call.

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 detail is unnecessary, and the description covers the key non-schema facts: cost, async behavior, and the required follow-up call. It does not address whether the source mesh is altered (relevant given destructiveHint=true) or the credit magnitude, leaving a minor gap for a 7-parameter task-creating 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 every parameter (bake, quad, model, smart_uv, face_limit, part_names) is already documented in the schema, including enum values and ranges. The description's 'triangles or quads' only loosely echoes the quad param and adds no syntax or format detail beyond the schema. 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 ('Rebuild a mesh as clean low-poly triangles or quads') with a parenthetical that names the technique (smart low-poly retopology). This clearly separates it from siblings like segment_mesh, complete_mesh, or smart_uv, though it doesn't explicitly name a sibling it is not.

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 concrete workflow context: it creates a Tripo task, returns a task_id immediately, and instructs the agent to 'call wait_for_task' next. That routes the agent through the async pattern. It stops short of stating when to choose this over alternatives (e.g., version trade-offs), but the operational guidance 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?

Adds real context beyond the annotations: the operation is free, it is asynchronous (returns task_id immediately rather than the verdict), and the result surfaces as riggable/rig_type outputs. This is consistent with readOnlyHint=false and non-idempotent task creation. It does not explain why destructiveHint=true for a check operation, leaving that flag unexplained.

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, front-loaded with the purpose, then the return semantics, then the required follow-up call. No filler and nothing repeated from structured fields unnecessarily.

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, yet the description helpfully names the relevant output fields (riggable, rig_type) and documents the async task pattern and follow-up tool. For a one-parameter async tool this is close to complete; only the rationale for the destructive annotation is left 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 100% and the single 'input' parameter already documents accepted forms (task ID, file token, URL, GLB/FBX/OBJ/STL). The description adds nothing about the parameter, 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 mesh can be rigged and detect its skeleton type.' An agent can distinguish this from rig_model by the word 'check', but the description never names or contrasts that sibling, so differentiation is inferred 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?

Gives a concrete workflow: it creates a task and returns task_id immediately, then explicitly names wait_for_task as the next call. What's missing is when to choose this over rig_model (i.e., that this is the pre-flight check before rigging) — no exclusions or alternatives 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?

Adds materially beyond the annotations: explicit cost (25 credits), the fact that it creates a Tripo task and returns a task_id immediately (async, non-blocking), and the required follow-up call. Annotations only cover the safety profile, so this operational detail is real added value.

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 short clauses, zero filler, and the highest-value facts (what it does, cost, prerequisite, async flow) are 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?

An output schema exists, so return-value detail is unnecessary; the description still adds the key async return (task_id) and the next call. Cost, prerequisite and sequencing make this complete for an expensive, non-idempotent task-creation 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% with enums documented for spec, model, rig_type and out_format, so the schema carries the parameter burden. The description adds no parameter-level guidance (e.g., which rig_type/model pairing to pick), 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+resource+goal: 'Auto-rig a mesh for animation.' An agent can distinguish it from siblings like rig_check (validation), retarget_animation (animation transfer), and retopologize 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 an explicit prerequisite ('Run rig_check first') and a downstream step ('then call wait_for_task'), naming two sibling tools with the conditions that select them. There is no explicit when-not-to-use or cost-vs-alternative tradeoff, which keeps it below 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 write/destructive/non-idempotent behavior, but the description adds meaningful context beyond them: it discloses that the call spends credits, returns a task_id immediately (async), and requires a follow-up wait_for_task. This credit-cost and async-flow disclosure goes beyond the structured 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?

Three short sentences, front-loaded with the core action and followed by the essential follow-up workflow. Every sentence earns its place with no 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?

Output schema exists so return values need not be explained, and the description captures the async task flow and credit cost. The only notable gap is the absence of any differentiation from the smart_segment sibling, which an agent would need for correct tool selection.

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 fully documents all five parameters including version differences and enums. The description adds no parameter-level meaning beyond what the schema already provides, which is the expected baseline of 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 ('Split a mesh into parts'), which is clear and actionable. However, it does not distinguish itself from the sibling tool smart_segment, which appears to serve a similar segmentation purpose, so an agent cannot easily tell the two apart from the description 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?

It gives explicit downstream workflow guidance ('Feed the task ID to complete_mesh' and 'then call wait_for_task'), which is genuinely useful. But it offers no guidance on when to choose this over smart_segment or other siblings, so usage selection is only partially addressed.

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 destructive=true, idempotent=false and openWorld=true, so the safety profile is partly covered. The description adds meaningful behavior the annotations do not: it spends credits (85 for image, 55 for mesh), is asynchronous, returns immediately with a task_id, and requires a follow-up wait_for_task call.

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, zero filler, and the primary action plus its cost consequence are front-loaded before the async follow-up instruction. Every clause carries information an agent needs.

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, the description does not need to explain return values, and it correctly focuses on the async handoff to wait_for_task. Coverage is good for a 5-parameter mutation tool; only the relationship to the segment_mesh sibling is left unstated.

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 every parameter, including the enum values and the transform array, is already documented in the schema. The description restates the seg_type cost split and the hint concept but adds no format or syntax detail beyond what the schema provides, which is the baseline 3 case.

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 ("Segment an object") plus the guiding mechanism (text hint) and the two supported input types, so the agent knows exactly what the tool produces. It does not, however, distinguish itself from the sibling segment_mesh, which an agent must otherwise infer 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?

Gives explicit workflow guidance: the call creates a Tripo task, returns a task_id immediately, and the agent should then call wait_for_task. It also surfaces the cost tradeoff that selects image vs model input. It stops short of saying when to prefer this over segment_mesh or the other generation 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 destructive/non-readonly/async-open-world behavior, and the description adds real value on top: a 20-credit cost, the triangle ceiling, and the asynchronous task_id-then-wait pattern. It does not explain what is destroyed or overwritten (e.g., prior UVs/textures via bake) or credit-refund behavior 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?

Three tight sentences with zero filler; the capability, limit, cost, and async follow-up are all front-loaded in the order an agent needs them.

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

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

An output schema exists so return values need no explanation, and annotations cover the safety profile. The description supplies cost and async workflow, but omits what the destructive operation affects and whether credits are refunded on failure — modest gaps for a paid, destructive task 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 input, bake, model, compress, and export_orientation. The description only echoes the ~80k triangle input limit and adds no syntax or semantic 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?

States a specific verb+resource ('Unwrap UVs for a mesh'), adds a concrete scope limit (~80k triangles) and a secondary output (UV layout preview). An agent can distinguish this from texture_model or retopologize 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 the operational workflow explicitly: it creates a task, returns task_id immediately, and instructs the caller to then call wait_for_task. That routes the agent to the correct follow-up sibling. It does not, however, say when to prefer this over texturing or retopology steps.

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 non-read-only, destructive, non-idempotent, open-world, and the description adds genuinely useful context beyond them: the operation spends credits, is asynchronous ('returns its task_id immediately'), and requires a follow-up wait_for_task call. It could go further on whether failures refund credits, but the added behavioral value is real.

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

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

Three tight sentences with zero filler. The core purpose and the credit-spending warning are front-loaded, and the async follow-up is stated last in execution order.

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, yet the description still usefully states that a task_id is returned and how to consume it. Combined with the credit and async notes, the definition is complete enough to call correctly, with only the sibling-differentiation gap remaining.

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 9 parameters with enums and defaults. The description adds no parameter-level meaning of its own, so the baseline of 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 ('Generate a reference image from a text prompt') and names a downstream consumer (image_to_model). However, it does not differentiate itself from the sibling image_to_image, which also produces images, so an agent must infer the distinction 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?

Provides a clear workflow cue ('then call wait_for_task') and notes the task ID can feed image_to_model, which implies usage. But it gives no explicit when-to-use vs. image_to_image or other generation siblings, leaving the selection 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 this is non-readonly, destructive, non-idempotent, and open-world. The description adds valuable behavior beyond that: it spends credits and returns immediately rather than blocking. It could note the credit magnitude or that repeated calls create new tasks, but the async/credit disclosure is solid.

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, both front-loaded: the first states the purpose, the second the async pattern and follow-up call. 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?

An output schema exists and annotations cover the safety profile, so the description needn't explain returns. Given the tool's complexity (20 params, credit spend, async), the description adequately covers the essential non-structured facts (credits, task_id, wait_for_task follow-up), though it omits any hint of the parameter surface.

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% across all 20 params, including credit costs, model versions, and constraints, so the schema carries the full parameter burden. The description adds no parameter detail beyond prompting implicitly, so the 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 3D mesh from a text prompt'), which cleanly separates it from image_to_model and multiview_to_model siblings. An agent can identify the tool's function from the first sentence 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?

Explicitly describes the async workflow: it creates a Tripo task, returns a task_id immediately, and directs the agent to call wait_for_task next. It does not, however, say when to choose this over image_to_model or multiview_to_model for a given input modality.

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 destructiveHint=true, readOnlyHint=false, and non-idempotence. The description adds genuinely new behavior: asynchronous task creation, immediate task_id return, and credit consumption. It does not explain what is destroyed (e.g., existing mesh textures being replaced), which is the one gap given destructiveHint=true.

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, no filler, and the credit/task_id consequence is front-loaded right after the purpose. Every clause earns its place by telling the agent what the call actually does downstream.

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 there is no need to describe return values, and the description still supplies the one thing the schema cannot: the async handoff to wait_for_task and the credit cost. Safety is covered by annotations and parameters by the schema, so nothing needed to call 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% and every parameter including the nested texture_prompt carries a description, so the schema does the heavy lifting. The description only implies the prompt modalities; it adds no format, syntax, or default detail beyond the schema. 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?

Specific verb+resource ('Generate new textures for a mesh') with the accepted prompt modalities enumerated (text, image, four-view). An agent can tell this apart from sibling model-generation tools like text_to_model, multiview_to_model, and smart_uv 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 the async workflow: it creates a task and returns task_id immediately, then the agent must call wait_for_task. It also flags that credits are spent. Missing any when-not-to-use guidance or alternative texturing paths, but the operating context is unambiguous.

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 carry the safety profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true, idempotentHint=false), lowering the bar. The description adds the return artifact (a reusable file token) but does not explain why a mere upload is flagged destructive or what remote state it creates, so it adds only modest 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?

Two tight sentences, front-loaded with the purpose and immediately followed by the caveat. Nothing is wasted and 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 fully-documented parameter plus annotation safety profile leave no gap. For a one-parameter utility, purpose, guidance, and output 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% and the single 'path' parameter is documented there with formats and size limits, so the schema does the heavy lifting. The description only mirrors it by saying 'local image or model' without adding format or path syntax detail, making the baseline 3 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 ('Upload a local image or model to Tripo') plus the concrete artifact it returns ('a reusable file token'). The 'Rarely needed' framing effectively distinguishes it from the many processing siblings that accept paths directly.

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

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

Provides explicit when-NOT-to-use guidance: 'every input field already accepts local paths' tells the agent the default is to call the target tool directly rather than upload first. The condition that would justify this tool (needing a reusable token) is implied clearly.

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 a non-read-only, open-world, idempotent, non-destructive operation; the description adds concrete behavioral detail beyond that — progress notifications are emitted, outputs are written to the output directory, and a timeout yields done=false rather than an error. This last point is genuinely useful and consistent with idempotentHint=true. Failure behavior (what happens if the task errors) is not covered.

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, zero filler, with the core action (wait, then save outputs) leading and the timeout/retry contract second. Every clause carries information an agent needs.

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-value details need not be explained, and annotations cover the safety profile. The description supplies the blocking/waiting loop and output-saving semantics that the schema alone would not convey. Only the failure path of the awaited task is left unspecified, a minor gap.

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 are already documented in the schema, including download's default and timeout_seconds' default of 120 and max of 900. The description restates the timeout/re-call semantics and implies download's effect but adds no syntax or format detail beyond the schema. 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?

The description gives a specific verb (wait) plus the resource (Tripo task) and adds the side effect (saving outputs). It implicitly separates itself from polling siblings like get_task, but it never names the alternative that overlaps most, download_task, which also writes outputs. An agent can infer the difference, but it isn't 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?

It clearly states the timeout contract and the follow-up action: 'Returns with done=false if timeout_seconds passes first; call again to keep waiting.' This tells the agent how to operate the tool in a loop. It does not, however, say when to prefer this over get_task or download_task, so the alternative-selection guidance is missing.

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