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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds behavioral context by specifying that the output includes 'normalized metadata and CC0 licensing', which is useful beyond the annotations. No contradictions.

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 a single, focused sentence with no wasted words. It is front-loaded and immediately conveys the tool's purpose.

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

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

Given the presence of an output schema (not shown), the description does not need to detail return values. However, it could benefit from mentioning the scope of metadata fields or any required permissions, but is largely complete for a simple retrieval 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 input schema has 0% description coverage for its single parameter (assetId). The tool description does not explain what assetId represents, its format, or how to obtain a valid ID. This forces the agent to infer from context, which is inadequate.

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 clearly states the tool retrieves 'normalized metadata and CC0 licensing' for a single ambientCG asset. It uses a specific verb ('Get') and resource ('ambientCG asset'), and distinguishes from sibling search/list tools that operate on collections or different sources.

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

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

The description implies this tool is for fetching details of a specific asset, but does not explicitly state when to use it versus alternatives like search or list tools. No when-not guidance 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?

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds that it returns metadata and asset counts, which is useful, but lacks details on pagination, errors, or performance. 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?

Single sentence, front-loaded with verb and resource, no unnecessary words. Efficient and clear.

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

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

Output schema exists so return values are covered. However, the optional 'type' parameter is unexplained, and given siblings, more context on filtering would help. Tool is simple but description could be more informative.

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 has one optional parameter 'type' with enum, but description does not mention it. With 0% schema description coverage, the description should compensate but fails to explain the parameter's purpose or usage.

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?

Description clearly states the action ('list') and resource ('ambientCG category metadata and asset counts'). It differentiates from sibling tools like polyhaven_list_categories and sketchfab_list_categories by specifying 'ambientCG'.

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 guidance on when to use this tool vs alternatives. Sibling tools offer similar list_categories functions for other sources, but description provides no context for selection or exclusions.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as false, indicating a safe read operation. The description adds context about output content (variant attributes, extensions, etc.) but does not reveal additional behavioral traits like pagination or 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?

Single sentence with 12 words, no redundancy. Efficiently communicates the core purpose without extraneous text.

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?

Despite having an output schema, the description is insufficient for a list tool with 5 parameters. It lacks details on pagination (cursor/limit), required assetId, filtering (extension, attributes), and when to use this tool over alternatives. The agent would struggle to invoke this correctly without additional documentation.

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. It only hints at 'variant attributes' and 'extensions' but fails to explain the purpose or format of parameters like assetId, limit, cursor, extension, and attributes. This leaves the agent uninformed about how to effectively use the 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?

The description clearly states it lists official CC0 asset archives and specifies the returned fields: variant attributes, extensions, URLs, and byte sizes. It distinguishes from sibling tools like ambientcg_search_assets and ambientcg_get_asset, which focus on searching or getting single 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?

No guidance on when to use this tool versus siblings (e.g., ambientcg_get_asset for single asset details, or polyhaven_list_files for Poly Haven files). No prerequisites, when-not-to-use, or alternative tool references.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context such as rate limits, pagination behavior, or query syntax, leaving a gap beyond the structured metadata.

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 a single sentence that front-loads the tool's purpose reasonably. However, it is too sparse and could benefit from additional context without becoming verbose. It earns a baseline score for efficiency but lacks depth.

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

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

Given that there are five parameters with no schema description coverage and no parameter information in the description, the description is incomplete. An output schema exists, which lessens the need to describe return values, but behavioral aspects (e.g., sorting, pagination via cursor) are missing. The description should provide more context for a search tool of this 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%, and the description provides no information about any of the five parameters (sort, type, limit, query, cursor). The description does not compensate for the lack of schema descriptions, making it difficult for an agent to understand parameter usage without inspecting 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 clearly states the verb 'Search', the resource 'CC0 materials, HDRIs, models, decals, atlases, brushes, terrains, and other ambientCG assets', and is specific enough to distinguish from sibling search tools for other sources (e.g., Poly Haven, Fab).

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 guidance on when to use this tool versus sibling search tools (e.g., polyhaven_search_assets, fab_search_assets). There is no mention of preferred use cases, exclusions, or context that would help an agent decide between alternatives.

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

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

The description adds significant behavioral detail beyond the annotations: it preserves existing rigs unless replaceRig is set, and it returns a landmark correction request on ambiguous anatomy instead of producing a bad rig. These are exactly the kind of behavioral traits an agent needs and that annotations do not provide.

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 two dense sentences with no filler. The core operation and the two most important behavioral caveats are front-loaded, and every phrase adds useful 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?

This is a complex 9-parameter tool with nested objects, yet the description omits semantics for several optional parameters such as overrides, orientation, priorDigest, and maxInfluences. An output schema exists, so return format is covered, but for a tool this complex the description should provide more guidance on the remaining inputs.

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

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

