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

With no annotations provided, the description carries the full burden for behavioral disclosure. It only states 'Download and import into Blender' and 'Returns a message', but does not disclose potential side effects (e.g., modifying the Blender scene, network access), required permissions, or error conditions.

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 concise and well-structured, with a brief purpose statement followed by a clearly labeled parameter list and a return-value note. No filler or redundant text; it earns its place without unnecessary 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?

For a 5-parameter tool with no annotations and no output schema, the description covers purpose, parameters, and return value, but lacks usage context and behavioral details like when to use or what happens during import. It is minimally viable but has clear 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?

Despite 0% schema description coverage, the description includes a parameter list with examples (e.g., '1k, 2k, 4k' for resolution, 'hdr, exr' for HDRIs), adding semantic meaning beyond the bare schema property names.

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 'Download and import a Polyhaven asset into Blender' uses a specific verb (download/import) and resource (Polyhaven asset into Blender), clearly distinguishing it from sibling tools like search_polyhaven_assets or get_polyhaven_categories.

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

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

There is no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when to prefer other tools, or any exclusion scenarios, leaving the agent to infer usage only from the name.

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?

With no annotations, the description carries the full burden. It discloses key behaviors: scaling to target_size, returning import details (object names, dimensions, bounding box), and the requirement that the model must be downloadable with proper access. It does not mention scene modification side effects or error handling, but for an import tool, this is reasonably transparent.

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 well-structured with a clear opening statement, a scaling note, a parameter list with examples, and return info. The examples for target_size are valuable despite adding length. It is concise enough while providing necessary details, with no 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's moderate complexity (3 params, scaling, import details), the description covers the essential aspects: what it does, scaling behavior, return message, and access requirements. It misses the user_prompt param and doesn't discuss error scenarios, but for an import tool with no output schema, it is adequately complete.

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 thoroughly explains uid and target_size, including detailed examples for target_size. However, it completely omits the user_prompt parameter (present in the schema), leaving a gap. Since not all parameters are described, it only partially compensates for the missing schema descriptions.

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 and import a Sketchfab model by its UID.' It specifies the verb (download/import), the resource (Sketchfab model), and the key identifier (UID). It also mentions scaling behavior, which distinguishes it from sibling tools like search or preview.

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 (you need a UID and want to import a model) but does not explicitly compare to alternatives such as search_sketchfab_models or get_sketchfab_model_preview. It does provide context about scaling and access rights, but it lacks an explicit 'use this when you have a UID' or 'use search to find UIDs' 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?

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only says code is executed in Blender and recommends step-by-step execution; it does not disclose potential side effects, scene mutation, undo behavior, error handling, or that arbitrary code can be destructive. This is a significant transparency gap for an arbitrary-code-execution tool.

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

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

The description is brief and front-loaded with the core purpose in the first sentence. The parameter list is concise and contains no filler, though the step-by-step advice could arguably be moved elsewhere without losing 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?

For an arbitrary code execution tool with no annotations and no output schema, this description is critically incomplete. It omits execution environment details, return format, failure modes, safety warnings, undo implications, and guidance on how this tool integrates with the rest of the Blender workflow. The minimal text leaves the agent without enough context to safely or effectively invoke the 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 compensate for missing parameter meaning. It restates 'code' as 'The Python code to execute' and adds that 'user_prompt' is 'for telemetry,' but it does not explain execution context, available Blender modules, expected return values, or how the telemetry parameter affects behavior. The added value over the raw schema is minimal.

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 ('Execute') and resource ('arbitrary Python code in Blender'), making the tool's function immediately clear. It is distinct from all sibling tools, which are specialized for asset retrieval, scene inspection, or generation.

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 only usage guidance is 'Make sure to do it step-by-step by breaking it into smaller chunks,' which is a how-to instruction rather than a when-to-use statement. There is no mention of when to prefer this tool over sibling tools or which operations are better handled by specialized 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?

