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

No annotations are provided, so the description must carry the behavioral burden. It does state that the tool downloads and imports into Blender and returns a success/failure message. However, it does not disclose side effects like modifying the current Blender scene, network requirements, or whether the operation could overwrite existing objects. This is adequate but leaves gaps.

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 concise parameter block with examples, and a return-value note. It is front-loaded and every line adds value given the schema has no descriptions. The parameter list is slightly long but justified by the lack of schema documentation.

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?

All parameters are covered and the return behavior is stated, which is good for a tool with no output schema. However, the description omits useful context such as where asset_id comes from, whether the import modifies the existing scene, and any dependency on Blender being open. Given no annotations and no output schema, this is a clear gap.

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

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

The input schema has 0% description coverage, so the parameter list in the description is the primary source of semantic information. It provides meaningful examples and allowed values for asset_type, resolution, and file_format, including asset-type-specific formats. Asset_id is under-specified (only 'The ID of the asset to download'), but the overall parameter documentation compensates well for 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 opens with a specific verb and resource: 'Download and import a Polyhaven asset into Blender.' This clearly distinguishes the tool from siblings like search_polyhaven_assets (searching) and download_sketchfab_model (different source platform). No ambiguity about what this tool does.

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 makes it clear this is for Polyhaven assets, which implies when to use it versus Sketchfab or Hunyuan tools. However, it does not explicitly state when to prefer this over search_polyhaven_assets or set_texture, nor does it mention preconditions such as needing an asset_id from a prior search. Usage context is present but only implied.

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

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

With no annotations, the description carries the full behavioral burden and it does a good job: it discloses the scaling behavior, the requirement to provide a target size, the return message with import details, and access prerequisites. It does not mention edge cases or failure behavior, but the core side effects are 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 front-loaded with purpose and scaling behavior, then provides a focused parameter list with useful examples. It is slightly repetitive about target_size being required, but no sentence feels unnecessary.

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 (two parameters, no output schema), and the description covers the input semantics, the scaling behavior, prerequisites, and what the return message contains. It could add failure/edge-case behavior, but for its complexity 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?

Schema description coverage is 0%, but the description compensates well for target_size with units, requirement status, and concrete examples. The uid parameter is only described as 'the unique identifier,' which is thin but sufficient given the tool name and context. This is strong compensation for an otherwise 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 starts with a specific action ('Download and import a Sketchfab model by its UID') and clearly identifies the resource and key behavior. This distinguishes it from sibling Sketchfab tools like search_sketchfab_models and get_sketchfab_model_preview, which do not import.

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 that the tool requires a UID and target_size and that the model must be downloadable with proper access rights, which gives some context. However, it never explicitly says when to prefer this tool over alternatives such as search_sketchfab_models or import_generated_asset, so usage guidance is only implied.

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

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

With no annotations, the burden falls on the description. It does disclose that the tool can run arbitrary Python code, which implies broad power and risk, and the 'step-by-step' warning hints that long or complex executions need caution. However, it does not mention possible destructive scene mutations, absence of undo, execution limits, or error behavior, so the disclosure is only partially complete.

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 and front-loaded with the core purpose. The step-by-step instruction is useful, and the parameter note is simple. The phrase 'step-by-step by breaking it into smaller chunks' is slightly redundant, but overall the text is efficient 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?

For an arbitrary code execution tool with no annotations and no output schema, the description leaves important gaps: there is no indication of what the tool returns, how failures surface, what Python objects are available in scope, or whether the execution mutates the Blender scene permanently. The minimal description does not give an agent enough context to safely and correctly invoke this powerful tool in varied situations.

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. The line 'code: The Python code to execute' adds only marginally more than the schema property title 'Code' and the tool name itself. It does not explain expected code environment details such as whether Blender's bpy module is pre-imported, how results or errors are returned, or whether there are execution limits.

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 a specific action and resource: 'Execute arbitrary Python code in Blender.' The word 'arbitrary' signals this is a general-purpose escape hatch, and no sibling tool has the same role, so an agent can immediately distinguish it from the other scene, asset, and model-generation 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?

