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

Annotations already flag this as a non-read-only, destructive operation. The description adds genuine behavioral value beyond them: cancelling is non-destructive to the user's credits because 'its credits are refunded', which tells the agent the cost impact of the action.

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

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

A single sentence with the action front-loaded and the refund consequence attached via a semicolon. Nothing wasted, nothing missing.

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 cancel operation, the description plus destructive annotations cover the essentials, and the refund note closes the main cost uncertainty. The only gap is the lack of any statement about what the call returns or confirming the post-state of the generation.

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?

One required parameter with 0% schema description coverage, so the schema explains nothing about generation_id. The description only implies it identifies the 'running generation'; it adds no format, source, or constraints beyond that implication.

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 ('Cancel a running generation') with no ambiguity, and 'running' scopes which generations are eligible. No sibling offers cancellation, so the agent can distinguish it immediately from the generate_*/get_*/list_* family.

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 word 'running' implies the tool applies only to in-progress generations, which is implied usage guidance. However, there is no explicit statement of when not to use it (e.g. already-finished or failed generations) and no named 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?

readOnlyHint=true is consistent, and rather than restating it the description explains the practical consequence: the tool never pays and never touches payment details, so settlement happens out-of-band by the user. It also tells the agent the returned domain and the post-condition to verify. Link expiry or reuse rules are not covered.

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

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

Three short sentences, front-loaded with what is returned and immediately followed by the key behavioral constraint. Every sentence carries information; none 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 simple two-parameter, no-output-schema tool, it covers the return value, the responsibility split, and the follow-up verification well. The remaining gap is parameter-level guidance for choosing a bundle and the currency default.

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 carries the burden but adds only 'credit pack' as a gloss for bundle. currency is never mentioned, and nothing explains tier selection or defaulting behavior. The enums supply valid values but no meaning, leaving a real 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: returns a checkout link where the user buys a credit pack. It distinguishes the tool's action (returns a link) from the user's action (buys and pays), which is valuable. It doesn't explicitly contrast with the nearby sibling list_credit_packs, keeping it just 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?

Gives clear flow guidance: hand the link to the user, then check get_balance. That names a sibling and a follow-up step. It stops short of a 5 because it never states when to choose this over list_credit_packs or what prerequisites exist for generating a link.

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

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

Adds substantial context beyond the annotations: the signing/expiry window (~30 minutes), the one-time billing model with permanent library ownership, the price-acceptance gate on max_credits, and the connected-account requirement. This is consistent with idempotentHint=true (charge occurs only once) and explains why readOnlyHint is false, so there is no 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 compact sentences with the core purpose front-loaded, followed by billing conditions. The parenthetical asides are informative rather than wasteful, though the density of pricing detail in the middle sentence slightly blurs emphasis.

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 three-parameter tool with no output schema, it covers the essentials: what is returned (signed URLs), how long they last, the cost model, the required auth, and the gating condition on max_credits. It omits error/edge behavior such as what happens when a resolution is unavailable or when credits are insufficient, but nothing critical for calling 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 67%, and the description supplements the schema by explaining the workflow for max_credits — pass it only after the user accepted the price — which is usage timing the schema does not convey. resolution is left to the schema's own description, so it adds meaning where it matters but not exhaustively.

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

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

States a specific verb and resource — 'Get signed download URLs for an asset' — with the concrete payoff (a URL valid ~30 minutes). This clearly distinguishes it from siblings like get_asset (metadata) and save_generation_to_library, since it describes retrieval of a downloadable file rather than a 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?