With only 33% schema description coverage, the description must compensate, and it does partially: it clarifies weightMode (smooth/rigid), replaceRig, target/output/projectRoot relationships. However, it leaves overrides, orientation, priorDigest, and maxInfluences semantically unexplained, so an agent would still have to infer their meaning from 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 operation: fit an 18-joint humanoid skeleton to an unrigged local GLB, bind weights, and publish the skinned GLB. This clearly distinguishes it from sibling tools like asset_inspect_rig or asset_retarget_animations by focusing on auto-rigging unrigged 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 clearly says the input must be an unrigged humanoid GLB and explains that an existing rig is preserved unless replaceRig is set, giving a concrete when-to-use/when-not-to-use condition. It does not explicitly name sibling alternatives, but the use case is unambiguous enough for selection.

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 idempotent and non-destructive hints. The description adds context on behavior: removes unrelated clips/meshes/materials/textures, reuses cached source entries, and uses range-fetching. These details go beyond 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?

Single sentence that is concise and front-loads the action. However, the phrasing is technical ('range-fetching', 'aggregate source entry') which may reduce 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?

Given the tool has 5 parameters and an output schema, the description covers the core function but omits prerequisites (e.g., listing animations first) and does not describe the output beyond 'standalone GLB'. Adequate but incomplete for a complex tool.

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

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

Schema coverage is 0% (no parameter descriptions), so the description must compensate. It only mentions 'one named animation' but does not explain the required parameters (packId, uploadId, animationName, acceptLicense) or the optional entryPath. The agent must infer mappings 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?

The description clearly states it exports one named animation as a standalone GLB from a bundled source. Specific verb 'export' and resource 'animation' distinguish it from sibling tools like asset_download_bundle_entry (downloads full entry) and asset_list_bundle_animations (lists animations).

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

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

The description implies usage after listing animations ('one named animation') but does not explicitly state when to use vs. alternatives like asset_download_bundle_entry. No exclusions or contexts are 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?

Annotations already indicate idempotency and non-destructiveness. The description adds behavioral details: extraction via HTTP byte ranges, local caching, and avoidance of downloading unrelated contents. It also notes the license requirement, providing context beyond 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?

The description is two sentences, front-loaded with the primary action. Every sentence adds value without redundancy or fluff.

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

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

Given the tool has an output schema (so return values are covered), the description sufficiently explains the core operation and key prerequisite. It could explicitly mention the relationship to sibling tools, but overall it is complete enough for typical usage.

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 only 25% (only acceptLicense has a description). The description does not explain packId, uploadId, or entryPath meanings beyond what the schema provides. It fails to compensate for the low coverage, leaving parameter semantics unclear.

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 clearly states the tool extracts one selected ZIP entry from a remote asset bundle using HTTP byte ranges, caches it locally, and avoids downloading unrelated contents. This distinctively differentiates it from sibling tools like asset_list_bundle_entries (listing) and asset_download_bundle_animation (animation download).

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

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

The description mentions 'Requires explicit license acknowledgement', indicating a prerequisite for use. It implies usage after listing bundle entries, but does not explicitly state when not to use or provide alternatives. The context is clear but lacks exclusions.

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

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

Annotations show mutability (readOnlyHint=false) and idempotency (idempotentHint=true). Description adds critical details: allowlisted hosts, redirect revalidation, byte cap, and no overwrite policy. 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?

Two sentences totaling ~70 words, front-loaded with core action and constraints. Every sentence adds value without redundancy.

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

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

Covers provider scope, license requirement, security measures (allowlist, revalidation, byte cap), and idempotency (no overwrite). Return details are omitted but output schema exists, so complete enough for correct invocation.

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 25% (only acceptLicense has description). Description adds context about license acknowledgement and validation of URL shapes, but does not fully explain each parameter's syntax or constraints.

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?

Clearly states the tool downloads a file URL from specific providers (Poly Haven, ambientCG, Smithsonian, Game-icons.net/Kenney) with license acknowledgement. Distinct from sibling tools like fab_download_free_asset or audio_download_asset which target different providers.

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?

Implies usage when a file URL from those providers is obtained and license must be accepted. Does not explicitly exclude when not to use or provide alternative sibling tools, but context of siblings is available.

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 convey that the tool is not read-only, is idempotent, and is not destructive. The description and schema add concrete behavioral context beyond annotations, especially the guarantee that the tool 'never overwrites one' and the fact that it works across download sources. No contradictions with annotations are present.

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 two sentences with no filler. It front-loads the primary purpose and output, then adds the important portability qualifier about already-downloaded Unreal packs. Every clause adds useful 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?

Between the description, annotations, and richly described schema, an agent has what it needs to call the tool: source and output directories, package filtering behavior, non-overwrite safety, and texture size constraints. The only minor gap is not explicitly routing to a sibling download/import tool, but that is not required for correct invocation.

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 schema has 100% description coverage: sourceDir, outputDir, packages, and maxTextureSize each have meaningful explanations, including the many-gigabytes warning for omitted packages and the texture-size cap behavior. The main description does not need to repeat parameter details, so the baseline score of 3 applies.

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

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

The description states a specific action ('Convert') with a precise input (a local directory of Unreal .uasset/.umap files) and output (self-contained model/scene GLBs with reconstructed PBR materials, actor transforms, and a provenance report). This clearly differentiates it from download-oriented siblings that fetch assets rather than convert local Unreal content.

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

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

The description gives clear context for when to use this tool: on any already-downloaded Unreal pack, independent of how it was downloaded. It does not explicitly name alternative tools or state exclusions, but the local-source condition is clear enough to route an agent.

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

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

