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

Annotations already declare idempotentHint and openWorldHint, but the description adds the material facts those hints cannot convey: the call 'reserves credits' (a financial side effect) and 'Returns immediately', so the agent knows this is async. The retry-safety guidance operationalizes the idempotency hint rather than repeating 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?

Front-loaded with the action and its prerequisites, then retry semantics, then the async/credit warning. Dense but every clause carries operational meaning; 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?

No output schema exists, and the description never says what the call returns (e.g. a job identifier) or how to correlate the response with quady3d_get_job beyond 'query the same job'. Credit reservation and interrupt/reconnect handling are covered, but the return contract is left implicit for a mutation that spends money.

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 33% – only client_action_id is documented inline, so the description must compensate. It conveys that quote_id refers to a 'saved quote' and that max_credits is a spend ceiling ('within max_credits'), but gives no format, source tool, or behavior when the quote expires or the cap is exceeded.

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 a user-authorized generation ... using a saved quote and a ready project directory.' That clearly separates it from quady3d_quote (pricing) and quady3d_get_job (polling). The only friction is the name says 'job' while the description says 'generation', which an agent must reconcile.

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 reuse rule for interruptions ('Reuse the exact client_action_id, quote and limit... including when the directory needs reconnecting') and routes follow-up to 'query the same job'. It stops short of an explicit when-not-to-use or naming quady3d_get_job, but the context is 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?

Adds real behavior beyond the annotations: writes never overwrite an existing file, the target must be an existing allowed project directory, and download access controls still apply. It also discloses the return payload (actual path, size, locally computed SHA-256), which the annotations cannot convey. Only the exact failure behavior on a refused path/overwrite is left implicit.

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 sentences, each carrying a distinct load: what it does, the non-overwrite constraint, retry guidance, return values, and the generation exclusion. The core action is front-loaded with 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?

With no output schema, the description supplies return values (path, size, SHA-256) and the key failure mode (no replacement of existing files), which is exactly what an agent needs. Gaps are minor: no statement of what happens on a disallowed path or how idempotent retries interact with the no-overwrite rule.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It constrains target_path meaningfully (existing, allowed, non-overwriting) but says nothing about asset_id beyond 'owned result' — the required pattern and ownership precondition go unexplained.

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

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

Names a specific action on a specific resource: saving an owned result to an existing allowed project directory. The closing clause 'Does not generate' distinguishes it from the generation/job siblings (quady3d_create_job, quady3d_get_job) without needing the schema.

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

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

Explicitly scopes usage: 'Retry downloads independently of generation' and 'Does not generate' tell the agent when this tool applies and what it must not be used for. It stops short of naming a concrete alternative tool for generation, so it is clear but not fully 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 cover readOnly, idempotent, non-destructive and open-world, so the bar is lower. The description still adds real value by disclosing the authentication side effect ('Authenticates this connection before associating saved requests') and the cost profile ('No generation charge'), both of which are beyond what the annotations state.

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 first sentence is a dense, comma-spliced field list that is hard to scan, and the key operational cue (check before a new task) is buried second. It is not padded, but front-loading the 'read account state' purpose ahead of the field enumeration would improve 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?

There is no output schema, so the description's enumeration of returned fields (balance, download access, credit limits, readiness, recovery) appropriately compensates. Combined with the auth and cost notes, an agent has enough to call this correctly as a pre-flight check.

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 zero input parameters, there is nothing for the description to disambiguate; the baseline for a parameterless tool is a 4. Nothing about the description confuses the (empty) input contract.

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

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

Names a specific verb (read) and a concrete resource set — balance, download access, credit limits, workspace readiness, recovery — so the agent knows exactly what payload comes back. It distinguishes itself from siblings like quady3d_create_job or quady3d_get_job by being purely account-state oriented. The only shortfall is the slightly opaque internal field names (local_recovery across-key support) that a caller may not parse without the schema.

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

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

The line 'Check ready_for_new_generation before a new task' implies this tool precedes generation, which is useful. But it gives no explicit when-not guidance and never names a sibling alternative or prerequisite, leaving the agent to infer the pre-flight role.

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, so the description does not need to restate safety. It adds meaningful non-obvious context: the wait is bounded, a local timeout does not fail or cancel the cloud task, and it must not trigger a replacement generation. It stops short of describing what the query returns or how to interpret a pending job.

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 tightly written sentences, front-loaded with the main action and followed by the most important caveat. Every sentence earns its place; there is no repetition or 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 simple read-only tool with annotations covering safety and idempotency, the description covers the critical timeout caveat. But with no output schema, it leaves an agent without any indication of what a job query returns or how to interpret the result, and job_id remains unexplained.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It adds useful meaning for wait_seconds ('waiting up to 30 seconds') but says nothing about job_id—its required status, expected format, or where the ID comes from—leaving half the parameters without semantic guidance.

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

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

The description uses a specific verb ('Query') and object ('the original task'), making the retrieval intent clear. It does not explicitly distinguish itself from siblings like quady3d_list_jobs or quady3d_create_job, and 'original task' is slightly less precise than 'job', but the core purpose is understandable.

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 useful operational guidance: waiting is optional up to 30 seconds, and a local timeout must not be treated as a cloud-side failure or trigger a replacement generation. However, it does not state when to use this tool versus quady3d_list_jobs, quady3d_create_job, or other alternatives, so usage is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorld, so the safety profile is covered. The description usefully adds that listing incurs no charge and creates no work, which is real value beyond the annotations, but it says nothing about pagination behavior despite cursor/limit parameters.

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

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