With no annotations provided, the description carries full burden. It discloses asynchronous behavior (returns job_id indicating task in progress), completion semantics (status changes to DONE when imported), error handling, and built-in materials. This goes beyond simple mutation and gives the agent an accurate picture of the tool's lifecycle.

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 well-structured: a one-sentence purpose, a short note on materials, a focused parameter list, and a clear return/status list. Every sentence earns its place; no fluff or repetition of schema defaults.

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 main flow (generation, async job, completion, import), which is good for a tool with no output schema. However, it could be more complete by referencing how to check job status (e.g., poll_hunyuan_job_status) and by documenting the missing user_prompt parameter. Given the tool's complexity, this is a minor gap but not fatal.

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 adds meaning for text_prompt and input_image_url, but entirely omits the third schema parameter 'user_prompt'. This is a significant gap: the agent knows how to fill two of three fields, but has no guidance for the third. Partial compensation, not complete.

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 ('Generate') and a specific resource ('3D asset using Hunyuan3D'), and explicitly notes the result is imported into Blender. This differentiates from sibling tools like generate_hyper3d_model_via_text and import_generated_asset_hunyuan.

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 clearly indicates the tool is used for generating Hunyuan3D assets from text and/or image, and that it also imports into Blender. While it doesn't explicitly mention alternatives or when not to use it, the context implies differentiation from Hyper3D generation tools and separate import tools. This meets 'clear context, no exclusions' level.

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?

No annotations are provided, so the description carries the full burden. It discloses key behaviors: the model has built-in materials, the generated model has a normalized size (implying potential re-scaling is needed), and it imports into Blender. It does not mention error scenarios or side effects beyond a success/failure message, but the core behaviors are covered adequately.

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 structured with a brief intro sentence followed by bullet-point-like parameter details. Every sentence earns its place: it covers purpose, output characteristics, parameter semantics, and usage constraint without fluff. It is compact yet complete.

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

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

There is no output schema, but the description states it 'Returns a message indicating success or failure.' It covers the necessary context for a generation tool: input modes, size normalization, and Blender import. It omits details like expected processing time or network requirements (which might be derived from mode), but given the tool's complexity and the rich parameter explanation, it is nearly complete.

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 zero parameter descriptions, so the description must explain each. It does so thoroughly: 'input_image_paths' and 'input_image_urls' are described as absolute paths and URLs, with format and mode requirements. 'bbox_condition' is explained as a list of ints of length 3 controlling the Length/Width/Height ratio. While 'user_prompt' is not explicitly described, it is optional and has a default; the description still adds substantial meaning well beyond schema field names.

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's function: 'Generate 3D asset using Hyper3D by giving images of the wanted asset, and import the generated asset into Blender.' It specifies the verb (generate), resource (Hyper3D), and action (import into Blender), and distinguishes itself from the text-based sibling by the input type (images vs. text).

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

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

The description explicitly states when to use which input mode: 'Required if Hyper3D Rodin in MAIN_SITE mode' and 'FAL_AI mode', and enforces mutual exclusivity: 'Only one of {input_image_paths, input_image_urls} should be given at a time, depending on the Hyper3D Rodin's current mode.' It also provides the needed condition for bbox_condition. This gives clear and decisive usage 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?

The description discloses that the asset has built-in materials and normalized size, and that it imports into Blender. However, it does not mention side effects like whether it replaces existing objects or requires permissions. With no annotations, this partial transparency leaves some ambiguity.

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 concise and well-structured: two sentences of overview followed by a bulleted parameter list. It avoids redundancy and is easy to parse.

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 output schema, the description does not need to explain return values, but it omits important context such as expected side effects on the Blender scene (e.g., whether it adds a new object) and the meaning of user_prompt. This makes it adequate but not fully complete.

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 explains text_prompt and bbox_condition (e.g., 'Controls the ratio between [Length, Width, Height]'), adding value beyond the schema. However, it omits the third parameter (user_prompt) entirely, so coverage is incomplete.

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's purpose: 'Generate 3D asset using Hyper3D by giving description of the desired asset, and import the asset into Blender.' It distinguishes from siblings like generate_hunyuan3d_model by explicitly mentioning Hyper3D and the dual generation+import action.

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 does not specify when to use this tool versus alternatives (e.g., generate_hunyuan3d_model). It only hints at usage with 're-scaling after generation can be useful,' but lacks explicit guidance on selection criteria.

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

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