There is no guidance on when to prefer this tool over the many specialized sibling tools. The instruction to break work into smaller chunks is about how to structure execution, not about choosing this tool over alternatives. The only implied guidance is that 'arbitrary' means it can be used for tasks the other tools don't cover, but that is not made explicit.

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 full behavioral burden and does well: it discloses asynchronous job submission via job_id, eventual DONE status meaning the model has been imported, error returns, and built-in materials. Could mention scene impact, but key behavior is covered.

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

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

Well-structured with front-loaded purpose, a compact Parameters section, and a Returns section. Every sentence adds value with 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?

Provides enough context for a generation-and-import workflow: inputs, async behavior, success condition, and error handling. It does not explicitly point to poll_hunyuan_job_status for status checking, but the job_id and DONE status make the flow inferable.

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%, but the description fully compensates by defining text_prompt as an optional short English/Chinese description and input_image_url as an optional local/remote URL that accepts None. It also clarifies the relationship between the two: either text, image, or both.

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

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

States a specific action, resource, and method: generate a 3D asset using Hunyuan3D from text, image, or both, and import it into Blender. This distinguishes it from sibling generation tools like generate_hyper3d_model_via_text/images and from standalone 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?

Clearly indicates when to use the tool (Hunyuan3D generation with auto-import) and how to choose inputs (text, image, or both). It does not explicitly name sibling alternatives or state when-not-to-use, but the context is clear 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?

With no annotations, the description carries the behavioral disclosure burden. It usefully mentions built-in materials, normalized sizing that may require re-scaling, that the asset is imported into Blender, and that a success/failure message is returned. However, it does not disclose whether generation is asynchronous, whether a job ID is produced, or what side effects occur beyond the import, which could be significant for an agent deciding how to proceed.

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 clear one-line purpose, a few meaningful behavioral notes, and a bullet-like parameter section. Every sentence adds value without redundancy, and the most important invocation constraints are placed prominently.

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 key parameters and gives relevant behavioral context, but it does not explain how an agent can determine the current Hyper3D Rodin mode, what image requirements exist, or what the success/failure message contains. Since there is no output schema and sibling polling tools exist, the lack of async/job details leaves some ambiguity 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 input schema has 0% description coverage, so the description fully compensates. It explains that input_image_paths must be absolute paths, that single values must still be wrapped in a list, that the three-element bbox_condition controls Length/Width/Height ratio, and that the two input parameters are mutually exclusive based on the current mode. This is strong parameter-level 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 states a specific verb and resource: 'Generate 3D asset using Hyper3D by giving images' and 'import the generated asset into Blender.' It clearly distinguishes itself from the sibling text-based generation tool by emphasizing image input, so an agent can identify when this tool is relevant.

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 concrete guidance on parameter selection: input_image_paths is for MAIN_SITE mode, input_image_urls is for FAL_AI mode, and exactly one must be provided. It does not explicitly name alternative generation tools or state when not to use this tool, but the image-vs-text distinction is clear enough to infer the primary use case.

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 does well by disclosing that the tool imports the asset into Blender, that materials are built-in, that the model size is normalized and may need rescaling, and that it returns a success/failure message. It does not mention whether generation is asynchronous, whether it blocks, or how the imported object can be referenced afterward, but it provides substantial useful behavior context.

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: purpose and side effect first, then relevant model characteristics, then parameter details, then return value. Every sentence adds information, and there is no redundant restatement of schema fields or filler.

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

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

For a two-parameter tool with no annotations and no output schema, the description is nearly complete. It covers input semantics, generated asset characteristics, the Blender import side effect, and the return message. Minor gaps are lack of clarification about asynchronous behavior and how the agent can locate or reference the imported asset after success.

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's parameter notes are essential. It explains that text_prompt must be a short English description, and that bbox_condition is optional, must be a list of floats of length 3, and controls the Length/Width/Height ratio. This adds meaningful semantic detail beyond the raw schema, though ranges or a more precise ratio explanation would strengthen it further.

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'), the specific service (Hyper3D), the input mode (description/text), and the side effect (import into Blender). It also adds useful purpose details: built-in materials and normalized size. This clearly distinguishes it from image-based generation like generate_hyper3d_model_via_images, even though that sibling is not named.

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: when you have a textual description of a 3D asset and want it generated and imported into Blender. However, it does not explicitly contrast with generate_hyper3d_model_via_images, import_generated_asset, or the other generation tools. No when-not-to-use guidance or alternative selection 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?