The description adds a useful safety claim—'Reads only caller-selected local files and downloads nothing'—which goes beyond the read-only/idempotent annotations. But it is not fully transparent: the `target` object variant allows 'acquire a pinned sample into the development cache,' which implies a cache write and possibly fetching, undercutting the blanket 'Reads only' statement. Because the annotations themselves declare read-only behavior, this is a descriptive overreach rather than an annotation 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?

The description is a single well-organized sentence with a front-loaded action/resource followed by a compact list of returned data, plus one short sentence for the access/security behavior. It contains no fluff and every clause earns its place.

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

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

For a two-parameter read-only inspection tool with an output schema, the description covers the main inputs and safety behavior compactly. However, it misses the `sourceId` pinned-sample input form, the cache-write implication, and any explicit relationship to sibling tools, leaving an agent with an incomplete mental model of when and how to invoke it. The output schema covers return values, so no deduction there, but the input-mode gap prevents a higher score.

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

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

Schema coverage is 100%, so the schema already documents `target` and `libraries`; the description mostly repeats those facts. It also narrows `target` to 'a local humanoid GLB' and omits the pinned-sample/sourceId acquisition option, which could mislead an agent about valid inputs. This is not a meaningful semantic addition 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?

The description names the action ('Inspect'), the exact resource ('local humanoid GLB and optional local UAL ZIP/GLB libraries'), and enumerates the outputs (meshes, joints, suggested bone mappings, clips, attributes, extensions, measured bounds, attachment candidates). This makes it clearly distinct in purpose from sibling mutation/preview/import tools such as asset_auto_rig and asset_retarget_animations.

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

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

The description implies the tool should be used when an agent needs detailed structural/animation-donor information before rigging or retargeting, and its read-only privacy claim clarifies safe contexts. However, it never explicitly states when to choose this over asset_auto_rig, asset_preview_animation, or asset_retarget_animations, and it gives no exclusions or prerequisites. Usage guidance is only implied, not stated.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by explaining the range-extraction and caching process, which goes beyond annotations. No contradictions.

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

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

Two sentences with no wasted words. The first sentence delivers the core function; the second adds a key default behavior. Every sentence earns its place.

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

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

Given the presence of an output schema (so return format is handled), the description covers the main behavioral aspects: caching, automatic selection, and the result being named clips. It could clarify that it only lists names (not downloads), but that's inferable from sibling tools.

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

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

Schema description coverage is 33% (low, <50%), so the description should compensate. It only explains entryPath ('omit to select standard non-root-motion GLB'), leaving packId and uploadId unexplained. Without that context, the agent may not infer their roles from names alone, especially since packId has an enum but no 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 clearly states the tool lists animation clips inside a bundled GLB, using specific verbs and the resource. The title reinforces this. The tool is well-differentiated from siblings like asset_download_bundle_animation (download) and asset_list_bundle_entries (list entries).

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

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

The description provides guidance on omitting entryPath to automatically select the standard non-root-motion GLB, but does not explicitly state when to use this tool over alternatives, such as when only animation names are needed. It lacks explicit usage context or 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?

The description adds behavioral context beyond annotations: it mentions HTTP byte ranges, return of entry paths and sizes, and that signed URLs are never exposed. This complements the readOnlyHint=true annotation without 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?

The description is two sentences, front-loaded with the main action, and every word adds value. No unnecessary information is present.

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

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

Given the tool's simplicity (two parameters, simple list output), the description covers the key return values (entry paths and sizes) and a security note. The presence of an output schema reduces the need to detail return structure. Minimal gaps.

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 input schema has two parameters (packId, uploadId) with 0% description coverage. The description does not explain what packId or uploadId represent or how they relate to the 'curated itch.io ZIP,' leaving the agent without parameter 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 clearly states the tool inspects a curated itch.io ZIP via HTTP byte ranges, listing entry paths and sizes. The verb 'inspect' and resource 'curated itch.io ZIP' align with the title 'List files inside a remote asset bundle,' and the purpose is distinct from sibling tools like download or search.

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

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

The description implies use for inspecting bundle contents without full download, but it does not explicitly state when to use this tool versus alternatives (e.g., asset_download_bundle_entry). No comparison or exclusion criteria are 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?

Annotations provide readOnlyHint and idempotentHint. The description adds significant context: results have MCP download paths without manual browser/login/paywall, and the broader directory includes package-manager, Git, authenticated sources. No contradictions.

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 extremely concise: two sentences. The first sentence front-loads the core functionality and key benefit, the second explains the parameter. No wasted words.

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

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

With a single parameter and full annotations, the description is complete. It explains the two modes, the nature of results, and acknowledges the output schema existence. No gaps.

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 fully compensates by explaining the agentReadyOnly parameter's effect (default true gives agent-ready sources, false gives broader list). This adds crucial meaning 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?

The description clearly states the tool lists asset sources, distinguishing between agent-ready and broader sources. It uses a specific verb ('list') and resource ('asset sources'), and effectively distinguishes itself from sibling tools like asset_search_sources and various asset search/download tools.

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

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

