AI3D Studio

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

Goes well beyond the annotations: states it is free/creditless, answered synchronously, non-destructive (files the result as a NEW creation made from the source), and reinforces idempotency with 'the same conversion run twice returns the same creation'. Format-specific behaviors (units, axis orientation, material retention) and the 200k-triangle repair ceiling are disclosed.

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

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

Front-loads the core capability and keeps every clause informative (formats, limits, idempotency, unit conventions). It is a dense single block rather than scannable structure, which slightly hurts readability but 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 a 10-parameter conversion tool with an output schema present, the description covers inputs sources, format semantics, constraints, cost, idempotency, and destructive-vs-additive behavior. Nothing an agent needs to call it 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 already 80%, so the baseline is 3, but the description adds real semantics beyond the schema: STL/3MF are millimetres and Z-up for slicers, OBJ/PLY are geometry-only in metres, GLB keeps materials/textures and supports meshopt. It also clarifies repair applicability and the simplify-before-repair interaction.

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/compress/repair) and resource (Library 3D model GLB) with the full set of output formats, and names sibling routes (get_job, search_library) for the input asset. An agent can distinguish this from generate_3d or list_models 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?

Explicitly tells the agent where to obtain asset_id (get_job or search_library, a finished 3D job file) and lists refusal conditions (>50 MB, >2,000,000 triangles, Draco GLBs). It does not explicitly contrast itself against siblings like generate_3d beyond naming input sources, so it falls short of full when/when-not routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, and the description usefully reinforces this with "Nothing is charged and nothing is started." More valuable is the disclosure that it runs the same validation as the real generation calls, so invalid requests fail rather than return a partial estimate, and that a valid request's figure is exactly what gets charged. It doesn't cover error shapes or whether pricing can drift between estimate and execution.

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 what the tool returns, followed by accuracy guarantees and the no-side-effects statement. Every sentence adds a distinct fact with no repetition of 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?

An output schema exists, so return shape needn't be spelled out, and the description still summarizes the two fields an agent cares about. For a read-only, four-parameter tool with a nested options object, the description covers purpose, accuracy semantics, side-effect status and the scene-omission behavior without leaving anything an agent needs unresolved.

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

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

Schema coverage is 75%, so the baseline is 3, but the description adds genuine meaning: omitting scene prices every scene of the model, a multi-value behavior the schema does not convey. It also frames options explicitly as the options the caller intends to pass and notes they change the price. The prompt parameter is undocumented in both the schema and the description, which is the remaining gap.

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

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

The description opens with a specific verb-and-resource pair ("Price a generation") and immediately defines the two return values: the credit charge for these options and whether the balance covers it. It also distinguishes itself from the siblings generate_3d and generate by explaining that it shares their validation and price calculation but does not start anything.

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

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

It clearly states the pre-flight context ("before starting it") and points to the sibling tools whose pricing it mirrors, so an agent knows to call this before generate/generate_3d. It also gives a usage rule for an optional parameter ("Omit scene to price every scene of the model"). It stops short of explicit when-not-to-use guidance, for example telling the agent to call get_balance instead for a pure balance check.

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 description adds real behavioral context beyond the annotations: it bills credits, the call is async and returns a job id, retries with the same idempotencyKey replay the original job instead of double-billing, and a price_changed error starts nothing. Note that idempotentHint=false is not contradicted — the description explains that idempotency is opt-in via idempotencyKey, which reconciles with the annotation. What remains unstated is what a started-but-failed job means for credits and what the response envelope contains.

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

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

The core purpose, the sibling routing, and the billing/idempotency warnings are front-loaded, and the preset paragraph is genuinely necessary detail. The preset clause is a dense, comma-chained run-on that costs some readability, but no sentence is filler.

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

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

For a mutating, credit-billing, async tool with 8 parameters and a nested options object, the description covers routing, required call shape, cost safety, retry safety, and the next step. An output schema exists, so the absence of return-value detail is not a 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?

With only 50% schema description coverage, the description carries real weight: it defines mediaType values ('image'), scene ('image-to-image'), the options.image ordering (picture, or subject then reference), options.preset/preset_addons/preset_background, and the narrowed meaning of prompt when a preset is used. It also explains idempotencyKey and the price_changed behavior of expectedCredits. model and workflowType are left implicit, which is the main gap.

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

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

States a specific verb and resource ('Start an async AI generation of any media type') plus the concrete return ('return its job id'), and explicitly differentiates from the sibling generate_3d for 3D work. An agent can distinguish it from generate_3d, estimate_cost, and start_batch 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 routing: consult list_models for the input shape, prefer generate_3d for 3D, call estimate_cost before this to check price, and call get_job afterwards. It also spells out the exact call shape for the image-preset case, so when-to-use is fully resolved rather than 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?