No annotations are provided, so the description carries the full burden. It does disclose that the tool returns a message about Hunyuan3D feature availability, but it does not explain the message format, the meaning of 'key type,' or any side effects/auth requirements. The instruction to 'silently remember it' is ambiguous.

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 and the core purpose is front-loaded. However, the first two sentences are somewhat redundant ('Check if enabled' vs 'Returns message indicating whether available'), and the final sentence about not emphasizing the key type is unclear and may confuse rather than help.

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

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

For a zero-parameter status check with no output schema, the description gives enough to invoke the tool correctly: it checks Hunyuan3D integration and returns an availability message. The incomplete area is the vague 'key type' mention, but the low complexity keeps the gap minor.

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 input schema covers 100% of the parameter space. With no params, the description does not need to add param semantics beyond the baseline.

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

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

The description states a specific verb and resource: 'Check if Hunyuan3D integration is enabled in Blender.' It also specifies the return value as a message about feature availability. This clearly differentiates it from sibling status tools such as get_hyper3d_status and get_sketchfab_status by naming the Hunyuan3D integration.

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 use case is implied from the description: call it when you need to know whether Hunyuan3D is enabled. However, it does not explicitly mention alternatives or provide when-not-to-use guidance, relying on sibling names to distinguish which status tool to pick.

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 carry the behavioral burden. It does disclose that the tool returns a status message and includes an unusual instruction about not emphasizing the 'key type' and silently remembering it. However, 'key type' is undefined, and the description does not explicitly confirm the operation is read-only or mention any prerequisites or side effects.

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

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

The first two sentences are concise and front-loaded with the core purpose and return behavior. The third sentence about the 'key type' is short but confusing, contains a typo ('sliently'), and is not clearly connected to the rest of the description, preventing a higher score.

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

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

For a zero-parameter status tool with no output schema, the description gives the essential high-level behavior: it checks integration availability and returns a message. Still, the meaning of 'key type' is unexplained and no guidance is offered about what the agent should do with that remembered information, leaving some context incomplete.

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, so the schema already provides complete parameter information. The description adds no parameter details, but none are needed; this matches the baseline of 4 for tools with no 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 states a specific action ('Check if Hyper3D Rodin integration is enabled'), a specific resource ('in Blender'), and the expected result ('Returns a message indicating whether Hyper3D Rodin features are available'). This clearly distinguishes it from sibling tools like get_sketchfab_status and get_hunyuan3d_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 intended use is reasonably clear from the tool name and the phrase 'Hyper3D Rodin integration', and sibling tools imply alternatives for other services. However, there is no explicit guidance about when to prefer this tool over siblings or exclusions, so the usage guidance remains mostly 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?

With no annotations, the description is the only source for behavior. 'Get' implies a read-only operation, which is helpful, but there is no disclosure about errors, missing objects, or what 'detailed information' includes. This is adequate but leaves room for surprise.

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 and front-loaded with the core purpose, and the parameter note earns its place given the schema's lack of documentation. The parameter list is slightly redundant with the schema, but it does not waste 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 one-parameter tool, the description provides the essential calling information and a clear purpose. However, with no output schema, it does not clarify what 'detailed information' returns, leaving an agent without expectations about the response contents.

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 provides only the parameter name with no description (0% coverage), but the tool description adds a functional definition: 'object_name: The name of the object to get information about'. This meaningfully clarifies the sole parameter, though it does not address exact-name matching or behavior for nonexistent objects.

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 'detailed information', and the specific scope 'specific object in the Blender scene'. It distinguishes this from scene-level tools like get_scene_info, though it does not explicitly name or contrast 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?