The description explains the default behavior and how to get broader results via the agentReadyOnly parameter. It implies when to use each mode, but does not explicitly contrast with sibling tools or state when not to use it. Still, the context is clear enough.

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 indicate idempotent, non-destructive, and non-read-only behavior. The description adds useful behavioral context beyond those annotations: it publishes a nonblank contact sheet under the project root and explicitly returns an unavailable result if the rendering backend is missing. This clarifies failure modes and output guarantees.

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 convey rendering, optional inputs, output location, and failure behavior with no wasted words. Key constraints like 'nonblank' and 'explicit unavailable result' are front-loaded and meaningful.

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 complex with 10 parameters and a nested pose object, yet the description leaves significant gaps: no explanation of priorDigest, no definition of what clip references, no clarification on how times interacts with clip vs pose, and no guidance on width/height defaults or constraints beyond the schema. The output schema helps with return value expectations, but the input side remains under-specified for an agent to use this confidently.

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 only 30%, so the description must compensate. It does partially explain angles, clip sampling, bone pose, and contact sheet output, but it leaves width, height, times, clip's reference semantics, and especially priorDigest unexplained. The description adds meaning for several parameters but not enough to fully cover the 10-parameter surface.

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 action: render a prepared GLB from several angles, optionally sampling a clip or using a bone pose, and publish a contact sheet. It clearly differentiates from sibling tools like asset_inspect_rig and asset_auto_rig by focusing on rendering/preview output rather than inspection or rigging.

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 phrasing 'prepared GLB' and 'optional clip sample time or explicit bone pose' implies this is the tool to call after preparation/rigging work, but it never explicitly says when to choose it over siblings like asset_inspect_rig or asset_retarget_animations. There is no when-not-to-use or alternative 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?

The description discloses meaningful behavior beyond the annotations: it preserves the target's mesh/materials/UVs and existing clips by default, applies a world-space rest correction, and publishes a minimal GLB. These details align with idempotentHint and destructiveHint=false; no contradiction exists.

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 packed sentences front-load the main action and then add the most important behavioral caveat. There is no filler or repetition.

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 7-parameter pipeline, the description captures the core workflow, key side effects, and the root-motion requirement. The main gap is no mention of mapping or priorDigest, but the output schema and annotations fill some surrounding context.

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 low at 43%, but the description compensates for key parameters: clips are 'pinned release donors', target is a 'prepared target skeleton', output is a 'game minimal GLB', keepExistingClips is 'by default its existing clips', and root_motion maps to the '_RM donor' rule. It leaves mapping and priorDigest unexplained, but the core workflow parameters are clarified.

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 multi-step action: fetch pinned release donors, retarget clips onto a prepared target skeleton, preserve target attributes, and publish a game minimal GLB. This clearly differentiates it from sibling search, download, and preview tools.

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

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

The description gives clear context: it is for retargeting pinned release donor clips onto an already prepared target, with a root-motion caveat about needing the matching _RM donor. It does not explicitly name alternatives or when-not-to-use conditions, but the scope is clear enough.

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 indicate readOnlyHint=true and destructiveHint=false. The description adds that the tool searches sources and clarifies exclusion behavior (manual sources unless agentReadyOnly=false), which is beyond what annotations provide. No contradictions.

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 extremely concise: two sentences with no wasteful words. The first sentence announces the core action and filters; the second clarifies the important exclusion rule. Every word earns its place.

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

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

Given the presence of an output schema (explaining return values), the description covers the main functionality and filtering options adequately. It mentions the key agentReadyOnly condition. Minor gap: does not explicitly state that it returns sources (not assets), but that is inferred from tool name and category. Overall complete for a search 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?

With 0% schema description coverage, the description must compensate. It mentions four out of five parameters (query, category, license, access) and implicitly references agentReadyOnly through the exclusion rule. However, it does not explain each parameter's behavior or constraints in detail, leaving some ambiguity (e.g., what 'access mode' values are available). Partially compensates but not fully.

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 clearly states it searches 'agent-ready asset sources' with specific filters (category, license, access mode, text query). It distinguishes from other search tools (siblings like fab_search_assets) by specifying the scope and the exclusion of manual/provider-page sources unless agentReadyOnly=false.

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

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

The description provides clear context on when to use the tool: for searching agent-ready sources, with a note that manual/provider-page sources are excluded by default. It implies that for non-agent-ready sources one might need to set agentReadyOnly=false or use other tools, but does not explicitly mention sibling alternatives.

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

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

Annotations indicate idempotent and non-destructive; the description reinforces this with 'existing files are never overwritten.' It adds new constraints like URL restrictions to official hosts, which annotations don't cover. No contradictions.

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

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

Two sentences, no fluff. First sentence conveys main purpose and key condition; second adds important behavioral constraints. Front-loaded with essential 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?

Given the output schema exists (not shown) and annotations cover safety hints, the description adequately explains core behavior, security, and idempotency. Could mention error handling for invalid IDs, but overall complete for a download 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 description adds context for acceptLicense (required acknowledgement) beyond the schema, but assetId is only described as 'by ID' without extra semantics. Schema provides pattern and maxLength for assetId, so overall value is moderate.

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 clearly states the tool downloads a catalog asset by ID into a dedicated audio directory, requiring license acknowledgement. It distinguishes from siblings like audio_search_assets (search) and fab_download_free_asset (free assets) by specifying the exact action and conditions.

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

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

The description provides clear usage context: requires license acknowledgement, URLs are restricted to official hosts, and files are never overwritten. It implies when to use (after searching with audio_search_assets) but does not explicitly state when not to use or suggest alternatives.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds specific behavioral context about what is listed (libraries, licenses, browse pages, contracts), enhancing transparency beyond 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?