Gives concrete conditional guidance: free CC0 assets cost nothing, AI assets charge once and then become free in the user's library, and max_credits should be passed only after the user accepted the price. It also states the prerequisite of a connected account. It does not name sibling alternatives (e.g. get_asset for previewing metadata), so it stops short of explicit 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 cover the safety profile (readOnly=false, destructive=false, idempotent=true, openWorld=true), and the description adds real value on top: async lifecycle, the polling requirement, credit spend with automatic refund on failure, and expected duration. It does not, however, explain credit cost magnitudes or any rate limits.

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 what is produced, then async/credit/timing facts in short, dense clauses; every sentence carries information. The telegraphic fragment style ('Realistic or stylized skies, interiors, landscapes.') is efficient but slightly choppy.

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 the missing return contract (generation id), the required follow-up call (get_generation), cost behavior including refunds, and timing. Together with the fully documented 6-parameter schema, an agent has everything needed to invoke and follow through correctly.

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

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

Schema description coverage is 100%, so the schema already documents seed, prompt, resolution, max_credits, idempotency_key and save_to_library. The description only reiterates the credit spend, adding no format or syntax detail beyond the schema — the baseline 3 for a fully-covered 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 ('360-degree equirectangular HDRI panorama / skybox from a text prompt'), plus the outputs produced (true HDR .hdr plus LDR preview). This clearly separates it from siblings like generate_texture and generate_pbr_material without needing their schemas.

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

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

Gives clear operational context: asynchronous, returns a generation id, poll get_generation, credits spent and refunded on failure, ~150 s runtime. It names the follow-up sibling explicitly but never states when to choose an HDRI over the other generators, so selection guidance is implied rather than 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 provide readOnlyHint=false, idempotentHint=true, destructiveHint=false. Description adds valuable context beyond annotations: asynchronous operation, credit cost and automatic refunds, typical duration, and precise tiling behavior. Does not contradict 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 core purpose, outputs, and key behavioral traits. Efficient, with no redundant sentences. Slightly dense but all information earns its place.

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

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

For a complex async generation tool with 9 parameters and no output schema, description covers asynchronous nature, credit refunds, timing, and outputs. Missing explicit mention of output format or resolution but schema handles those. Adequate but could mention the idempotency and save_to_library behavior more explicitly.

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 67% (6 of 9 params have descriptions). Description names output maps but adds no parameter-specific meaning beyond schema. Baseline 3 is appropriate since schema covers most parameters.

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 (generates) and resource (PBR material from text prompt) with outputs listed (albedo, normal, roughness, height maps). Distinguishes from sibling generate_texture by specifying PBR maps and precise tiling layouts, and from generate_hdri by material focus.

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

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

Provides clear usage context: asynchronous workflow (poll get_generation), credit spending (refunded on failure), typical time (120s). However, no explicit when-to-use vs siblings like generate_texture or generate_hdri is given; user must infer from output types.

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 annotations by disclosing the async contract (returns a generation id, poll get_generation), the credit cost with automatic refund on failure, and a ~60 s expected duration. Annotations only declare write/openWorld/idempotent/destructive hints; the description adds the operational behavior an agent needs.

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 dense sentences, front-loaded with purpose and use cases, then exclusions, then async/credit/time behavior. No filler; every clause carries decision-relevant information.

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

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

Covers purpose, exclusions, sibling routing, async polling, cost/refund, and latency for an 8-parameter write tool with no output schema. Nothing essential to a correct invocation is missing.

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

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

Schema description coverage is 88%, so the schema already documents model, prompt, image_url, max_credits, aspect_ratio, and idempotency. The prose only loosely reinforces image_url ('optionally from a reference image') and adds no detail on model selection or resolution. Baseline 3 is appropriate when the schema carries the semantics.

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

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

Specific verb+resource ('One AI image from a text prompt') with concrete output categories (sprites, flipbooks, emissive/UI textures, concept images) and explicit exclusion of a sibling ('No PBR maps: use pbr-material'). An agent can distinguish this from generate_pbr_material and generate_hdri without opening schemas.

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

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

Gives clear when-to-use (sprites, flipbooks, emissive/UI, concept images) and when-not (PBR maps, redirecting to pbr-material), plus the polling alternative get_generation. It omits the quote_generation prerequisite from the prose, though that lives in the max_credits schema description.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. Beyond that, the description discloses the shape of the response (permissions/downloadability and ownership flags), which is meaningful behavioral context for a read tool with no output 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?