Beyond the annotations, it discloses that the call spends credits, that credits are only committed after a successful start, that a stale price aborts with a price_changed error and nothing is charged, and that idempotency_key prevents double billing. That is exactly the cost/irreversibility context an agent needs before firing a mutating, credit-consuming request. The lack of inherent idempotency (idempotentHint=false) is consistent with the guidance to supply a key rather than a contradiction.

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

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

Purpose and immediate return value are front-loaded, followed by mode semantics, then prerequisites, then the safety rule and the follow-up call. Every sentence carries operational information and none 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?

For a credit-spending, asynchronous, nested-options tool with 6 parameters, the description covers input interpretation, cost verification, retry safety, error behavior, and the polling hand-off to get_job. With an output schema present, it does not need to describe the returned job id further.

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 83%, so the baseline is 3; the description earns above that by explaining the semantic of each mode value and by tying expected_credits to the estimate_cost/price_changed flow. It still leaves the shape of `options` to list_models rather than describing any common fields, so it does not fully compensate for the remaining gap.

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

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

States a specific verb and resource plus the async contract: 'Start a 3D generation and return its job id at once.' It also enumerates what each mode consumes (text prompt, image URL, view images, sketch, existing model), so an agent knows exactly what the tool produces. It does not differentiate itself from the sibling `generate` tool, which prevents a clean 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?

Gives an explicit sequence: pick a model id and option names from list_models, price it with estimate_cost, then call get_job to follow progress. It also states a conditional rule for retries (pass a stable idempotency_key) and warns that this call spends credits, so prerequisites and hand-offs are all spelled out.

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, idempotentHint, and destructiveHint=false, and the description's closing 'Read-only' merely restates that. The only added behavioral nuance is that the monthly-limit fields appear conditionally when connected via a rate-limited API key, which is helpful but largely a return-value detail the output schema already covers.

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 leads with the primary value (spendable credits) before the optional details. It is dense with parenthetical asides but every clause describes a real returned field, so little 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 no parameters, a full output schema, and complete annotations, the description needs only to frame what the call answers, which it does, including the conditional API-key branch. Slightly more guidance on when an agent should reach for it would make it fully sufficient.

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; the baseline of 4 applies. It correctly signals a no-argument call by not introducing any input concepts.

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

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

The description uses a specific verb ('Get') and a well-defined resource (spendable credits, their subscription/permanent split, plan name, and API-key monthly limit with usage and reset). This clearly separates it from cost-forecasting siblings like estimate_cost, though no sibling is named explicitly.

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

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

Usage is only implied: an agent can infer this is a pre-flight check for available credits, but the description never says when to call it versus estimate_cost or what happens if the balance is zero. 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?

Annotations already establish read-only, idempotent, non-destructive behavior, and the description builds on that by disclosing content an agent would otherwise have to discover: per-picture statuses, the job_id linkage once a run starts, credits charged, and whether a retry is possible. No auth, rate-limit, or error behavior is described, which keeps it from a 5.

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

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

A single dense sentence, front-loaded with the resource state and then the useful extras. The enumerated status list is long but earns its space by telling the agent exactly what values to expect.

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 enumerate return values, yet it does so usefully and ties them to sibling tools. It omits only edge behavior such as what happens for an unknown or not-yet-started batch.

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, and the schema already explains that batch_id is the value start_batch returned. The description adds nothing beyond that, 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?

Names the resource (a batch) and precisely scopes what is returned: batch state plus per-picture state, with the full status vocabulary spelled out. It also distinguishes itself from get_job by noting that get_job is where the files live, so an agent can separate the two 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?

Placement in the workflow is clear from the mentions of start_batch's id, get_job for files, and retry_batch for re-runs, which implicitly define this as the polling/progress-inspection step. There is no explicit when-not or prerequisite statement, but the routing hints are strong.

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, and closed-world, so the safety profile is covered. The description adds real behavioral detail beyond that: the polling cadence, the terminal-state stop condition, and the fact that credits can be refunded and that alternate format files may be included. Since an output schema exists, the return-value enumeration is partly redundant, keeping this at a 4 rather than 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?

Two sentences, both front-loaded: the first says what comes back, the second says how to poll and when to stop. No filler, and the operational instruction is placed where an agent driving the call will read 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?

With a single required param and a full output schema, the remaining agent-facing unknowns are polling behavior and termination, and the description covers both explicitly along with the credits/refund nuance. Nothing needed to call this correctly 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?