Two short sentences, front-loaded with the resource and scope, with no filler. Efficient, though the second sentence could be phrased to also carry usage routing.

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?

The tool is simple (read-only list, no output schema), and the description establishes scope and the no-charge guarantee. But with zero schema descriptions and no output schema, an agent has no idea how results are paginated or what a returned job entry looks like, which is the main 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 0% with three parameters, so the description carries the burden and fails to do so: it never explains what limit, cursor, or the status enum do. The only enum is self-describing, but pagination semantics (page size cap of 100, cursor lifetime) are entirely absent.

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

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

States a specific verb (list) and resource (this account's API tasks), and the phrase 'for recovery' hints at the use case. It is distinguishable from create_job and get_job, though the wording 'tasks' vs the tool name's 'jobs' creates a small terminology mismatch an agent must reconcile.

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?

'for recovery' implies the scenario (recovering jobs when IDs are lost), and 'Does not generate or charge' implicitly contrasts with create_job. However, no sibling is named explicitly and there is no statement of when not to use this versus quady3d_get_job or quady3d_list_models.

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 that this is a read-only, idempotent, non-destructive, open-world operation. The description adds useful context beyond the annotations: it says there is no generation charge and warns that older APIs may omit parameter definitions, so defaults should be used rather than guessed.

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 compact and front-loaded with the core purpose. Each sentence adds a distinct piece of value: return contents, model selection guidance, omission caveat, and cost clarification.

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?

The description compensates for the lack of an output schema by explaining what model information is returned, and it covers key caveats. However, it omits any explanation of the only input parameter, leaving a meaningful gap for a tool whose schema description coverage is 0%.

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 sole parameter is an optional 'operation' enum with values 'text-to-3d' and 'image-to-3d', but the schema provides 0% description coverage and the tool description never mentions this parameter. It does not explain whether omitting it lists all models or what each enum value filters, leaving the schema's enum values to speak for themselves.

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 model availability, input limits, and parameter schemas. The phrase 'before quoting' hints at its relationship to quady3d_quote, but it does not explicitly name or distinguish other sibling tools such as create_job or get_job.

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

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

It gives clear usage context: select an explicit available model and respect its parameter definitions before quoting. It also advises using defaults when older APIs omit definitions. However, it does not explicitly state when not to use this tool or name a direct alternative.

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/idempotent/non-destructive, and the description adds genuinely non-obvious behavior: no charge is incurred, connection-scoped input is persisted for a later create_job call, and the quote has a 5-minute TTL. There is mild tension between 'readOnlyHint: true' and the stated persistence of input state, but it reads as a non-mutating quote record rather than a real 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?

Three short sentences, front-loaded with the core action, and every clause adds distinct information (cost, downstream use, expiry). 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?

With no output schema, the description should say what a quote returns (a price, a quote identifier, expiry token) and how create_job consumes it; it only says the input is saved for the same connection. The cost/expiry lifecycle is covered, but the return shape and handoff mechanism are left implicit.

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 reported at 100%, so the schema carries the parameter burden and baseline 3 applies. The description adds no meaning about `model`, the free-form `parameters` passthrough, or the `upl_...` upload_id requirement for the image-to-3d branch, all of which an agent must infer from the schema alone.

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

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

Names a specific verb and resource (quote a text or single-image 3D generation) and explicitly contrasts with the charging path by saying 'without charging' and pointing at create_job. An agent can distinguish it from quady3d_create_job, though it never states the two operations map to the text-to-3d and image-to-3d branches of 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?

'Saves this connection's input for create_job' plus the five-minute expiry clearly signals the intended workflow: quote first, then create. It does not state any explicit when-not or what happens if the quote is not consumed, so it falls short of full routing guidance.

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

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

Annotations already declare non-read-only, non-idempotent, open-world and non-destructive, and the description adds real value beyond them: the 8 MiB cap, the three accepted formats, the allowed-project-root restriction, the absence of a generation charge, and the 30-minute expiry. What it omits is the consequence of the temporary upload (what handle comes back and whether it must be consumed before expiry).

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

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

Two dense sentences, zero filler, with the file-type and size constraints front-loaded and the cost/expiry facts second. 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 one-parameter upload tool with no output schema, the description covers constraints, cost and lifetime well. The remaining gap is the return value — since no output schema exists, the agent has no way to know whether it receives an upload token, URL or ID to feed into quady3d_create_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?

The single parameter has 0% schema description coverage, so the description must carry the load. It does add meaning — the value must point at an allowed project root and must resolve to PNG/JPG/WebP under 8 MiB — but it never states whether file_path is absolute or relative, or what constitutes an 'allowed project root', leaving format ambiguity.

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 ('Upload') plus the exact resource (one PNG, JPG or WebP file) and its constraints, so an agent can tell this apart from quady3d_download_asset or quady3d_create_job. It never names a sibling or explains the relationship (e.g. that an upload must precede job creation), so it stops short of full 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?

'One explicitly selected' hints that the file must come from the user rather than being generated, and 'from an allowed project root' implies a precondition. But there is no explicit when-to-use/when-not, no mention of alternatives such as quady3d_download_asset, and no statement of what to do if the file is rejected. Usage is implied rather than instructed.

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