One front-loaded sentence with no filler; the field enumeration is dense but all of it is informative. Minor weakness: it reads as a noun fragment rather than stating the action verb explicitly.

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 read tool with an existing title and readOnly annotation, the main gaps are the provenance/format of asset_id and any indication of what happens for nonexistent or non-owned assets. The field list compensates for the absent output schema, but parameter guidance is missing.

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

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

Schema description coverage is 0% and the single parameter (asset_id, type integer) carries no description. The tool description says nothing about what asset_id is or where to obtain it (e.g., from search_assets), leaving the parameter entirely undocumented.

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 ('Full details of one asset') and enumerates the concrete fields returned (description, tags, license, price, downloadability, ownership), which clearly separates it from search_assets. It doesn't explicitly reference a sibling or say it addresses a single asset_id vs. a listing, but the singular scope is evident.

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 guidance, no exclusion clause, and no mention of the obvious alternative (search_assets to discover assets before fetching details). The agent must infer that this tool is for lookup by a known asset_id.

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?

readOnlyHint=true already covers the safety profile, so the bar is lowered. The description usefully discloses what the call returns (balance, per-connection spending limits, recent movements), which matters because there is no output schema, but it says nothing about freshness, window size for 'recent', or result format.

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 compact phrase-fragment that front-loads the primary resource (credit balance) before the secondary details. Nothing is padded, though it is a fragment rather than a complete sentence.

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 tool with no output schema, the description covers the key question of what data comes back. Only the shape and time window of the returned figures are left unstated, which is a minor gap.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; the baseline of 4 applies. The schema is empty and fully consistent with the parameterless 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?

Names the specific resource being retrieved (credit balance) and enumerates the scope: spending limits for this connection plus recent credit movements. An agent can distinguish it from list_credit_packs or quote_generation, though it never explicitly contrasts itself with those 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?

Usage is implied by the enumerated contents — an agent knows to call this to inspect credits or spending limits — but there is no explicit when-to-use statement, no prerequisites, and no guidance on how it relates to alternatives such as list_credit_packs.

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?

readOnlyHint=true already establishes the safe-read profile, and the description adds genuinely useful state-dependent behavior: progress reporting and a caller-facing poll_after_seconds on running, file URLs and license on success, and refund information on failure/cancellation. It stops short of documenting ID validity, retention/expiry of URLs, or error behavior for unknown IDs.

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 front-loaded sentence with a compact state-by-state enumeration; every clause carries information and nothing is padded or repeated.

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 usefully covers the shape of each return state, which is exactly what an agent needs before polling. It is nearly complete for a status endpoint, missing only edge behavior (invalid/expired IDs, URL lifetime) and the explicit polling workflow.

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% and the single required parameter generation_id has no description anywhere. The description never clarifies that the parameter is the ID returned by a generation-triggering tool, or what forms are accepted, so it does not compensate for the schema 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+resource ('Status of a generation') and enumerates the four terminal states it can report, which is far more precise than a bare name restatement. It doesn't explicitly distinguish itself from the sibling list_generations (bulk listing) or cancel_generation (mutation), leaving that differentiation to the name.

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

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

Usage is only implied: the mention of 'poll_after_seconds' on the running state signals this is a polling endpoint, but the description never says when to call it (e.g. after generate_texture/generate_pbr_material) or how it differs from list_generations. No explicit when-not or alternative routing is provided.

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 readOnlyHint=true annotation already establishes this is a safe read. The description adds genuinely useful behavior beyond the schema: the price currencies (EUR/USD) and the fact that credits never expire, which is a policy trait an agent could relay to a user.

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

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

Two terse fragments with no wasted words and the subject front-loaded. However, the absence of a verb makes it read as a label rather than a directive, which slightly undercuts clarity.

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 input parameters and no output schema, the definition is nearly complete by omission, and the currency/expiry notes cover the key user-facing facts. Still, an agent is not told what a pack entry contains (e.g., credit amount, price field names) or that this is the canonical catalog source.

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

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