The description is a single, well-structured sentence that efficiently conveys the tool's output without unnecessary words.

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

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

Given no parameters, rich annotations, and an existing output schema, the description is complete enough for an agent to understand the tool's purpose and output.

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 are 0 parameters with 100% schema coverage trivially. The description adds meaning beyond the empty schema by detailing what the tool returns.

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 clearly states the tool lists supported audio libraries, best uses, licensing caveats, browse pages, and contract info, distinguishing it from sibling search/download tools.

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

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

The description implies when to use the tool (to get an overview of audio sources), but does not explicitly state when not to use it or compare it to siblings like audio_search_assets or audio_download_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?

Annotations already indicate read-only and idempotent, and the description adds context about stable direct URLs and explicit license metadata, which are non-obvious behaviors.

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 extremely concise with two sentences, no filler, and the key information is front-loaded.

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

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

Given the presence of an output schema and annotations, the description covers the core purpose and primary usage scenario, but lacks explanations for pagination and parameter meaning.

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 0% schema description coverage, the description should explain at least key parameters like query, kind, source, and limit, but it doesn't mention any parameter.

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 clearly states the tool searches a curated catalog of official audio packs with stable URLs and license metadata, and distinguishes itself from the sibling audio_list_sources for broader discovery.

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

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

Explicitly tells when to use this tool (searching curated catalog) and when to use an alternative (audio_list_sources for broader provider-page discovery).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful context that it reads a 'bounded' section and does not run or extract the compiler, which clarifies the non-execution behavior. It doesn't add much beyond that, but the annotations carry the main burden.

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

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

Two sentences with no wasted words. The core action and resource are front-loaded, and the clarifying 'does not run or extract the compiler' is placed second. Every sentence earns its place.

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

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

The tool has a single parameter with an enum, an output schema, and read-only annotations, so the description doesn't need to explain return values or safety. However, it doesn't explain what the sections contain or how an agent would know which section to request, which is a meaningful gap for a guidance-reading tool. The output schema may cover return structure, but the selection semantics are left to the enum names.

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 the 'section' parameter. The description says 'bounded syntax or workflow section' which maps to the enum values, but it does not explain what each enum value (overview, syntax, low, mid, high, delivery) means or how to choose one. The enum itself provides the allowed values, but the description adds minimal semantic guidance beyond 'bounded section'.

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 ('Read') and resource ('bounded syntax or workflow section from the verified anyCreature 1.3.1 payload'), which clearly distinguishes it from the sibling tools that search/download assets. It could be slightly stronger by naming a sibling it is not, but the 'does not run or extract the compiler' clause helps differentiate it from compiler-related operations.

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

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

The description implies when to use it: when you need authoring guidance for anyCreature 1.3.1, and the 'does not run or extract the compiler' clause tells the agent what it won't do. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions, leaving the agent to infer usage context from the section enum.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond those: it does not start a browser and does not request credentials, which clarifies that this is a lightweight, non-interactive status check. No contradiction with 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?

The description is a single, front-loaded sentence with no filler. However, terms like 'pinned anyCreature payload' and 'optional local tooling' are somewhat jargon-heavy and may require the reader to infer their meaning.

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

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

With no parameters, an output schema present, and annotations covering safety, the description provides adequate context: purpose, non-interactive nature, and credential-free operation. It is reasonably complete, though it could clarify what 'optional local tooling' refers to.

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 has zero parameters and the empty schema has 100% description coverage, so the baseline is 4. The description does not need to elaborate on parameters; none exist.

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 the specific verb 'Report' and names the resource ('pinned anyCreature payload') and the exact content reported (payload, currently available operations, optional local tooling). This clearly distinguishes it from sibling tools that search, import, or inspect 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?

The description implies when it should be used: when you need status/availability information without the overhead of a browser or credentials. However, it does not explicitly state when to use this tool versus alternatives like creature_guide or asset_inspect_rig, and it offers no exclusions or conditions.

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 indicate idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds valuable context that the tool downloads to a local directory and never performs purchases or library operations, which aligns with annotations. It does not detail file overwrite behavior or other side effects, but the idempotency hint mitigates some concerns.

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 two concise sentences that convey the core purpose and a key behavioral distinction with no redundant information. It is front-loaded and efficient.

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

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

Given moderate complexity (3 required params, output schema exists), the description covers the overall function and important behavioral notes but lacks parameter details. For a download tool, it is adequate but not fully complete without addressing parameter semantics.

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 only 33% (only acceptFabEula has a description). The description does not elaborate on 'listingIdOrUrl' or 'format', leaving agents to infer meaning from names alone. For low coverage, the description should compensate but does not.

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 clearly states the action (download), resource (free Fab file), and location (configured local download directory). It explicitly distinguishes itself from purchasing or adding to a library, which sets it apart from sibling tools like fab_search_assets or fab_get_asset.

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

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

The description provides clear context for when to use the tool (downloading a free Fab file) and when not to use it (if the intent is to purchase or add to library). However, it does not explicitly mention alternative tools or prerequisites such as requiring a valid listing 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, providing strong behavioral transparency. The description adds the specific context of returning normalized details and per-license prices, but does not disclose behavior for invalid inputs or edge cases. The added value is moderate given the rich 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?