No annotations are present, so the description carries full behavioral burden. It does disclose the return type ('message indicating whether Hunyuan3D features are available') and frames this as a non-mutating check. However, it doesn't clarify whether the function ever enables anything, what happens if Blender isn't running, or what the message structure looks like. Acceptable baseline disclosure, but with no annotations, more depth would help.

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 front-loaded sentences, zero wasted words. The description efficiently conveys the check subject, the environment, and the output behavior.

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 low complexity (one assertion, simple message return, no output schema, no nested objects), the description covers the essentials: what's checked and what's returned. The completeness is dragged down by the completely unexplained user_prompt parameter, which an agent must somehow resolve. Adequate but with a visible gap.

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

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

Schema description coverage is 0% and the description makes no mention of the user_prompt parameter, whose purpose is genuinely confusing for a status check. An agent given this description cannot tell whether to provide a prompt, why it defaults to an empty string, or what behavior changes if it's populated. Since the schema provides no help and the description adds zero clarification, this is a significant failure.

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 ('Check') and resource ('Hunyuan3D integration in Blender') and clearly distinguishes this from sibling tools like get_hyper3d_status and get_polyhaven_status by naming the specific integration. The outcome ('whether Hunyuan3D features are available') makes the tool's scope 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 purpose implies this is a pre-flight check before using Hunyuan3D generation features, giving clear contextual timing. However, there's no explicit when-to-use-vs-alternatives guidance, and no mention that siblings like poll_hunyuan_job_status serve a different phase of the workflow. The usage context is implied rather than stated.

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

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

No annotations are provided, but the description explicitly says it 'checks' and 'returns a message', indicating a read-only operation. It does not mention failure modes or side effects, but for a status check this is acceptable.

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 concise, consisting of two clear sentences that convey the tool's function without unnecessary detail.

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 main function and output, but omits any explanation of the 'user_prompt' parameter, which is a significant gap for a status-checking 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 schema includes a 'user_prompt' parameter, but the description does not explain its purpose or why a status check would need it. This leaves the parameter's 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 checks if Hyper3D Rodin integration is enabled and returns a message about availability. It is distinct from sibling tools that generate or download models.

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 checking integration status, but it does not explicitly state when to use it over alternatives. However, the purpose is clear enough for an agent to infer usage.

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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'Get detailed information' and does not state that the operation is read-only, whether it can fail, or what exactly is returned. This is a minimal but not fully transparent description.

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 main description is one clear sentence, followed by concise parameter annotations. No redundant words or filler; every sentence earns its place. The structure is front-loaded and easy to scan.

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 (one required parameter, no output schema, no annotations), the description is adequate but minimal. It defines purpose and parameters, but does not describe the return value structure or any edge cases, leaving the agent partially in the dark about what to expect.

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 compensates by explaining both parameters: object_name clarifies the target object, and user_prompt explains its telemetry purpose. This adds meaning beyond the property titles in the schema, though it could give more detail on object name lookup.

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') and resource ('detailed information about a specific object in the Blender scene'), distinguishing it from siblings like get_scene_info. It lacks a fuller explanation of what 'information' includes, but the core purpose is 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?

No guidance is given on when to use this tool versus alternatives such as get_scene_info or execute_blender_code. The description implies usage for object-level queries but offers no exclusions, prerequisites, or comparisons.

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?

With no annotations provided, the description carries the full burden. It clearly indicates this is a read-only retrieval operation ('Get a list'), but it does not disclose details such as network dependency, potential rate limits, caching, or error behavior. For a simple list endpoint, this is adequate but not comprehensive.

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 highly concise: one purpose sentence followed by a clear, minimal parameter list. Every element earns its place, and the most critical information (what the tool does) 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?

