3D Valley

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds the credit unit conversion (1 credit = $0.01) and clarifies that the spending cap is key-specific, both of which are useful behavioral context beyond 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?

It is a single compact sentence listing the returned data points plus a short usage directive. Nothing is wasted, though the noun-phrase opening is slightly less front-loaded than a verb-first description would be.

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 zero-parameter, read-only, informational tool with an output schema, the description covers all the relevant return categories and tells the agent when to call it. 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?

The tool takes no parameters and the schema is empty, so there is no parameter semantics to explain. The baseline score of 4 therefore 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 enumerates exactly what the tool returns: credit balance, per-tool/model prices with a credit-to-dollar conversion, rate limits, and this key's daily spending cap. That is specific enough to distinguish it from the action-oriented siblings such as generate_model and upload_file, though the name 'account' alone is generic.

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

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

It gives a clear directive — 'Check before spending' — which tells the agent when this tool is relevant. It does not name an alternative or explicitly state when not to use it, but for a zero-parameter informational tool that is a minor omission.

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

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

Goes well beyond the annotations by disclosing per-model credit costs (5/10/20/40 for texturing, 50 for remesh) and the async pattern: waits ~45 s then returns job_id for get_job. That is exactly the kind of cost and latency context annotations cannot express. It stops short of explaining failure behavior, what max_credits does when exceeded, or how wait_seconds interacts with the stated 45 s wait.

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 scope is front-loaded in the first clause, and the credit table and chaining note follow in priority order. The parenthetical credit lists are dense but each parenthetical carries real information; no sentence is pure filler.

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

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

For an async, open-world generation tool with an output schema, it covers cost, input forms, wait duration and the follow-up call, which is most of what an agent needs. The remaining gap is the mesh-vs-model parameter ambiguity in a 9-parameter, nested-object schema.

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

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

With 56% schema coverage the description must compensate, and it partially does by clarifying that mesh accepts a URL, upload_file id, library id or job id, reinforcing chaining. However it never resolves the confusing overlap between 'mesh' and 'model' (both described as the model), and leaves max_credits and idempotency_key entirely unaddressed in the text.

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 ('Change a model you have') and immediately enumerates the two operations, retexture and remesh, with the concrete models that back each. This makes it distinguishable at a glance from generate_model and generate_texture, which create rather than modify.

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 scopes usage to models you already have and names an exclusion: 'To reduce, compress, convert or repair a file, use gltf-transform or Blender locally.' It also states the input forms so steps chain without downloading, and points to get_job for 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?

Annotations only declare the safety/idempotency profile; the description adds the material behavior an agent needs: per-model credit prices, refusal via max_credits, a ~45 s wait that returns job_id for get_job, same-arguments resumption with no double charge, and the GLB orientation at the origin. That goes well beyond what readOnlyHint/idempotentHint 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 purpose and scope, then costs, then sizing guidance, then job behavior — a sensible order. It is dense and semicolon-heavy, and the inline price list adds bulk, but nearly every clause carries information an agent would otherwise have to guess.

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

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

For a 10-parameter generative tool with an output schema, the description covers cost, latency, resumption, sizing, and orientation. Gaps are small: no statement about what happens if both image and prompt are supplied, and no mention of behavior when credits are exhausted or max_credits rejects the job.

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 80%, so the baseline is 3; the description earns above that by attaching prices to model names, explaining max_credits as a spend guard, and clarifying idempotency_key's exact purpose (a second, different job). It still doesn't explain seed or wait_seconds semantics beyond 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 ("make one 3D object ... as a textured GLB") and scopes it explicitly ("never a scene") with the two input modes named. This separates it cleanly from generate_texture, edit_model, and search_assets without opening any schema.

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

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

Gives clear conditional guidance: image for pictures, prompt for descriptions, max_faces and style=lowpoly for game/web low-poly kits, max_credits to cap spend, new idempotency_key only to force a second job. What's missing is explicit routing to siblings (e.g. edit_model for changing an existing model, generate_texture for textures only) and whether image and prompt can be combined.

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=false, openWorldHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: what artifacts are produced and the per-model credit cost. It does not explain the asynchronous/job nature implied by the 45-second `wait_seconds` default or what happens when `max_credits` is exhausted.

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

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

It is a single front-loaded sentence with no filler, which is good. But the trailing pricing clause ('for flux-2-klein-material 2, muse-image-material 5, gpt-image-2-5-material 8 credits') is hard to parse and forces the reader to reconstruct the model-to-credit mapping.

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 costly, likely asynchronous generative tool with an output schema present (so returns need not be described), the description omits the operational essentials: that generation may exceed the wait window and how to follow up (sibling get_job exists), and what failure/credit-exhaustion looks like. Only the output contents and pricing are 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 only 33% (model and prompt only), so the description must compensate, and it partially does by mapping model names to credit costs, which informs both `model` and `max_credits`. However, `seed`, `wait_seconds` (oddly capped at 50 with default 45) and `idempotency_key` remain completely unexplained in both places.

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

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

States a specific verb+resource: generates a seamless PBR texture set from a description, and enumerates the exact output channels (base colour, normal, height, roughness, metallic) at 2048 px. That is far more concrete than the sibling 'generate_model', though the description never explicitly says how it differs from generate_model or edit_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?

There is no when-to-use / when-not-to-use guidance and no mention of alternatives such as generate_model. The only routing signal is implicit in 'from a description', leaving the agent to infer when a texture rather than a model is wanted.

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 openWorldHint=false, so the safety profile is covered; the description nonetheless contributes the licensing/cost fact ('free') and an obligation attached to the returned data (credit line must be reproduced in READMEs). The trailing 'Read-only' partly restates the annotation, and there is no mention of behavior for an unknown or stale id, which keeps this below 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?