The description is a single, concise sentence that front-loads the core purpose. Every word provides value, with no redundancy or fluff.

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

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

Given the tool has 2 parameters (1 required), a rich set of annotations, and an output schema, the description is largely adequate for selection. It could mention that listingIdOrUrl accepts either an ID or a URL, but overall it provides sufficient context for an agent to decide when to use 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?

Schema description coverage is 0%, so the description should compensate by explaining parameters. It mentions 'one Fab listing' but does not detail the listingIdOrUrl parameter (e.g., format, what it accepts) or the currency parameter. This leaves the agent with minimal guidance beyond the schema's structural definitions.

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 clearly states 'Get normalized public details and per-license prices for one Fab listing,' specifying the verb (Get), resource (Fab listing), and the type of data returned (details and prices). This distinguishes it from sibling tools like fab_search_assets which perform searches.

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

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

The description implies usage for retrieving details of a single Fab listing, and the naming suggests it complements search tools. However, it does not explicitly state when not to use it or provide alternatives, though the sibling set includes similar tools for other sources, making context clear.

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

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

Annotations already indicate a non-read-only, idempotent, non-destructive operation. The description adds meaningful behavioral context: it uses the user's existing FabCLI session, performs no auth or purchase actions, and converts to GLBs in a single step. This goes beyond what the annotations alone 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?

Two sentences with no filler: the first states the core action and scope, and the second adds the key auth boundary. Every sentence earns its place and avoids repeating schema 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?

Given the rich schema, annotations, and output schema, the description is complete enough for an agent to understand when and how to invoke it. It covers ownership, one-step conversion, and the FabCLI session constraint, while the structured fields handle the remaining parameter details.

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 86%, so the schema documents most parameters in detail, including engine, packages, platform, outputDir, acceptFabEula, and maxTextureSize. The description itself adds little parameter-level detail beyond the ownership and GLB conversion context, so the baseline score of 3 is appropriate.

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

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

The description names a specific operation: download an already-owned Unreal asset and convert it to source GLBs in one step. It also scopes the tool to the signed-in Fab account and explicitly rules out login, claiming, and purchasing, which distinguishes it from acquisition-focused sibling tools.

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

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

It clearly states the precondition that the user must already own the asset and have an established FabCLI session. It also gives an implicit when-not by saying the tool never logs in, claims, or purchases, though it does not name an alternative tool for cases like free downloads or new purchases.

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

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

The description adds context beyond annotations by mentioning that a warning identifies 'versioned fallback or stale values,' indicating potential data quality concerns. However, the annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description does not significantly expand on these.

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 two sentences long, front-loading the core purpose. Every sentence adds value: the first states the main action, the second highlights a notable behavior (warning). No extraneous text.

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?

While an output schema exists (not shown), the description does not cover the parameters, leaving a significant gap for a tool with 2 parameters and 0% schema coverage. The warning about stale values adds some depth, but the overall description is slightly incomplete for an agent to understand parameter usage.

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 parameter schema is not described in the description (0% coverage). The 'kinds' parameter has enum values and 'refresh' is a boolean with default false, but their effects are not explained. The description provides no guidance on how these parameters affect the results, relying entirely on 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 clearly states the tool lists 'usable public Fab filter labels and slugs,' with a specific verb and resource. It distinguishes itself from sibling tools like fab_search_assets, which search for assets, by focusing solely on filter metadata. The mention of a warning about versioned fallback values adds specificity.

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

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

The description implies usage for listing Fab filters but does not explicitly state when to use this tool versus alternatives like fab_list_limited_time_free or other filter-related tools. No exclusion criteria or alternative tool references are provided, leaving some ambiguity.

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, openWorldHint, idempotentHint, and destructiveHint, indicating a safe read operation. The description adds only that it lists separately from general free search, adding minimal behavioral context beyond annotations. 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?

Single sentence, front-loaded, no superfluous text. Every word adds value.

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

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

Given rich annotations and an output schema, the description is mostly sufficient. It could mention default limit and behavior when no promotions exist, but the output schema likely covers return fields.

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 only parameter (limit) is fully documented in the schema (type, default, min/max). With 0% schema description coverage, the description does not add parameter meaning, but schema coverage is complete for this single parameter, so baseline 3 is appropriate.

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

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