For a tool with two parameters and no output schema or annotations, the description provides all essential information: purpose, asset_type choices, and user_prompt semantics. The lack of any note about return format or when this might be called in a workflow is a minor gap, but overall the description is sufficient.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining both parameters: asset_type with its allowed enum-like values (hdris, textures, models, all) and user_prompt with its telemetry purpose. This adds significant meaning beyond the bare schema names and defaults.

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+resource construction ('Get a list of categories for a specific asset type on Polyhaven') and clearly distinguishes this tool from siblings like search_polyhaven_assets or download_polyhaven_asset. The asset_type parameter options (hdris, textures, models, all) further clarify its 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?

There is no explicit guidance on when to use this tool versus alternatives, nor any mention of exclusions or prerequisites. The intended use case is only implied by the tool's name and purpose, which is not sufficient for a dedicated usage guideline dimension.

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 indicates a read-only check ('Check if' and 'Returns a message') without stating side effects or permissions. Since no annotations are present, it partly relies on implication, but it is likely safe.

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 concise—two sentences with no redundant information. It efficiently conveys the tool's purpose and output.

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 function and return type (a message) but omits details about the output format and the meaning of the user_prompt parameter. The overall context is incomplete for a full understanding.

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

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

The sole parameter 'user_prompt' has no description, and its purpose is entirely unclear. The schema provides no details, and the description does not mention it, leaving it unexplained and likely unused.

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 checks if PolyHaven integration is enabled in Blender, which is specific and distinct from other status tools like get_hyper3d_status or get_sketchfab_status.

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 checking PolyHaven availability) but does not explicitly contrast with alternatives or provide conditional guidance. It is somewhat clear but lacks explicit direction.

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?

No annotations are present, so the description carries the full burden of disclosing side effects or behavioral traits. It only says 'Get' which implies read-only, but does not explicitly state that the operation is non-destructive, does not modify the scene, or has any telemetry side effects beyond the user_prompt parameter (which is not mentioned in the description).

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 communicates the tool's purpose without unnecessary words 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?

The description is minimal and does not specify what 'detailed information' includes or what the return format is. Since there is no output schema, the description should ideally explain the nature of the returned data, but it does not. This is a significant gap for a getter tool.

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

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

The tool description does not mention parameters, but the input schema provides a complete description for the single parameter 'user_prompt' (required for telemetry). Since schema coverage is 100%, the baseline of 3 applies, and the description adds no additional meaning.

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's function: 'Get detailed information about the current Blender scene.' This is a specific verb+resource (get + scene info) and distinguishes it from sibling tools that deal with textures, models, or other 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 provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or situations where this tool is preferred over siblings. It simply states what it does.

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?

No annotations are provided, so the description must convey behavior. It mentions retrieving a thumbnail and its purpose but does not state whether the operation is read-only or any side effects. It is fairly transparent for a simple read operation.

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 concise with two clear sentences, avoiding unnecessary details while covering the essential purpose and usage.

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?

It adequately describes the return value as an Image for visual confirmation. For a simple tool, it provides enough context, though it lacks potential error scenarios or prerequisites. Given the simplicity, it is reasonably complete.

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 explains the 'uid' parameter as the identifier obtained from search_sketchfab_models, adding meaningful context beyond the schema. However, the 'user_prompt' parameter is left unexplained, leaving a gap in 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?

Clearly states it retrieves a preview thumbnail for a Sketchfab model, specifying the action and resource. It distinguishes from sibling tools like search_sketchfab_models and download_sketchfab_model by focusing on preview retrieval.

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 to use it to visually confirm a model before downloading, providing a clear use case. It does not mention when not to use it, but the guidance is sufficient for the intended purpose.

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?