The tool takes zero parameters and schema coverage is 100%, so the baseline is 4. There is nothing for the description to disambiguate about inputs.

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 is a noun phrase ('Credit packs and prices') rather than a verb+resource statement, though it clearly implies retrieving the credit-pack catalog. It adds scope (prices in EUR/USD) but does not distinguish itself from sibling retrieval tools like get_balance or create_checkout_link.

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?

No when-to-use guidance at all. It does not say whether this is the right tool to inspect purchasable packs versus checking an existing balance via get_balance, nor when create_checkout_link should follow.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. Beyond that the description discloses nothing: no ordering rule for 'recent', no default limit behavior, no pagination or truncation semantics, which matters for a list tool.

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 short sentence with no wasted words, but the brevity reflects under-specification rather than discipline. It is front-loaded in the trivial sense that there is only one clause.

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 low-complexity, read-only, single-optional-parameter tool the bar is modest, but the description adds nothing about the limit semantics, ordering, or what a 'generation' record contains. An agent gets no help deciding how to call it correctly.

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

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

Schema description coverage is 0% and the single 'limit' parameter (default 10, max 100) is undocumented in both schema and description. The description does not compensate for this gap by explaining the limit, its bounds, or the default page size.

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 sentence 'The user's recent API generations.' is a noun phrase that essentially restates the title 'Recent generations' without naming an action verb. It conveys the resource and that a list is implied, but it does not distinguish itself from siblings like get_generation or list_generators.

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

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

There is no when-to-use guidance, no mention of the single-generation alternative (get_generation), and no exclusions. The word 'recent' hints at scope but provides no actionable selection criteria.

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

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

Annotations already declare readOnlyHint=true, so safety is covered, but the description goes beyond them by disclosing what the listing actually contains: API parameters, price examples, and URLs for website-only generators. It does not mention pagination or output format, but with no output schema the content disclosure is valuable.

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

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

A single sentence that front-loads the resource and then enumerates the two result categories. It is slightly dense as a run-on, but every clause carries information about the returned content.

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

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

For a parameterless, read-only catalog call with no output schema, the description covers what is returned and how entries are categorized. The remaining gap is that it doesn't state the return shape or ordering, which is minor for this tool.

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

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

The tool takes zero parameters (schema coverage 100%), so per the rubric the baseline is 4. The description introduces no parameter concepts because none exist, and none are needed.

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 (list) and resource (3D Texel AI generators) and further splits it into API-runnable vs website-only, which is genuinely informative. It does not explicitly distinguish itself from siblings like list_generations or generate_texture, but the catalog purpose is unambiguous from the name and text.

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 explicit when-to-use statement, no condition that selects this tool over list_generations or generate_texture, and no mention of prerequisites. The only hint of usage is the implicit 'discover generators' framing, which is not 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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds useful context that owned assets can be re-downloaded at no cost, which explains why a user would list them. It says nothing about pagination behavior or how results are ordered, so it is only a modest addition.

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 short fragment with zero waste and the key scope fact front-loaded. It is under-specified rather than verbose, so conciseness is adequate but not exemplary.

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 paginated list tool with no output schema, the description should at least indicate pagination existence and roughly what is returned. Neither is covered, and with only readOnlyHint available the agent lacks the full picture.

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% and the description never mentions page or per_page, so neither the schema nor the description explains these two pagination parameters. They are optional with defaults, which limits the harm, but the description does not compensate for the coverage gap as required.

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 and its scope precisely: assets the user owns. It implicitly distinguishes this from search_assets (catalog-wide) and get_asset (single asset), though it never names a sibling explicitly. A clear purpose, short of the 5-level standard that calls out 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?

The parenthetical '(re-download for free)' hints at the re-download use case, but there is no explicit when-to-use statement and no alternatives named. An agent must infer whether to call this or search_assets to locate an asset.

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?