The description clearly states the tool lists limited-time-free promotions from Fab, distinguishing it from general free search. It uses specific verb 'list' and resource 'promotions', but does not explicitly name the sibling tool for general free search (fab_search_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?

The description implies usage for limited-time-free promotions versus general free search, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternative tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces the read-only nature and adds the specific 'never claims or purchases' context beyond the generic hints. It also explains the unrealOnly filter behavior (filtering to what fab_import_asset can convert), which is useful behavioral context beyond the schema. No contradictions with 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?

Two concise sentences, with the core action front-loaded and the usage guidance in the second sentence. No redundant or filler content; every clause earns its place.

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

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

For a tool with two optional parameters, a rich output schema, and strong annotations, the description covers purpose, usage guidance, the read-only caveat, and the filter semantics. Nothing an agent needs to invoke 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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds a high-level explanation of the unrealOnly filter ('ones that publish an Unreal artifact fab_import_asset can convert') and mentions 'optionally filtered' for query, but this largely paraphrases the schema. It adds minimal incremental value, so a 3 is appropriate.

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

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

States exactly what it does: 'List every listing already in the signed-in Fab library,' with a specific verb and resource. It also distinguishes itself from siblings by mentioning the optional unrealOnly filter and explicitly pointing to fab_search_assets as the alternative for free assets, so an agent can tell them apart.

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

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

Explicitly instructs when to use it: 'Search free assets first with fab_search_assets; reach for this when you want something already paid for.' Also clarifies what it does not do ('it never claims or purchases'), giving clear exclusions against other tools like fab_download_free_asset or purchasing actions.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds that free assets are returned by default, which is useful but not extensive. No disclosure of other behaviors like pagination or 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?

The description is short (two sentences) and front-loads purpose. However, for a tool with 19 parameters, it could be more informative without sacrificing conciseness.

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?

Despite having an output schema, the description fails to provide an overview of filtering capabilities or search behavior. Many sibling tools exist, and this description does not help an agent understand when to use it.

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%. The description does not explain any of the 19 parameters beyond hinting at the 'priceMode' default. It adds negligible semantic value over the raw 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 clearly states the tool searches 'public Fab marketplace listings', a specific verb+resource. It distinguishes from sibling tools that search other marketplaces (e.g., polyhaven_search_assets). The note about free assets as default adds specificity.

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 guidance on when to use this tool versus alternatives like polyhaven_search_assets or sketchfab_search_models. Does not mention prerequisites, when not to use, or other context for choosing this tool.

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

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

The description discloses key behavioral traits beyond annotations: signed URLs are not exposed, the download is streamed to guarded local storage, and license acknowledgement is required. This aligns with annotations (readOnlyHint=false, idempotentHint=true) and adds useful context about side effects and security.

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 concise sentences that front-load the core action and flow, then clarify a key detail (signed URL exposure). Every sentence adds value, no fluff or repetition of schema.

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 covers the core process but lacks guidance on prerequisites (e.g., the need to call itch_list_downloads first), error handling, or what the tool returns. An output schema exists but is not shown; the description does not compensate for missing details on success/failure conditions.

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 only 33% (only acceptLicense has a description). The description adds context that acceptLicense is a required boolean acknowledgement and links to license terms, but provides little additional meaning for packId and uploadId beyond what the schema enum and pattern offer.

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 clearly states the action (resolve and stream), the resource (itch.io asset pack upload), and the flow (explicit license acknowledgement, signed URLs not exposed). It distinguishes from sibling tools by specifying 'itch.io' and 'curated asset pack', and from other download tools by the unique process.

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

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

The description implies the tool should be used when you have a packId and uploadId and after acknowledging a license, but it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or refer to other tools for comparison. The reference to 'listed upload' hints at a prerequisite but could be clearer.

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 the tool as read-only and open-world. The description adds meaningful behavioral context: it explicitly states that no account is required and that signed page tokens are never returned, which addresses a potential security or privacy concern. This goes beyond the annotations and helps the agent understand the tool's safety and access model.

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 two sentences and front-loaded. The first sentence delivers the core purpose and output, and the second sentence adds a critical security note. Every clause earns its place with no redundancy or fluff.

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

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

Given that the tool has a single parameter with clear enums, a read-only annotation, and an existing output schema, the description is complete. It covers the action, the resource, the output fields, and the important behavioral note about tokens. No gaps are present for this level of 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?

The single parameter packId has an enum list of specific values, which are self-explanatory. Schema description coverage is 0%, but the description does not need to add meaning because the enum values and tool name already convey the parameter's purpose. The description adds 'fresh no-account' context, which is not parameter-specific but useful. A score of 3 is appropriate: the description does not hinder understanding but neither does it enhance the schema significantly.

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 clearly states the action (resolve and list uploads), the resource (itch.io pack download page without account), and the specific information returned (upload IDs, names, sizes, license, filenames). It distinguishes this tool from siblings like itch_download_asset, which performs downloads instead of listing.

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

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

The description implies the tool is for listing available downloads from a pack, but it does not explicitly state when to use it versus alternatives like itch_download_asset, nor does it provide prerequisites or exclusions. The context from sibling names helps infer the intended use, but the description itself lacks direct 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 read-only, open-world, idempotent, and non-destructive behavior. The description adds context about the type of metadata returned (authorship, dimensions, license). No contradictions.

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?

Single sentence, 13 words, front-loaded with verb and resource. Every word is informative; no redundancy or fluff.

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

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

Output schema exists, so return values are defined. The description covers the main output components. However, it could mention that the asset ID comes from a search tool. Still, it is sufficient for a simple retrieval tool.

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

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

Schema description coverage is 0%, so the description must explain the parameter. It does not mention 'assetId' or how to obtain it. The parameter is required, yet the description lacks any guidance on its value.

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 clearly states the verb 'Get', the resource 'one Poly Haven asset', and specifies the returned information: normalized metadata, authorship, dimensions, and CC0 license. It distinguishes this tool from search and list 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?

The description implies use when you need metadata for a specific Poly Haven asset, but it does not explicitly mention when not to use it or provide alternatives. Given many sibling tools, more guidance would be helpful.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns category labels and asset counts, which is basic behavioral context. No contradiction with 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?

The description is a single sentence that front-loads the verb 'List' and the resource. There is no extraneous information; every word is necessary and clear.

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

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

With a simple one-parameter tool and an output schema present, the description adequately indicates what is returned (category labels and asset counts). It could be slightly more detailed but is generally complete for the tool's simplicity.

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 schema has 0% description coverage, but the description lists the allowed types (HDRIs, textures, models) corresponding to the enum. This adds meaning beyond the schema by explicitly pairing the parameter with the tool's resource types.

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 clearly states the tool lists Poly Haven category labels and asset counts for HDRIs, textures, or models. It distinguishes from sibling tools like polyhaven_search_assets and polyhaven_get_asset by specifying the listing action and resource scope.

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

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

The description implies usage for listing categories but provides no explicit guidance on when to use this tool versus alternatives (e.g., polyhaven_list_files) or any exclusions. The context is clear but lacks when-not or alternative recommendations.

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, openWorldHint, and destructiveHint=false. The description adds value beyond annotations by specifying exact output fields (download URLs, byte sizes, MD5 hashes, file dependencies) and the presence of filters. This helps the agent understand the response structure without contradicting 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?

The description is a single concise sentence with no filler. It is front-loaded with the verb and resource, immediately followed by key output details and filter capabilities. Every word contributes to understanding.

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

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

Given the output schema exists (assumed to document return values), the description does not need to detail them. However, it fails to mention pagination parameters ('limit', 'cursor') and only lightly covers filters. For a tool with 6 parameters and 1 required, the description is slightly incomplete but still adequate for basic use.

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. It only mentions two parameters ('format' and 'resolution') as filters, ignoring 'limit', 'cursor', 'assetId', and 'includeDependencies'. The agent gets no explanation of pagination or how to use the required 'assetId'. This is insufficient for a 6-parameter tool.

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 clearly states the tool lists 'download URLs, byte sizes, MD5 hashes, and file dependencies' for a Poly Haven asset, with explicit mention of format and resolution filters. This distinguishes it from siblings like polyhaven_get_asset (which likely gets metadata) and ambientcg_list_files (different source). The verb 'list' and specific resource 'Poly Haven asset' are 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use, or compare with similar tools like polyhaven_get_asset or asset_list_sources. The agent must infer usage from the name and context alone.

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, openWorldHint, idempotentHint, destructiveHint. The description adds that results include explicit Poly Haven attribution, a useful behavioral detail for licensing. However, it does not describe pagination, sorting behavior, or error handling beyond what annotations imply.

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

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

Two sentences with no wasted words. The description is front-loaded with the action and includes an additional detail about attribution without verbosity.

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?

Despite an existing output schema, the description lacks explanation of how to use parameters like cursor, limit, and categories. It does not cover result structure, pagination, or typical usage patterns for a search tool.

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

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

Schema description coverage is 0%, but the description provides no parameter information beyond hinting at the 'type' parameter (HDRIs, textures, models). Six parameters remain unexplained, leaving the agent to infer from names 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?

The description clearly states the tool searches CC0 HDRIs, textures, and models from Poly Haven. It distinguishes from siblings by specifying the source (Poly Haven) and content type (CC0), and adds a unique detail about attribution in results.

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 guidance on when to use this tool versus alternatives like fab_search_assets or ambientcg_search_assets. The description does not provide context for selection based on asset source or licensing needs.

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 destructiveHint=false, so the description adds limited new behavioral insight. It confirms no credential storage and no file downloading, which is useful but not extensive. No contradiction with 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?

The description is two sentences long, front-loaded with the core purpose, and contains no extraneous information. Every sentence serves a clear function.

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

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

Given the tool has a single parameter and output schema, the description covers key aspects: token requirement, temporary URLs, and non-storage. It could mention the modelId's role but is otherwise sufficient for a simple 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 input schema has 0% description coverage and the description does not mention the 'modelId' parameter or its format. This fails to add meaning beyond the schema, which is especially problematic given the low coverage.

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 clearly states the tool retrieves temporary download URLs for a Sketchfab model using the user's API token, providing a specific verb-resource pair. This distinguishes it from sibling tools like sketchfab_search_models or sketchfab_get_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?

The description implies the tool requires a valid SKETCHFAB_API_TOKEN and clarifies that it does not store credentials or download files, giving context for when to use it. However, it does not explicitly exclude usage scenarios or compare with alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying what is returned (public metadata and Creative Commons requirements), beyond what annotations provide. No contradictions.

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 a single sentence that instantly conveys the action and target, with no filler or redundant information. Every word earns its place.

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

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

The tool has an output schema (covering return values), simple parameters, and the description states the retrieval scope. It is complete enough for this straightforward read operation.

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 compensate. It does not explain the modelId parameter beyond the schema's pattern, missing an opportunity to clarify its meaning or format.

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

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

The description uses a specific verb ('Get') and resource ('public metadata and explicit Creative Commons requirements for one Sketchfab model'), clearly distinguishing from sibling tools like sketchfab_search_models and sketchfab_get_downloads.

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

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

The description implies usage for retrieving a single model's metadata and license info, but it lacks explicit when-to-use guidance or comparisons with siblings. No exclusions or alternatives are mentioned.

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