With one parameter at 100% schema coverage, the baseline is 4. The description adds a small amount of provenance ('started by generate_3d or generate'), which matches the schema's own wording, so it neither compensates for a gap nor adds much new syntax detail.

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

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

The description opens with a specific verb+resource ('Get a job') and immediately ties it to the producing siblings (generate_3d, generate), then enumerates what comes back: status, progress, credits charged/refunded, and result file URLs. That is enough for an agent to distinguish get_job from list_job_files or get_batch 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?

It gives concrete operational guidance — poll every 5–10 seconds while status is pending/processing, and stop when is_terminal is true — which is exactly the when-to-use context an agent needs. It does not explicitly name alternatives (e.g. list_job_files for just file listing), 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 cover the safety profile (readOnly, idempotent, openWorld=false, non-destructive), and the description adds real behavioral facts beyond them: results are limited to the last 24 hours, sorted newest first, and include per-picture progress plus a plan allowance where 0 means batches are unavailable. Those are non-obvious traits an agent would otherwise only discover at runtime.

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 sentence, front-loaded with the resource and scope, with no wasted wording. The trailing parenthetical about allowance is slightly crammed but carries genuinely useful semantics rather than 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-shape explanation is optional, and the description still usefully flags progress and allowance fields plus the allowance=0 edge case. What's missing is an explanation of how the two input parameters behave (especially limit's cap of 10) in this lightly annotated-by-schema definition.

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

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

Schema description coverage is 0%, so the description must compensate and does not fully. It implies the 'scene' parameter through 'batches of one scene' but never explains what a scene identifier is or its format, and the 'limit' parameter (max 10) is not mentioned at all despite governing the 24-hour result set.

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

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

The description names the resource (batches), the scope (one scene, last 24 hours) and the ordering (newest first), which is enough for an agent to know exactly what it returns. It never names a sibling like get_batch (single batch) or list_job_files, so differentiation is implicit rather than stated.

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

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

There is no guidance on when to call this versus get_batch, start_batch or list_job_files, and no exclusions. The 24-hour/one-scene scope hints at applicability but the agent must infer it from a description of return content, not from explicit usage instructions.

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 establish read-only, idempotent, non-destructive behavior; the description adds meaningful context beyond that by noting the job must be finished, that each format has a public download URL, and that the tool does not perform conversion. Those are behavioral constraints an agent needs before calling it.

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

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

The description is front-loaded with the core purpose, then adds the format filter behavior and the non-conversion caveat. The sentences are dense but purposeful, 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?

Given the rich annotations, the output schema, and full input schema coverage, the description provides everything an agent needs: what the tool returns conceptually, how format is used, and where to go for conversion. No material gaps remain.

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 operational meaning to format: it is a lookup filter rather than a conversion request, and if it is unavailable the response's available_formats field explains what exists. That goes beyond the schema's short format example.

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: it lists files a finished job already has, one per format, with public download URLs. It also distinguishes the tool from conversion by explicitly saying it does not convert, which separates it from convert_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 explains when to use the format parameter to target one format, what happens when the requested format is absent via available_formats, and redirects conversion/export needs to the web app model viewer. This gives clear usage boundaries and alternatives.

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, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds genuinely behavioral context beyond that: results are grouped by media type, credits shown are at default options (so not an exact price), and an account with Image Maker gets extra presets. It stops short of covering the available_only filtering behavior or pagination/size limits beyond the include_inputs cost warning.

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 the follow-up call, and every sentence carries distinct information. It is dense with parentheticals and run-on clauses ('presets: ready-made picture conversions (figurine, style, pose, …)'), which costs some readability but no sentence is filler.

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

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

Given an output schema and full annotation coverage, the description supplies exactly the missing operational context: when to call it relative to estimate_cost, what conditional sections (presets, batches) may appear, and the size tradeoff of include_inputs. Nothing needed to invoke it correctly 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 coverage is 100%, so the baseline is 3. The description does add real meaning for include_inputs ('the option fields of each scene (names, allowed values, ranges)') beyond the schema's terse 'larger result', but it says nothing about media_type or available_only semantics, leaving those to 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?

States a specific verb and resource ('List the models this account can generate with') plus the grouping and per-item payload (id, scenes, credits). It is clearly distinguishable from siblings like estimate_cost, get_balance, or list_batches, and even explains what the extra 'batches' and 'presets' sections mean.

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 sequencing: 'Call this first to choose a model id, then estimate_cost for an exact price.' It also names the downstream consumers — generate with options.preset, and start_batch via the batches section — so the agent knows both when to call this and what to do with the result.

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 important side-effect context beyond annotations: retries are charged as they start, the balance must cover them, and they count against a monthly limit. With annotations already covering mutability and idempotency, this is strong transparency, though it does not discuss permission or error 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-loads the action, then adds the critical billing and quota constraints. Two sentences with no wasted text; both earn their 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?