With no annotations provided, the description must carry the behavioral burden. It discloses that this is a read-only status check and that it returns a message, but it does not clarify whether any network request occurs, whether authentication is needed, or what the exact return format looks like. For a simple status check this is acceptable but not detailed.

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 short, front-loaded sentences with no filler. Every phrase contributes meaning, and it is appropriately sized for a simple status-check tool.

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

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

The tool is simple and the description adequately covers its core purpose and return type, but the unexplained user_prompt parameter creates a completeness gap. An output schema is not present, so the description's mention of returning a message is useful, yet the parameter semantics remain underspecified.

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, user_prompt, has 0% schema description coverage and is not mentioned in the tool description at all. The description does not clarify why the parameter exists, how it affects the status check, or what values are expected, leaving the agent to guess.

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 checks whether the Sketchfab integration is enabled in Blender and returns a message about feature availability. It uses a specific verb+resource structure that distinguishes it from sibling status tools like get_polyhaven_status and get_hyper3d_status.

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, such as search_sketchfab_models or download_sketchfab_model. There are no explicit conditions, prerequisites, or with/without contexts mentioned.

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?

With no annotations, the description should disclose side effects and limitations. It mentions the return type but does not elaborate on potential failures, impact on the scene, or whether the screenshot is taken in background. It adds some transparency but not comprehensive.

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 concise and well-structured: it starts with the purpose, then lists parameters, and ends with the return type. It is front-loaded and avoids unnecessary detail.

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

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

For a simple tool with two parameters, the description covers the basics, but the default value mismatch and lack of error handling make it incomplete. It does not mention any conditions under which the tool might fail or any additional 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?

The description explains both parameters, which is necessary since the schema lacks descriptions. However, there is a contradiction: the description states max_size default is 800 while the schema says 1000, which could mislead the agent. It adds meaning but with a flaw.

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 captures a screenshot of the Blender viewport with a specific verb and resource, distinguishing it from other tools in the list. It is not a tautology and provides a clear action.

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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or conditions. The usage is implied (if you need a screenshot of the viewport), but no alternatives are named.

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?

With no annotations provided, the description carries the full burden. It discloses that it returns a success indicator ('Return if the asset has been imported successfully') and enforces a parameter exclusivity constraint. However, it does not describe side effects (e.g., scene modifications), failure modes, or necessary preconditions, leaving some ambiguity for a mutation-like operation.

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 concise, structured with a parameters list and a note on exclusivity. Every sentence provides value: purpose, parameter explanations, and usage constraint. No fluff or 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?

For a simple 3-parameter tool with no output schema, the description covers the essential aspects: target resource, when to use, parameter semantics, and return status. It could be more explicit about prerequisites (e.g., an active scene) but is sufficiently complete given 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?

Schema coverage is 0%, so the description must compensate, and it does thoroughly. It explains 'name' as the object name in scene, and crucially distinguishes 'task_uuid' (for MAIN_SITE mode) from 'request_id' (for FAL_AI mode), including the conditional rule that only one should be provided. This adds significant meaning beyond the bare 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 'Import' and the resource 'asset generated by Hyper3D Rodin after the generation task is completed'. It distinguishes from the sibling 'import_generated_asset_hunyuan' by specifying 'Hyper3D Rodin', making the purpose 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 explains when to use the tool ('after the generation task is completed') and provides explicit usage guidance on parameter selection: 'Only give one of {task_uuid, request_id} based on the Hyper3D Rodin Mode!'. It does not explicitly mention alternatives or when not to use, but the context is clear enough for an agent to select correctly.

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?

With no annotations, the description carries the full burden of transparency. It mentions the return value ('Return if the asset has been imported successfully') but does not clarify side effects, error handling, or whether the import modifies or replaces existing assets. The lack of detail on failure modes or permissions leaves behavioral ambiguity.

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 concise and well-structured, with a clear purpose statement followed by a simple parameter list and return hint. No unnecessary words or redundant 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?

