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

With no annotations, the description must carry the full behavioral burden. It states the basic action (download and import) and the return value, but omits details like scene modification side effects, network requirements, or potential conflicts. This is adequate but not rich, hence a 3.

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 efficiently structured: purpose sentence, parameter list, return message. No filler 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 4-parameter tool with no annotations and no enums, the description provides strong coverage of parameters and return. It could mention prerequisites (e.g., need a valid asset_id from search) but the core operation is fully described.

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 lists all four parameters in detail, including valid asset_type values, resolution examples, and format suggestions per asset type. Schema coverage is 0%, so this description fully compensates, earning a 5.

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 phrase 'Download and import' with a clear resource ('Polyhaven asset') and target ('into Blender'), distinguishing it from sibling search/category/status tools and other asset downloaders.

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

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

It clearly states the tool's purpose: to download and import a Polyhaven asset. It does not explicitly mention when not to use it or point to siblings, but the context is unambiguous, so it earns a 4 rather than a 3.

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 the tool returns a success/failure message and requires downloadability and access rights. However, it does not explain side effects of the 'import' action, such as whether it modifies the scene, whether it is reversible, or whether it creates a duplicate asset.

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: purpose first, then parameter list, then return and requirements. Every sentence 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 simple one-parameter tool, the description covers the essential information: what it does, the parameter, the return value, and prerequisites. However, it could be more complete by explaining the relationship to sibling tools (e.g., searching for UIDs) and clarifying the destination of the imported model.

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 for the uid parameter (0% coverage), so the description compensates by explaining it as the unique identifier of the Sketchfab model. While it lacks examples or format details, it adds meaning beyond the bare schema type.

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

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