Given an output schema, annotations, and only two parameters, the description is mostly complete: it explains scope, optional filtering, cost, and quota impact. Minor gaps remain around item-level edge cases, but nothing essential to invoking it 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 50%; batch_id is documented in the schema and item_ids is not. The description clarifies that item_ids limits the retry to specific items, which compensates somewhat, but it does not add details such as the 100-item cap or item validity requirements.

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: queue the batch’s failed pictures again as new runs, with an optional item_ids filter. It is clear what the tool does, though it does not explicitly name start_batch or contrast itself with creating a fresh batch.

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

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

The description gives a clear usage context: retry failed pictures or items stopped for lack of credits. It does not provide explicit exclusions or name alternatives, but the intended situation is evident.

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 and closed-world, so the safety profile is covered. The description adds genuine value beyond that: result ordering (newest first), account scoping, the returned fields (job id, model, status, result file URLs), and cursor-based paging via next_cursor.

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 compact sentences, front-loaded with what is searched and in what order, then return shape, paging and the sibling hand-off. 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?

Read-only search with a full output schema and complete annotation coverage; the description supplies scope, ordering, paging and the escalation path to get_job. Nothing needed to call it 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 still adds useful framing by saying the query matches words in the prompt or title and that media_type selects a kind of run. Note a small naming drift: the prose says next_cursor while the parameter is cursor.

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 (search) plus a precisely scoped resource (the Library of past generations kept by this account), with ordering stated (newest first). It is clearly separable from get_job, which is named as the per-run detail tool.

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 get_job as the alternative for full detail of a single run, and clarifies the scoping constraint that only this account's runs are searched. Lacks an explicit 'when not to use' clause (e.g. browse without query vs. query), but the routing 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?

Goes far beyond the annotations with a detailed charge model: nothing charged at creation, each run charged as it starts and refunded on failure, the full quote must be covered by balance, and monthly-limit keys hold the whole quote until each item runs or is cancelled/refused. Also discloses that a batch id is returned immediately and that idempotency_key makes retries safe, which is exactly the kind of context idempotentHint=false 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-loaded with the action and an example, then prerequisites, then cost behavior, then follow-up — a sensible ordering. The charging sentence is long and clause-heavy, and a bulleted cost/idempotency split would read faster, but nothing is wasted.

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

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

For a nested-array, 9-param, mutating tool this covers the hard parts: item limits, value sourcing, async follow-up, billing holds and retry safety, and an output schema means return shape needn't be spelled out. The unmentioned prompt and project_id leave a small but real hole.

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 only 33% schema coverage across 9 params, the description compensates well: it explains where model/scene values come from, that items are per-picture asset_ids, that options are shared across runs with the picture field filled per item, and what idempotency_key and the quoted price do. Gaps remain for prompt, project_id and notify_by_email, which are undocumented in both schema and description.

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

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

States a specific verb and resource ('Run the same model, scene and options once for each of several pictures') and grounds it with a concrete example ('image to 3D for twelve product photos'). This makes the fan-out semantics immediately distinguishable from the single-run 'generate'/'generate_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?

Gives explicit prerequisite routing: scenes and models come from list_models (`batches`), asset_ids from get_job or search_library on a finished image job, and the result is followed with get_batch. It never names 'generate' as the single-picture alternative, so the when-not-to-use case is implied rather than 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 behavioral context beyond the annotations: the result is only complete after the job finishes, and the payload includes a viewer-usable model URL and download links. 'Read-only' largely restates readOnlyHint=true, but the lifecycle timing ('once it has finished') is genuinely useful and not in the 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-loads the ownership constraint and the return contents in one tight sentence, then closes with the routing note. Dense but every clause carries information; only the 'Read-only' clause is slightly redundant with the 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?

For a single-parameter read tool with a full output schema and complete annotations, the description covers who calls it, when it is meaningful, what it returns at a high level, and the preferred alternative. Nothing an agent needs in order to call it 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?

There is a single parameter and schema coverage is 100%, with the schema already explaining that job_id comes from generate_3d. The description adds no further semantics about the id, so this sits at the baseline where 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 precisely what the tool yields: the state of a single job and, once finished, the model file URL the viewer draws plus download links. It also names its consumer (the interactive 3D viewer) and explicitly distinguishes itself from get_job, so 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 an explicit when-not-to-use ('not for direct use', 'the conversation never needs to call it') and names the alternative that supplies the same facts ('get_job gives the same facts as text'). No inference is required about whether the agent should select this tool.

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