Two sentences, front-loaded with the payload content and then the practical credit-line instruction — nothing is buried. The long mid-sentence enumeration of returned fields is dense and marginally overlaps the output schema, and the closing 'Read-only, free' is a partially redundant tail.

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, enumerating return fields is not strictly required, and parameters are fully documented, so the description is adequate. What it does not address is the one behavior an agent must handle: what happens when an id does not resolve (error vs empty result), which matters for a lookup that is typically called in a loop over search hits.

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 at 100% schema coverage, and the schema already explains its format and provenance ('an asset id from search_assets, e.g. "ph:wooden_barrel_01"'). The description adds no further meaning about id, so the baseline 3 for a fully documented single parameter 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 states a specific verb and resource ('Full details for one library asset') and then enumerates exactly what that detail set contains: per-format download URLs, size in metres, up axis and origin, texture maps, credit line, related assets, import notes. That enumeration plus the singular 'one asset' clearly separates it from the sibling search_assets, which finds assets rather than returning a single record.

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 context is clear: this is the fetch-detail step taken once you have an id, and the description adds a concrete downstream instruction ('when you write credits or a README... include its credit line'). It stops short of an explicit when-not or a named alternative, though the schema's pointer to 'an asset id from search_assets' covers the routing gap.

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 openWorldHint=false, so safety of repetition is partly covered; the description nonetheless adds real value with the ~45 s bound and "never charges", a billing guarantee nothing in the structured fields conveys. It does not say what a timed-out or failed job looks like on return, which would be the remaining behavioral gap.

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

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

Three clauses in roughly two sentences: what it does, how safe it is to repeat, and what comes back — front-loaded with the primary purpose and with no filler. Every phrase carries information an agent would otherwise have to guess.

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

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

With an output schema present, the description need not enumerate return fields, and it still summarizes them usefully (download URLs, preview, size in metres, triangle count, asset id) while covering timeout and cost behavior. What remains missing is the non-success path — what is returned or raised when the wait expires or the job errors.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it only partly does: "up to about 45 s" gestures at wait_seconds and its default, but never says it is caller-configurable (0–50, minimum 0) or that wait_seconds=0 means a pure non-blocking status read. job_id is left entirely implicit.

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?

"Waits up to about 45 s for a job to finish, or reads where it stands" gives a specific verb (wait/read) and resource (job) plus the two modes of operation, so an agent immediately understands this is a status/polling tool. It does not explicitly name a sibling (generate_model, get_asset) to contrast with, which keeps it short of a 5.

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

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

"Safe to call again and again" and "usable as input to the next step" spell out the intended polling loop and downstream handoff, which is the core usage context for a job tool. It stops short of naming what to do instead when the job never finishes (or of pointing to get_asset once an id exists), so 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?

Beyond the readOnlyHint/idempotentHint/openWorldHint annotations, it discloses asset conventions (GLB, metres, +Y up, origin at base), the match-confidence scale (strong/good/weak) and the degraded-result signal, and the cost/licensing context (free with a free account). These are traits an agent cannot infer from the annotations or 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?

The description is front-loaded, with the verb and resource in the first clause and practical gotchas following in descending priority. It is dense but nearly every sentence carries a distinct call-time decision; the licence sentence at the end is the weakest performer.

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 20-parameter, zero-required search tool with an output schema present, the description covers the decisions that matter most (semantic querying, size filtering, previews, weak-match fallback). Fine-grained filter interactions such as maps+format+source combinations are left to the per-parameter schema entries, which is reasonable.

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 moderate (65%) over 20 parameters, yet the description supplies the operational meaning several schema entries lack: it explains previews' max-6 cost tradeoff, the purpose of min_size_m with a concrete threshold, and derives the size_m convention that makes the size filters meaningful. That genuinely compensates for the coverage gap rather than restating the schema.

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

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

The description names a specific verb (search) and the exact resource set (CC0 3D models, PBR textures, HDRIs) plus the two mechanisms, semantic meaning and filters. It is immediately distinguishable from generate_model, get_asset and generate_texture among the siblings.

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 when-to-call guidance (check size_m before placing, min_size_m >= 2 for floors and walls, previews are cheaper than downloading the wrong asset) and an explicit fallback: when no result beats 'weak', use generate_model instead. That is both a routing rule and an exclusion.

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

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

Annotations only say it is a non-read-only, non-destructive, non-idempotent write, which is thin for such an unusual tool. The description supplies the context annotations cannot: the server has no disk access, the call is a two-phase handshake rather than the transfer itself, and uploads expire after 24 hours.

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, each carrying distinct information, with the blocking constraint front-loaded so an agent cannot misread this as a normal file-upload call. No filler or restatement of the title.

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

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

An output schema exists, so return values need not be enumerated, yet the description still flags the two useful return elements (upload id and ready-to-run command) that drive the next step. For a two-phase tool this covers everything an agent needs to avoid a failed call.

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

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

Schema coverage is 67% and the two required parameters (filename, bytes) are already well documented in the schema. The description adds only a loose hint about accepted file kinds ('a mesh or picture') and says nothing about content_type, the one undocumented parameter, or why the byte size must be supplied when the file never reaches the server directly.

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 and non-obvious mechanism: it does not transfer the file itself, it returns an upload id plus an exact curl command the agent must run. Naming the constraint ('The server cannot read the user's disk') immediately separates it from generate_model and other siblings that consume assets.

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 the full sequencing: call this, run the returned curl command, then pass the id as the image or mesh of another tool. That is clear when-to-use guidance. It stops short of naming which sibling to pass the id to (generate_model vs generate_texture vs edit_model) or what to do if a 24-hour upload expires.

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