The description explains the tool's purpose, usage timing, and return value, which is adequate for a straightforward import operation. It does not elaborate on exception cases or specific outcome details, but given no output schema, it sufficiently conveys the expected result.

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 provides explicit meanings for both parameters: 'name: The name of the object in scene' and 'zip_file_url: The zip_file_url given in the generate model step.' Since the schema offers no descriptions, this covers 100% of parameters, adding necessary semantic clarity.

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's purpose: 'Import the asset generated by Hunyuan3D after the generation task is completed.' It specifies the resource (asset) and action (import) and differentiates from siblings like generate or poll by focusing on importing a generated 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 temporal guidance ('after the generation task is completed') and ties the zip_file_url to the generation step ('given in the generate model step'), which implies when to use this tool. It does not explicitly mention alternatives, but the context is sufficient for typical usage.

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?

With no annotations provided, the description carries full behavioral disclosure burden. It discloses the possible statuses ('DONE', 'RUN', and a failed state), states that it returns ResultFile3Ds on success, and identifies itself as a polling API. This is transparent for a read-only status check, though it could mention error handling or timeout behavior.

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

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

The description is redundantly worded. It repeats the ResultFile3Ds information twice: once in a bullet point and again in a separate sentence. The overall structure mixes bullet points and prose, making it less scannable. It could be trimmed to two or three concise sentences without losing 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?

For a simple polling tool with one parameter and no output schema, the description adequately covers what the tool returns (status and optional result path), how to interpret statuses, and when to stop polling. It lacks explicit examples of failure states or timeout guidance, but these are minor gaps given 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 only defines job_id as a string with no description, and schema description coverage is 0%. The description compensates fully by explaining that job_id is 'the job_id given in the generate model step', providing precise provenance and context for the 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's purpose: checking if a Hunyuan3D generation task is completed. It uses a specific verb ('check'), names the resource ('Hunyuan3D generation task'), and distinguishes it from sibling tools like poll_rodin_job_status or get_hunyuan3d_status by explicitly mentioning Hunyuan3D and its polling nature.

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 practical usage guidance: it explains that this is a polling API and instructs to 'only proceed if the status are finally determined'. It also tells when the result is ready (when status is 'DONE'). However, it does not explicitly mention when not to use this tool or point to alternative tools like get_hunyuan3d_status, so it misses a clear exclusion.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It discloses mode-specific statuses, progress states, failure conditions, and terminal states: 'Done', 'Canceled', 'COMPLETED', 'IN_PROGRESS', and 'IN_QUEUE'. It does not describe exact response shape or polling timeout/block behavior, but the core decision logic is clear.

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 well organized into two mode sections with clear parameter and status explanations. It is still reasonably tight, though the 'polling API, so only proceed' caution is repeated in both sections, which slightly reduces 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?

Given the absence of annotations and output schema, the description covers the important status logic, failure conditions, and decision rule with enough clarity for an agent. It is slightly incomplete because it does not differentiate itself from the sibling get_hyper3d_status tool or describe the response structures in more detail.

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 contains two arbitrary string fields with no descriptions and 0% schema coverage. The description compensates by explaining that subscription_key belongs to MAIN_SITE mode and request_id belongs to FAL_AI mode, both obtained from the generate step. It still does not explicitly state that exactly one parameter is required depending on mode.

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

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

The description opens with a specific verb-resource pair: checking whether the Hyper3D Rodin generation task is completed. It clearly separates behavior across MAIN_SITE and FAL_AI modes, which makes the tool's role in the generation pipeline obvious and distinguishes it from sibling generation/import 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 gives useful usage context: it is a polling API, should be called when checking generation status, and should only proceed when terminal statuses are observed. However, it does not explicitly name alternatives such as get_hyper3d_status or describe when this tool is not appropriate.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a list of matching assets with basic information and mentions that user_prompt is for telemetry, which is useful behavioral context. However, it does not explicitly state whether the operation is read-only, safe to call, or if there are any side effects, rate limits, or additional behavioral quirks that an agent should know.

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

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