No guidance is given about when to use this tool versus alternatives. Sibling tools like execute_blender_code or get_scene_info could overlap, but the description provides no exclusions or contextual 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 provided, so the description carries the burden. It accurately signals a read-only operation ('Get a list'), but it does not disclose return format, network dependency, or error behavior. For a simple list operation this is adequate but not rich.

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, with the core action front-loaded and a structured parameter list. However, the parameter list partially duplicates the schema, even though it adds the allowed values.

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 one optional parameter and no output schema, the description covers the main semantic need: what categories are for and the allowed asset types. It lacks an explicit return-format note, but 'list of categories' implies an array of names. Minor gap: no statement about the default when asset_type is omitted, though the schema covers this.

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's Parameters section provides the accepted values for asset_type (hdris, textures, models, all), which the schema omits. This adds critical meaning beyond the schema's bare string type and default.

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 'Get a list of categories for a specific asset type on Polyhaven' – a precise verb+resource. This clearly distinguishes it from siblings like search_polyhaven_assets, download_polyhaven_asset, and get_polyhaven_status, which concern asset search, download, and service 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?

No guidance on when to use this tool versus alternatives. It does not specify a workflow (e.g., fetch categories before searching assets) or any exclusions. The parameter list is not 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?

With no annotations, the description carries the full burden. It states the tool 'returns a message' about feature availability, which implies a read-only status query, but it does not disclose whether it queries Blender state or makes network calls, nor possible errors. The non-mutating nature is inferred from 'Check' rather than stated.

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

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

Two short sentences with no filler. The primary action is front-loaded, and the return behavior is separated in the second sentence.

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

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

For a zero-parameter status check, the description provides the essential purpose and return information. It lacks an explicit statement of the message format or error behavior, and no output schema compensates, so it is not fully specified.

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, so there is nothing to document. The baseline of 4 applies because schema coverage is complete and the description correctly says nothing about 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 uses the specific verb 'Check' with the resource 'PolyHaven integration in Blender', making the operation immediately clear. It names PolyHaven, distinguishing it from sibling status tools like get_sketchfab_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 implies the tool is a capability check but gives no explicit guidance on when to invoke it or when to prefer a sibling status tool. There is no mention of using it before PolyHaven asset operations or an alternative. This is acceptable but relies on inference.

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 must carry the full behavioral burden. 'Get' weakly implies a read-only operation, but it does not disclose what 'detailed information' contains, whether it errors under certain conditions, or whether it requires a valid Blender context. It provides very little beyond the tool name itself.

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

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

A single clear sentence with no filler or redundancy. The key components—verb, resource, and scope—are all present and front-loaded. Nothing extra needs to be trimmed.

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 zero-parameter tool with no annotations and no output schema, so the description is the only source of behavioral and return-value information. Saying only 'detailed information' leaves the agent uncertain about what fields or values will be returned, making the definition incomplete for a tool that provides scene info.

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 is empty, so there are no parameters to document. With a parameter count of 0, the baseline of 4 is appropriate because no parameter meaning needs to be added by the description.

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

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

The description states a clear verb ('Get') and resource ('current Blender scene'), making the basic purpose understandable. However, 'detailed information' is vague about exactly what scene data is included, and it does not explicitly differentiate from get_object_info, though scene vs. object is an implied distinction.

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 context is implied: use this when you need detailed scene-level information. But there is no guidance on when not to use it, no mention of alternatives like get_object_info, and no prerequisites such as requiring an open Blender scene or active session.

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 exist, so the description carries the full burden. It does disclose the return value ('thumbnail as an Image') and implies a non-destructive preview via 'visually confirm'. However, it does not explicitly state that this is a read-only operation, whether it makes a network request, or how failures are surfaced. For a simple preview tool this is acceptable but not thorough.

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-organized: one sentence for purpose, one for usage, one clear parameter line, and one for the return value. Every sentence earns its place with no filler.

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

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