readOnlyHint=true already tells the agent this is a non-mutating call, so the safety burden is covered. The description adds genuine context beyond that: the quote is pre-flight and exact, and the balance is only returned 'when connected', hinting at an auth/connection dependency. It says nothing about rate limits, failure modes for unsupported generators, or how the nested params affect the quote.

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, the pricing purpose front-loaded and the usage directive second. Every clause carries information; there is no filler or restatement of the title.

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

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

For a read-only pricing lookup with no output schema, the description covers the essential 'what' and 'when'. However, with 0% schema coverage and an opaque nested params object, it leaves the caller without enough to actually construct the quote request, which is a meaningful completeness gap for this tool's complexity.

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% for two required parameters, and the description compensates for neither. It never explains the generator enum values or, more importantly, the free-form nested 'params' object whose shape is entirely undocumented anywhere. An agent cannot know what to put in params other than by guessing from the generate_* siblings.

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 (quote/pricing) and resource (a generation) plus the pre-execution timing: 'Exact credit price of a generation before running it.' This clearly separates it from the generate_* siblings that actually produce assets, though it does not name any sibling explicitly. It also folds in the balance read, which partially overlaps get_balance.

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 imperative 'Always show this price to the user before generating' gives a clear trigger condition and even a UX obligation, which is more than most definitions offer. It does not state when *not* to call it or point to an alternative when a price is not needed, so it falls short of a full 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 declare a non-read-only, idempotent, non-destructive write. The description adds material context beyond that: the write is a PUBLIC publication (an irreversible visibility consequence the annotations do not convey), it is free of charge, and it requires a previously succeeded generation. It does not cover auth requirements or what happens if the generation is republished.

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 fragments with zero filler, front-loaded on the action and destinations, then cost and the permission gate. Every clause carries distinct information; nothing repeats the schema or title.

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

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

For a single-parameter tool with no output schema, the description covers what the tool does, which generation types qualify, the destination libraries, the cost, and the user-consent requirement. The remaining unknowns (return payload) are not needed since no output schema is declared.

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?

One parameter with 0% schema description coverage, so the description must carry the load. "A succeeded generation" usefully constrains generation_id to a completed generation, but gives no format, ID source, or how to obtain a valid value (e.g. via get_generation or list_generations). Partial compensation only.

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 (Publishes), a specific resource (a succeeded generation of type PBR material or HDRI), and two destinations: the public community library and the user's library. No sibling tool (list_my_library, download_asset, get_generation) does this, and the dual-destination scope makes the tool's effect unambiguous.

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?

"Only when the user asks" is an explicit gating condition, and "Free" tells the agent this does not consume credits unlike the generate_* / quote_generation siblings. The prerequisite that the generation must have succeeded is implied by "a succeeded generation". No named alternative is given, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds meaningful behavior beyond that: catalog size (7,000+), the shape of returned records, and the pricing convention ('price in credits (0 = free)'), which is context the annotations cannot convey.

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

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

Front-loading the search scope and return shape is good, but the asset list is redundant — HDRIs, decals, and atlases are each named twice across the two catalog enumerations, padding a description that could be two tighter sentences.

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 five params, no required fields, and no output schema, the description usefully states the returned fields (id, title, type, license, price, thumbnail, URL) so the agent knows what comes back. The missing piece is any guidance on pagination behavior across the 7,000+ catalog.

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 60%, with enums on both 'type' and 'source' already documenting their values. The description reinforces 'free CC0' for handmade and the credit pricing model, but adds no syntax, paging guidance, or semantics for 'page'/'per_page' beyond what the schema provides, so it only partially compensates for the coverage 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 concrete verb and resource ('Search 7,000+ assets') and enumerates the asset categories covered, so the agent knows exactly what corpus is being queried. It does not, however, distinguish itself from siblings like get_asset or list_my_library, so the scope is clear but the boundary against neighbors is not.

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

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

Usage is implied rather than stated: the query examples ('mossy stone wall', 'sunset skybox', 'walk cycle') signal a keyword-search workflow, but there is no explicit statement of when to choose this over get_asset for a known id or list_my_library for owned assets, and no exclusions.

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