The description is compact and well-structured: a one-sentence purpose statement followed by a concise parameter list. There is no filler or redundancy; every word adds value. It is appropriately sized for the tool's simplicity.

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

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

For a simple search tool with three parameters and no output schema, the description is fairly complete. It states the return type (list of matching assets with basic information) and parameter semantics. Minor gaps remain, such as what 'basic information' includes or whether pagination/limits apply, but these are not critical for basic 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 no descriptions and 0% coverage, but the description fully compensates by explaining each parameter: asset_type lists its allowed values (hdris, textures, models, all), categories is described as 'optional comma-separated list', and user_prompt is clarified as the original prompt for telemetry. This adds significant meaning beyond the bare schema 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 the tool's function: 'Search for assets on Polyhaven with optional filtering.' It uses a specific verb ('search') and resource ('Polyhaven assets'), and the parameter list clarifies the scope. This distinguishes it from sibling search tools like search_sketchfab_models by explicitly naming the platform.

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 context (when you need to search Polyhaven assets) but does not explicitly state when to prefer this over alternatives, nor does it provide exclusions or comparisons to sibling search tools. The presence of sibling tools like search_sketchfab_models makes this distinction important, but the description relies on the tool name to convey it.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that a 'formatted list' is returned, but does not disclose whether this makes network calls, whether results are live, pagination behavior, error handling, or any rate limits or auth requirements.

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 concise and front-loaded with the core purpose, followed by a tidy parameter list and a one-line return summary. There is no filler or redundant elaboration; every line communicates 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?

Given the absence of an output schema and annotations, the description should more thoroughly explain the return format and any special search behavior. It also fails to document the user_prompt parameter, which is a clear gap in completeness for a moderately parameterized 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 meaningful semantics for four of the five parameters: query text, comma-separated categories, maximum count, and downloadable filter. However, it completely omits the user_prompt parameter that appears in the schema, so the semantic coverage is not complete.

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

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

The description opens with a specific action and resource: 'Search for models on Sketchfab with optional filtering.' This clearly distinguishes it from sibling tools like download_sketchfab_model and get_sketchfab_model_preview, which serve different purposes.

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 no explicit guidance on when to use this tool vs alternatives such as search_polyhaven_assets or download_sketchfab_model. Usage is only implied by the phrase 'Search for models on Sketchfab'; there are no context cues, exclusions, 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?

No annotations are provided, so the description carries the full burden. It tells us it mutates an object by applying a texture and returns a simple success/failure message. However, it doesn't disclose important behavioral traits like whether the operation is undoable, whether it overwrites existing materials, or what failure conditions exist. It doesn't contradict annotations, but it's a minimal description for a mutation tool.

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

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

The description is brief, with a clear one-sentence summary, a short parameter list, and a note about the return value. Every sentence earns its place without extraneous 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?

For a straightforward apply operation, the description is mostly complete. It explains the prerequisite (texture downloaded), the parameters, and a brief note on the return value. However, it lacks details on edge cases and the 'user_prompt' parameter remains unexplained. It's adequate but leaves some gaps for a tool with three parameters and no annotations.

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 does explain both parameters in the text. It adds meaning beyond the schema by stating that texture_id is a Polyhaven texture and that it must be downloaded first. However, it fails to explain the third parameter, 'user_prompt', which is in the schema but not mentioned in the description. This omission is a gap.

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

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

The description uses a specific verb+resource: 'Apply a previously downloaded Polyhaven texture to an object.' It clearly indicates the action (apply), the resource (Polyhaven texture), and the target (an object). This is unambiguous and distinguishes it from the many sibling tools, which deal with searching, downloading, or generating models.

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 specifies 'previously downloaded' and 'must be downloaded first', giving clear context that the texture must already be downloaded. It doesn't explicitly mention alternatives, but the sibling list shows many related tools. It also doesn't state when NOT to use this tool, though the exclusion is logically implied by the download-first requirement. The description clearly explains the context but omits an explicit alternative.

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