The tool has one required parameter, no output schema, and simple semantics. The description covers the purpose, the parameter source, and the return type. Missing details like error cases, licensing implications, or the fact that no model data is fetched are minor for a preview thumbnail tool, but would make it even stronger.

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 crucial meaning to 'uid' by defining it as the unique Sketchfab model identifier and specifying its source (search_sketchfab_models). It stops short of giving format, example, or validation constraints, but for a single self-explanatory parameter this is solid.

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 ('Get') and resource ('preview thumbnail of a Sketchfab model'), and identifies the input (UID). It clearly distinguishes its role from sibling tools like download_sketchfab_model by framing it as visual confirmation before downloading.

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 explicitly instructs when to use the tool: 'Use this to visually confirm a model before downloading.' It also tells agents where the UID comes from (search_sketchfab_models), which is contextual guidance. It does not explicitly name alternatives or when-not-to-use cases, so it misses the top of the scale.

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 behavioral transparency burden. It does communicate a non-mutating status check and a message return, but it does not state whether the check is local-only or queries Sketchfab, nor any side-effect or error behavior. This is adequate but not rich.

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

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

Two short sentences, front-loaded with the purpose and followed by the return behavior. No filler or duplication beyond a mild redundancy between 'enabled' and 'available'.

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

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

For a zero-parameter status check with no output schema, the description covers the essential aspects: what is checked and what the caller receives. It could be more specific about the exact structure/form of the returned message, but nothing critical 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?

The tool has zero parameters, so there is nothing for the description to document. The schema already covers 100% of the empty parameter surface, earning the zero-parameter baseline of 4.

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 ('Sketchfab integration in Blender'), and clarifies the outcome ('Returns a message indicating whether Sketchfab features are available'). It is unambiguous and distinguishable from sibling status tools for other integrations by naming the exact integration.

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

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

Usage context is implied: an agent would call this when it needs to know whether Sketchfab is available in Blender. However, there is no explicit guidance about when not to use it, nor any comparison with sibling status tools like get_hyper3d_status or get_polyhaven_status.

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 the basic behavior (captures viewport, returns an Image) but does not mention whether the scene is modified, what image format is used, or any viewport/display requirements. For a screenshot tool this is adequate but not deeply 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 short and well-structured: a one-sentence purpose, a compact parameter definition, and a return note. Every part earns its place with no redundancy or filler.

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

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

For a simple tool with one optional parameter and no output schema, the description is nearly complete: it states what it captures, how max_size behaves, and that it returns an Image. Minor missing details like image format or whether overlays are included keep it from a 5.

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 single parameter. It does so effectively by explaining that max_size is 'Maximum size in pixels for the largest dimension' and noting the default. This adds meaning beyond the bare schema property.

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 clear, specific verb and resource: 'Capture a screenshot of the current Blender 3D viewport.' This unambiguously identifies the tool's function and distinguishes it from the generation/status/polyhaven/sketchfab siblings.

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

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

Usage is implied by the resource: use this when an image of the current Blender viewport is needed. However, there is no explicit guidance about when not to use it or how it relates to alternatives, though no sibling tool appears to provide the same screenshot capability.

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 does the work: it states the prerequisite ('after the generation task is completed'), the mode-dependent parameter behavior, and that it returns a success/failure indicator. However, it does not disclose side effects on the scene, such as whether importing with an existing name replaces or adds an object, nor does it describe error 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 tightly structured: one sentence of purpose, a bullet-style parameter list, a prominent mutual-exclusivity warning, and a return statement. Every line adds needed operational information with no filler.

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

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

For a simple three-parameter tool with no output schema, it covers the prerequisite, parameter meaning, mode-based selection, and return status. Minor gaps remain: the exact return type is not specified ('Return if...' could be read as 'whether' versus 'the asset'), and behavior when neither/both ID fields are supplied is only partially covered by the instruction.

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% coverage for parameter descriptions, but the tool description fully documents all three parameters: name as the scene object name, task_uuid for MAIN_SITE mode, request_id for FAL_AI mode, plus the critical rule that exactly one of the two IDs should be provided based 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 action and target: 'Import the asset generated by Hyper3D Rodin after the generation task is completed.' This clearly distinguishes the tool from the sibling import_generated_asset_hunyuan and from polling/status tools, so an agent knows exactly what this tool is for.

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

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