The description clearly states the tool downloads and imports a Sketchfab model by its UID, using a specific verb and resource. It distinguishes itself from sibling tools like search_sketchfab_models (which finds UIDs) and get_sketchfab_status (which checks 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?

The description provides context on when to use the tool: when you have a UID and proper access rights, and the model must be downloadable. However, it does not explicitly mention alternatives or when not to use this tool, such as using search_sketchfab_models to first obtain a UID.

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 discloses that the tool executes arbitrary code, which implies potential side effects, but it does not warn about dangers, failure modes, or effects on Blender scenes. The step-by-step hint is a recommendation rather than a description of tool behavior, leaving significant transparency 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 two sentences, front-loaded with the core purpose, and includes a brief, practical tip. There is no fluff or repetition, making it appropriately concise and 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?

The tool has an output schema, so return values need no explanation. The description covers the core action and provides a step-by-step safety tip, which is useful. However, given the complexity of arbitrary code execution, more context such as Blender environment details (e.g., pre-imported modules, potential timeouts) would make it more complete, so it settles at an adequate but not comprehensive level.

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 add meaning. It says 'code: The Python code to execute', which simply restates the parameter name and suggests no additional details about format, execution environment, or restrictions. This adds minimal value beyond the schema's title, failing to compensate for the lack of 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 'Execute arbitrary Python code in Blender', which uses a specific verb ('execute'), identifies the resource ('Blender'), and conveys that this tool runs any Python code. It distinguishes itself from sibling tools by being the only one that directly executes custom code, making its 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 gives clear context: it is for running arbitrary Python code in Blender, implying use when other specific tools are insufficient. It also provides a directive to break execution into smaller chunks, which serves as a practical usage guideline. However, it does not explicitly mention when not to use it or name alternative tools, so it slightly misses the top score.

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 asynchronous nature (returns job_id, status changes to DONE), the auto-import into Blender, built-in materials, and error handling. It does not cover rate limits or authentication, but these are less critical for a generation tool. Overall, it provides solid transparency.

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 Purpose, Parameters, and Returns sections. Every sentence adds value, with no fluff or redundancy. It is appropriately sized for the tool's complexity.

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 full workflow: generation, import, job status, and success criteria. It includes return format and error handling. It could explicitly mention that the agent may need to poll for status, but the job_id and status change description imply this. Given two optional parameters and an output schema, this 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?

Schema coverage is 0%, and the description fully compensates by explaining each parameter: text_prompt is optional, short, and supports English/Chinese; input_image_url accepts local or remote URLs and None when only using text. This adds meaningful usage guidance beyond the raw schema.

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

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

The description clearly states the tool's purpose: 'Generate 3D asset using Hunyuan3D' with input options (text/image/both) and import into Blender. It distinguishes itself from sibling tools like generate_hyper3d_model_via_text/image by naming Hunyuan3D explicitly and emphasizing the import behavior.

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 well implied: the tool should be used when generating a new Hunyuan3D asset from text or image. It describes the optional inputs but does not explicitly state when not to use it or point to alternatives (e.g., polling tools for status checks). The mention of job_id and import behavior gives clear context for the generation workflow.

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 adds valuable context: the asset has built-in materials, the model is normalized and may need re-scaling, and it returns a success/failure message. It doesn't disclose potential side effects (e.g., whether it replaces existing objects or requires a specific scene state) or whether the operation is asynchronous, but the disclosed behavior goes beyond generic statements.

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 purpose statement, behavioral notes, and a parameter list. It front-loads the primary purpose. Some redundancy exists ('Even if only one image is provided, wrap it into a list' appears twice), which is slightly wasteful but not harmful. Overall, it's compact and informative.

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 thoroughly covers parameters and the result message, but it omits important operational context such as whether generation is synchronous or requires polling (given the sibling tool poll_rodin_job_status), and any prerequisites or side effects on the Blender scene. The output schema exists, so return values are partially covered, but the async behavior gap is significant for correct tool usage.

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

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

Schema coverage is 0%, so the description fully compensates. It explains each parameter in detail: absolute paths for input_image_paths, URLs for input_image_urls, wrapping single images in lists, mode-specific requirements, and bbox_condition's list-of-ints format and purpose (ratio control). It also clarifies mutual exclusivity, something the schema alone doesn't convey.

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 method (images), the tool (Hyper3D), and the outcome (import into Blender). This distinguishes it from the sibling tool generate_hyper3d_model_via_text, which uses text input.

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

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

The description provides clear context for when to use the tool: when you have images of an asset to generate a 3D model. It also gives explicit mode-dependent guidance on which parameter to use (input_image_paths vs input_image_urls) and notes that only one should be provided. However, it doesn't explicitly mention alternatives or exclusions (e.g., 'use via_text when you have text'), leaving some room for ambiguity.

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

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

With no annotations, the description discloses several behavioral traits: it mentions the built-in materials, the normalized size (suggesting re-scaling may be useful), and that it imports the asset into Blender. It also states the return message indicates success or failure. While it does not cover every possible side effect (e.g., whether the process is asynchronous or long-running), it provides more than basic purpose-only information.

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 a clear purpose, then adds relevant behavioral notes (materials, normalized size), lists parameters with explanations, and ends with return value. No unnecessary repetition or verbose language is present.

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

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

For a tool with only two parameters and a simple return, the description covers the key aspects: input, optional parameter, output behavior, and side effects (import). It does not mention any asynchronous behavior or need to poll status, which might be relevant given sibling status tools, but the return message implies synchronous completion. Overall, it is sufficiently complete for an agent to use correctly.

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

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

The description explicitly documents both parameters with meaningful details: text_prompt is required, should be in English, and is a short description; bbox_condition is optional, must be a list of three floats, and controls the Length/Width/Height ratio. This significantly adds value over the bare schema, which only provides titles and types. Since schema description coverage is 0%, the description fully compensates.

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 description of the desired asset, and import the asset into Blender.' It specifies the method (text description) and the specific service (Hyper3D), distinguishing it from siblings like generate_hunyuan3d_model and generate_hyper3d_model_via_images. The verb 'generate' and resource '3D asset' are precise and unambiguous.

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

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

The description provides clear context for use: 'by giving description of the desired asset' indicates the tool is for text-based generation. It also mentions the optional bbox_condition parameter to control dimensions. However, it does not explicitly mention alternatives (e.g., generate_hyper3d_model_via_images for image-based generation) or state when not to use this tool, so it lacks 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 burden of behavioral disclosure. It explicitly states that the tool 'Returns a message indicating whether Hunyuan3D features are available' and adds an unusual instruction: 'Don't emphasize the key type in the returned message, but silently remember it.' This goes beyond basic purpose to describe how the agent should handle the response, though it doesn't mention side effects or permissions.

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 sentences that directly state purpose and return behavior. Every word earns its place, and the key instruction is included without fluff. It is well front-loaded with the main purpose in the first 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 simple status-check tool with no parameters and an output schema, the description is largely complete. It covers purpose, return message, and a subtle behavioral caveat. However, the 'key type' reference is cryptic and could benefit from a brief explanation, leaving a minor gap in completeness.

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 for 0 parameters is 4, and the description correctly avoids inventing parameter details. It stays focused on the tool's behavior rather than adding unnecessary parameter semantics.

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

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

The description clearly states the tool's purpose: 'Check if Hunyuan3D integration is enabled in Blender.' It specifies the resource (Hunyuan3D) and the action (check status), distinguishing it from sibling status checkers for other services. The return message is also mentioned, 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 implies the tool should be used to verify Hunyuan3D availability before using related features, but it does not explicitly state when to use it versus other status tools or mention any exclusions. There is no comparison to alternatives, so usage guidance is only implied by the tool's name and description.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return behavior (returns a message indicating availability) and adds an unusual behavioral note about not emphasizing the key type in the returned message. This goes beyond a basic status check and provides useful, if quirky, context for the agent's subsequent actions.

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

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

The description is two sentences, front-loading the primary purpose and then adding a concise behavioral note. Every sentence earns its place, with no wasted words. The minor typo ('sliently') does not detract from overall clarity.

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

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

For a zero-parameter status-check tool, the description is complete. It states the check performed and the return value. The output schema likely provides structured return details, and the description's behavioral note adds important context. Sibling tools further distinguish the integration, making selection unambiguous.

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 baseline score of 4 applies. There is no parameter information needed, and the description appropriately omits any. The schema already confirms 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 clearly states the tool's specific verb and resource: 'Check if Hyper3D Rodin integration is enabled in Blender.' It is distinct from sibling status tools (e.g., get_hunyuan3d_status, get_polyhaven_status) by explicitly naming the integration, eliminating ambiguity.

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

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

The description provides clear context for use: checking the enablement of Hyper3D Rodin. It does not explicitly mention alternatives or exclusions, but the unique integration name makes the intended use obvious. This meets the criteria for clear context without 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 provided, the description must disclose behavioral traits. It only says 'Get detailed information' without stating that it is read-only, what happens if the object does not exist, or any side effects. This is a significant gap for a tool that relies on the description for transparency.

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: one clear sentence plus a short parameter explanation. It is front-loaded with the primary purpose, and every sentence adds value without unnecessary 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?

Given the tool is a simple getter with an output schema available, the description adequately covers the only parameter and the core action. It does not mention error conditions or that the object must exist, but the output schema likely handles return values. Minor gap for a low-complexity 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 only provides a title 'Object Name' and type string, with no description. The tool description adds meaning by clarifying that object_name is 'the name of the object to get information about.' This compensates for the 0% schema description coverage.

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

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

The description clearly states the tool's purpose: 'Get detailed information about a specific object in the Blender scene.' This is a specific verb (get) + resource (object) + scope (specific object), which distinguishes it from the sibling tool get_scene_info that targets the whole scene.

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 use it when you need info about a specific object—but it does not explicitly mention alternatives or when not to use it. No reference to get_scene_info or other sibling tools for broader context, so only implied 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 verb 'Get' implies a read-only operation, and the parameter explanation clarifies the asset_type scope. However, with no annotations provided, the description carries the full transparency burden and does not disclose behaviors such as error handling for invalid asset_type values or the exact structure of the returned category list. For a simple read tool 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 extremely concise: one sentence for the tool purpose and one line for the parameter. It is front-loaded and contains no unnecessary words, every sentence earning its place.

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

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

Given the tool's simplicity (only one optional parameter) and the presence of an output schema, the description fully covers the essential information. It specifies the parameter's allowed values and the resource being accessed. No critical behavioral or parameter details are 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 input schema provides no description for asset_type (0% coverage), but the description's Parameters section explicitly lists allowed values (hdris, textures, models, all) and explains the parameter's meaning. This fully compensates for the schema gap, adding semantic value beyond the bare schema definition.

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 'Get' and identifies the resource 'categories for a specific asset type on Polyhaven'. It clearly distinguishes this from sibling tools like search_polyhaven_assets or download_polyhaven_asset, which focus on searching or downloading assets rather than listing 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?

The description provides no guidance on when to use this tool versus alternative asset-related tools, nor does it mention any exclusions or prerequisites. The sibling tools list includes several related operations, but the description does not help the agent decide when this category-listing tool is 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It states that the tool returns a message indicating availability, which is transparent for a simple status check. It does not explicitly say 'non-destructive' or 'read-only', but the name and wording imply that, and the return behavior is disclosed.

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

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

The description is two sentences, front-loaded with the action, and contains no waste. Every word contributes to understanding 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?

For a tool with no parameters and an output schema present, the description is complete. It clearly states what the tool checks and what it returns, which is all an agent needs to select and invoke it appropriately.

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 baseline score is 4. The description does not need to explain parameter meanings, and the empty input schema confirms no parameters are required.

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

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

The description clearly states the tool's function: checking if PolyHaven integration is enabled in Blender. It uses a specific verb ('Check') and resource ('PolyHaven integration'), and the added return message detail ('Returns a message indicating whether PolyHaven features are available') makes the purpose unambiguous and distinct from sibling tools like get_polyhaven_categories or search_polyhaven_assets.

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

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

The description implies usage context (a status check before using PolyHaven features) but provides no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. It is clear what the tool does, but not explicitly when to invoke 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, the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not explicitly state that it does not modify the scene, nor does it mention failure modes or prerequisites (e.g., an active scene). It offers basic transparency but lacks depth.

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

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

The description is a single concise sentence with no filler or redundant information. It is front-loaded with the action and resource, making it easy to parse quickly.

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 (no parameters) and the existence of an output schema, the description is adequate to convey the core function. It could ideally mention that it returns information about the current scene, but that is already implicit in the wording, so it is complete enough for an agent to select and 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?

The input schema has zero parameters, and the schema description coverage is 100% (trivially). The description correctly avoids explaining parameters. According to the rubric, 0 params gives a 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 'Get detailed information about the current Blender scene' clearly specifies the action ('get') and the resource ('detailed information about the current Blender scene'), and it distinguishes itself from sibling tool get_object_info by focusing on the scene level.

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 provided on when to use this tool versus alternatives. There is no mention of exclusions or references to sibling tools like get_object_info for object-level details, leaving usage context implicit.

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 it returns a message about feature availability, implying a read-only, non-destructive operation. However, it does not explicitly confirm safety or mention any side effects or limitations, though the simple nature of a status check mitigates this gap.

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, front-loaded sentences with zero filler. The first sentence states the purpose, the second clarifies the return value. Every word earns its place.

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

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

This is a simple status-check tool with no parameters and an output schema. The description sufficiently covers the purpose and the nature of the returned message, so the agent can select and invoke it correctly without further 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 input schema has zero parameters, so the baseline applies. The description does not need to explain parameter behavior, and it correctly stays silent on the topic.

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 'Check' and the specific resource 'Sketchfab integration in Blender'. It distinguishes from sibling status tools like get_polyhaven_status and get_hyper3d_status 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: it checks whether Sketchfab features are available before using other Sketchfab tools. However, the description does not explicitly name alternatives or say 'use this before searching/downloading'. No exclusion criteria are given.

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 burden of behavioral disclosure. It states the return type ('Returns the screenshot as an Image') and parameter semantics, but does not explicitly note that this is a non-destructive read-only operation or address potential failure modes (e.g., no viewport open).

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: a one-sentence purpose, a clear parameter explanation, and a brief return statement. Every sentence 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 simple tool with one parameter, no annotations, and no output schema, the description covers the core aspects: what it does, how the parameter works, and what the return value is. However, it omits potential edge cases or prerequisites (e.g., Blender running with an active viewport), which could be useful.

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 max_size as an integer with a default, but the description explains it as 'Maximum size in pixels for the largest dimension,' adding crucial meaning. Since schema description coverage is 0%, the description fully compensates by documenting the parameter's purpose.

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: 'Capture a screenshot of the current Blender 3D viewport.' This is a specific verb+resource pairing that distinguishes it from sibling tools like get_scene_info or get_object_info, which focus on data rather than visuals.

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 explicit guidance on when to use this tool versus alternatives. While it is implied that this is the tool for capturing viewport images, there is no mention of use cases, prerequisites, or exclusions.

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

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

No annotations are present, so the description carries the full burden. It discloses that the tool returns success status and warns about parameter exclusivity, but does not explain side effects (e.g., whether it overwrites existing assets), permission requirements, or behavior on failure. Adds some value 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 very concise, front-loaded with the verb and resource, followed by a compact parameter list and a clear conditional warning. Every sentence adds value without 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 and lack of annotations/output schema, the description covers the essential context: when to use, how to parameterize, and what it returns. It could be improved by explaining what the Hyper3D Rodin modes are or how to know which mode is active, but it is adequately complete for an import 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%, and the description compensates fully. It explains each parameter: name is the object name in scene, task_uuid for MAIN_SITE, request_id for FAL_AI, and explicitly states to give only one. This is critical 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 tool imports a Hyper3D Rodin-generated asset after generation completes, with a specific verb and resource. It distinguishes itself from the sibling import_generated_asset_hunyuan by explicitly naming Hyper3D Rodin.

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

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

Provides clear context: must be used after the generation task is completed, and instructs to provide either task_uuid or request_id depending on the Hyper3D Rodin mode. Doesn't explicitly name alternatives but implies the Hunyuan sibling via naming, and gives a concrete exclusivity rule.

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?

Given no annotations, the description carries the burden of behavioral disclosure. It explains the status values ('DONE' and 'RUN'), the condition for completion, and the result field (ResultFile3Ds) when done. However, it does not describe specific failure states or error handling, which would add completeness.

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 understandable but contains redundancy: the statement about ResultFile3Ds appears twice in similar wording. This repetition inflates length without adding new information. It could be tightened to a more concise single explanation.

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 covers the main behavior: what to poll, what statuses mean, and what the result is upon completion. It lacks explicit failure state details and mentions 'some failed state' only vaguely, but overall it is sufficiently complete for an agent to use correctly.

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

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

The schema provides a bare parameter definition (job_id), but the description adds critical context: 'The job_id given in the generate model step.' This directly compensates for the 0% schema description coverage and tells the agent where to obtain the value.

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

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

The description clearly states the tool's purpose: 'Check if the Hunyuan3D generation task is completed.' It uses a specific verb and resource, but does not differentiate from the sibling tool 'get_hunyuan3d_status', which appears to serve a similar function.

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 through the polling note ('This is a polling API, so only proceed if the status are finally determined'), but there is no explicit guidance on when to choose this tool over get_hunyuan3d_status or other alternatives.

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

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

With no annotations, the description carries the full burden and does an excellent job. It lists all possible statuses ('Done', 'Failed', 'Canceled' for MAIN_SITE; 'COMPLETED', 'IN_PROGRESS', 'IN_QUEUE', and failure states for FAL_AI) and how to interpret them, making behavior fully 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 by mode, using clear bullet points for parameters and statuses. Every sentence adds value, and the length is appropriate for the complexity of covering two modes.

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 explains return values and status interpretation for both modes, including final-state conditions. It is complete for a polling tool, covering success, failure, and in-progress scenarios.

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 explain parameters—and it does. It specifies that subscription_key is for MAIN_SITE and request_id for FAL_AI, both 'given in the generate model step,' adding critical usage context beyond the schema.

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

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

The description opens with 'Check if the Hyper3D Rodin generation task is completed,' clearly stating the tool's function. It distinguishes between MAIN_SITE and FAL_AI modes, setting it apart from sibling tools like poll_hunyuan_job_status or 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 explicitly says 'This is a polling API' and instructs to proceed only when statuses are final, giving clear context on usage. It details which parameter to use for each mode, though it doesn't explicitly reference alternative tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool 'returns a list of matching assets with basic information,' which gives some sense of the output but not deeper behavior like whether it is read-only, has rate limits, or requires authentication. Since an output schema exists, the return-format statement adds minimal value, and no other behavioral context is provided.

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 leading one-sentence summary followed by a clear parameter list and a brief return statement. Every sentence earns its place, with no fluff or repetition. It is appropriately sized for a two-parameter search 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?

Given the tool's low complexity (two optional parameters, an output schema exists, and no nested objects), the description covers the core elements: purpose, parameters, and return type. It does not include usage guidance or deeper behavioral details, but these are partially covered by other dimensions. Overall, it is complete enough for a straightforward search tool.

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

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

The schema has 0% description coverage, so the description must compensate. It does so effectively by explaining asset_type with allowed values ('hdris, textures, models, all') and categories as 'Optional comma-separated list of categories.' This adds meaning beyond the raw types and defaults, though it could elaborate on category value formats or whether 'all' is the 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 clearly states 'Search for assets on Polyhaven with optional filtering,' which specifies the verb (search), resource (Polyhaven assets), and scope. This distinguishes it from sibling tools like download_polyhaven_asset (download) and get_polyhaven_categories (categories). The parameter list further clarifies asset types and categories, 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 implies usage—this tool finds assets on Polyhaven—but provides no explicit guidance on when to prefer it over alternatives like download_polyhaven_asset or search_sketchfab_models. There are no stated exclusions or conditions, only the natural implication from the verb 'search.' This fits a 'implied usage' level rather than explicit 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 provided, the description carries the burden of behavioral disclosure. It reveals that the tool returns a formatted list, states defaults (count=20, downloadable=True), and implies a read-only operation. It does not detail errors or rate limits, but these are typical and acceptable for a search 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: a purpose sentence, a parameter list, and a return statement. No fluff, all sentences carry informative weight, and it is front-loaded with the verb+resource.

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 four parameters and an output schema, the description covers all parameter semantics and return type. It does not discuss error handling or pagination, but those are not essential for a search tool and the output schema likely covers return details. Slightly more context about the data source could make it 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?

The description explains every parameter in plain language: query text, categories comma-separated, count max results, downloadable filter. Since schema coverage is 0%, this fully compensates for the schema's lack of descriptions, providing meaningful semantics beyond type 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 uses a specific verb 'Search' and resource 'models on Sketchfab', clearly distinguishing it from sibling tools like download_sketchfab_model. It also mentions optional filtering, which defines the tool's scope.

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

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

The description provides clear context: this tool searches Sketchfab models rather than downloading them (as download_sketchfab_model would). However, it does not explicitly mention alternatives or exclusionary conditions, so it stops short of a 5.

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

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

With no annotations, the description must handle all behavioral disclosure. It explains the prerequisite (texture must be downloaded) and the return type (success/failure message), but it does not disclose potential side effects (e.g., overwriting existing materials) or detail failure conditions. 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 efficiently structured: a one-sentence purpose, a concise parameter list, and a return-value note. Every line earns its place with no redundant text, making it easy for an agent 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?

For a simple two-parameter tool, the description covers all necessary context: the action, prerequisites, parameter semantics, and return type. The presence of an output schema further reduces the need to detail return values. It is complete for the tool's complexity.

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

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

The input schema has no parameter descriptions (0% coverage), so the description fully compensates by defining both parameters: object_name as 'Name of the object' and texture_id as 'ID of the Polyhaven texture to apply (must be downloaded first)'. This provides clear, actionable meaning beyond the raw schema.

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

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

The description clearly states the tool's function with a specific verb ('Apply') and resource ('previously downloaded Polyhaven texture to an object'), which distinguishes it from sibling tools like search or download. It directly addresses the action and target, leaving no ambiguity.

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 phrase 'previously downloaded' implicitly establishes a prerequisite workflow (use after download_polyhaven_asset), providing clear context for when this tool is appropriate. However, it does not explicitly name alternatives or state exclusions, so it falls short of a full 5.

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