It gives a clear usage context: call after the generation task is completed, and choose task_uuid or request_id according to the Hyper3D Rodin mode (MAIN_SITE vs FAL_AI). It stops short of explicitly contrasting with alternative tools such as import_generated_asset_hunyuan, so it does not quite earn a 5.

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

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

With no annotations, the description carries the full transparency burden. It discloses the timing prerequisite and the return behavior ('Return if the asset has been imported successfully'), and the mutation is implied by 'import'. However, it does not mention failure modes, whether an existing object with the same name is overwritten, or any side effects on the current scene.

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, front-loaded with the main action, and uses a clear parameter list and return statement. Every sentence contributes; the only minor issue is slight redundancy between 'after the generation task is completed' and the parameter note about the generate step, but overall it is well-structured.

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

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

For a simple two-parameter tool with no output schema or annotations, the description covers the core purpose, parameters, timing, and return value. It is missing explicit edge-case behavior (e.g., invalid zip_file_url, generation not finished, duplicate names) and does not clarify the exact return format, leaving moderate gaps for an agent.

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 provide meaning for both parameters, and it does: 'name' is clarified as the scene object name, and 'zip_file_url' is explicitly tied to the generate model step. This adds practical semantics beyond the bare schema titles, though the URL format could be more precise.

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 ('Import') and names the exact resource ('asset generated by Hunyuan3D after the generation task is completed'), which clearly distinguishes it from other generation/import tools. However, it does not explicitly contrast itself with the sibling 'import_generated_asset', leaving some ambiguity about which import variant to use.

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 states a clear precondition ('after the generation task is completed') and references the 'generate model step' for obtaining zip_file_url, which gives an agent a concrete workflow. It does not explicitly name alternatives or when not to use this tool, but for a focused import tool this is adequate context.

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 burden of explaining behavior. It discloses the status values DONE and RUN, the ResultFile3Ds field on success, and the generated ZIP/OBJ path. The polling nature and 'only proceed if final' guidance are also transparent, though failure statuses remain vaguely described.

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 mostly clear and front-loaded, but it repeats the same DONE-result detail twice in slightly different wording ('If status is DONE, returns...' and 'When the status is DONE, the response includes...'). This redundancy weakens an otherwise reasonably sized description.

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 one-parameter polling tool with no output schema, the description covers the essential context: the source of job_id, meaningful statuses, and what the successful response contains. It does not enumerate all possible failed states, but 'some failed state' is sufficient for the agent to know when to stop polling.

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 provides no description coverage for job_id, so the description's explanation that job_id comes from the generate model step adds necessary semantic meaning. It could be stronger by stating whether the parameter is required, but the source and usage are clear enough for a single-parameter polling 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 checks whether a Hunyuan3D generation task is completed and explains the relevant statuses. It does not explicitly differentiate itself from get_hunyuan3d_status, though the polling-focused wording and name provide some distinction.

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 indicates this is a polling API and tells the agent to proceed only when the status is final, which gives useful context. However, it does not describe when to prefer this tool over get_hunyuan3d_status or other status-checking siblings, nor does it state explicit exclusions.

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

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

With no annotations, the description carries the full burden. It discloses that this is a polling API, explains expected status values, final versus in-progress states, and failure conditions. It does not cover error handling or whether the call blocks, but it provides substantial behavioral context.

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 with mode sections and bulleted parameters. The purpose is front-loaded, and each status and guideline is relevant. Minor redundancy in the polling warnings is acceptable given the two-mode structure.

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-mode polling tool with no output schema and no annotations, the description covers the main behavioral contract: statuses, final states, and mode-specific inputs. It does not explain how to determine which mode applies or how to handle API errors, but it is largely complete for normal 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 input schema has zero description coverage, so the description compensates by explaining that subscription_key belongs to MAIN_SITE and request_id belongs to FAL_AI, and that both come from a previous generate step. It could add format or requiredness details, but it gives enough meaning to choose the right parameter per 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 clear verb and resource: 'Check if the Hyper3D Rodin generation task is completed.' It also distinguishes the two Rodin modes, but does not explicitly differentiate this polling tool from the sibling get_hyper3d_status, so it stops short of a perfect score.

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 mode-specific instructions and explicitly states when to proceed based on final statuses ('Done', 'Canceled', 'COMPLETED', or failed states). It does not name alternative tools or when not to use this one, but the polling guidance is clear and actionable.

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 correctly conveys a read-only search operation and states that it 'Returns a list of matching assets with basic information', which is useful context. However, it does not mention pagination, result limits, required authentication, or that actual asset files are not downloaded by this 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 compact and front-loaded with the core purpose. The parameter list is minimal and useful, and the return statement is a single line. No redundant prose or filler exists.

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 only two optional parameters and no output schema, the description covers the basic call contract. However, 'basic information' is vague about the exact return fields, and it does not tell the agent that valid category values can be obtained from get_polyhaven_categories. These are notable gaps given there is no output schema.

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

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

Schema description coverage is 0%, so the description must compensate. It does so well by documenting asset_type with its allowed values (hdris, textures, models, all) and categories as an 'optional comma-separated list'. This adds real meaning beyond the bare schema property 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 opens with a specific verb and resource: 'Search for assets on Polyhaven'. Combined with the asset_type values (hdris, textures, models, all), it clearly distinguishes this tool from sibling search tools like search_sketchfab_models and from download/category 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 the tool should be used when the agent needs to discover Polyhaven assets, and it mentions optional filtering. However, it does not explicitly contrast with siblings such as get_polyhaven_categories or download_polyhaven_asset, nor does it state when not to use 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?

With no annotations, the description carries the burden of behavioral disclosure. It mentions that the tool returns a formatted list of matching models, which is helpful, but it does not disclose whether it calls an external API, potential rate limits, pagination behavior, or error conditions. The read-only nature is implied by 'search' but not made explicit.

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 clean bullet-style parameter list. Every sentence adds value and there is no redundant or filler content.

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

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

The parameter documentation is complete, but the return value is only described as a 'formatted list', which is vague given that no output schema exists. Missing details include what fields each model entry contains, how categories combine, and what happens on errors or empty results. It is adequate for a basic search tool, 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 schema description coverage is 0%, but the description compensates fully by explaining every parameter: query text, comma-separated categories, maximum result count, and downloadable filtering. This goes well beyond the bare schema definitions and gives the agent actionable 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 action ('Search for models on Sketchfab') and the resource, making the tool's purpose immediately understandable. It does not explicitly contrast itself with sibling tools, but the verb 'search' naturally distinguishes it from download, preview, and status 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 opening sentence gives clear context for when to use the tool: to search Sketchfab for models. It does not provide explicit exclusions or alternatives, but the sibling tool names make it evident that this is the search step before downloading or previewing.

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 must carry the behavioral burden. It discloses the prerequisite of a prior download and states that the tool returns a success/failure message. However, it does not explain what happens on failure, whether existing textures are replaced, or whether the object must exist, leaving moderate behavioral gaps.

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, front-loaded with the main purpose, and structured cleanly into purpose, parameters, and return behavior. There is no filler or redundant content beyond what is needed given the 0% schema coverage.

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

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

For a simple two-string-parameter tool, the description covers the essential inputs, the prerequisite, and the return behavior. It could be slightly more complete by noting that the object must exist or that the operation may overwrite the object's current texture, but the core invocation context is present.

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 fully define the parameters. It does exactly that: object_name is the target object and texture_id is the already-downloaded Polyhaven texture ID. This adds the necessary meaning that the bare schema property names omit.

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 starts with a specific verb-plus-resource statement: 'Apply a previously downloaded Polyhaven texture to an object.' The 'previously downloaded' qualifier clearly distinguishes this from the sibling download_polyhaven_asset and makes the scope of the tool immediately clear.

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 a clear usage condition: the texture 'must be downloaded first.' This implies the correct sequence with download_polyhaven_asset, but it does not explicitly name that sibling or state when not to use this tool, so it falls just short of full alternative routing guidance.

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