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

No annotations are provided, so the description carries full burden. It states the tool downloads and imports into Blender and returns a success/failure message, but lacks details on import behavior (e.g., overwrite, placement), required Blender context, or error handling. This is insufficient for a mutation tool.

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

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

The description is structured with a clear opening sentence followed by a bullet-like parameter list. It is front-loaded and every sentence serves a purpose. The parameter explanations, while necessary due to lack of schema descriptions, could be more concise by being moved to the schema.

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

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

Given no output schema and no annotations, the description covers the basic operation and parameter meanings. However, it misses prerequisites (e.g., Blender must be running), error handling details, and import specifics. For a tool with 5 parameters and mutation effects, it is adequate but 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?

Schema description coverage is 0%, so the description must compensate. It provides brief explanations for each parameter (e.g., 'The ID of the asset to download', examples for resolution and format). However, the descriptions are terse and not exhaustive; for instance, available resolutions are only listed as examples. This adds moderate value over 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's purpose: 'Download and import a Polyhaven asset into Blender.' This is a specific verb+resource combination that distinguishes it from sibling tools like download_sketchfab_model and 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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest alternative tools for different scenarios. The context of sibling tools (e.g., search_polyhaven_assets) is not leveraged.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the model will be scaled to target_size, that it downloads and imports, and that access rights are required. This provides good transparency for the core behavior. However, it does not describe what happens to existing objects in the scene or whether the import is reversible.

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

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

The description is structured with a summary sentence followed by a parameter section with bullet points. The examples add clarity without being verbose. Each sentence contributes meaning. Slight room for improvement by integrating user_prompt 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?

Given the complexity of importing a 3D model, the description covers the main action and scaling but lacks information on scene impact (e.g., will it add to collection or replace selection). It also does not mention any prerequisites beyond access rights. The return value is vaguely described as 'a message with import details'. A more complete description would address these gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It adequately explains uid and target_size with examples, but ignores user_prompt. The parameter list in the description only covers two of three parameters, leaving user_prompt undocumented. This is a moderate gap.

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

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

The description clearly states the verb (download and import), the resource (Sketchfab model), and the method (by UID). It also mentions scaling to target_size. This distinguishes it from siblings like search_sketchfab_models (searching) and get_sketchfab_model_preview (previewing), 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 when you have a Sketchfab UID and want a model imported at a specific size, but it does not explicitly state when to use this tool over alternatives like download_polyhaven_asset or generate_hyper3d_model_via_text. There is no when-not-to-use guidance or exclusion criteria, leaving some ambiguity for the AI agent.

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

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

With no annotations, the description must disclose behavioral traits. It only states 'Execute arbitrary Python code' without mentioning side effects, permissions, error handling, or limitations. The risk profile is unclear.

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

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

The description is extremely concise: two sentences and parameter list with no fluff. Information is front-loaded.

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

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

For a code execution tool with no annotations and no output schema, the description should cover return values, potential errors, and safety warnings. It fails to provide enough contextual detail for safe usage.

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

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

Schema description coverage is 0%, so the description adds context. For 'code' it repeats 'The Python code to execute,' which is minimal. For 'user_prompt' it explains its telemetry purpose, adding value. Format or examples are missing.

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 is a specific verb and resource. It distinguishes from sibling tools that handle downloads, model generation, and scene queries.

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?

Instructs to 'do it step-by-step by breaking it into smaller chunks,' which provides useful guidance. However, it does not specify when to use this tool versus alternatives or when not to use 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?

No annotations provided, so description carries full burden. It describes the async workflow (job_id, DONE status) but is ambiguous about whether import is automatic or requires a separate tool (import_generated_asset_hunyuan exists as sibling). Missing details on failure modes and rate limits.

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

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

Reasonably front-loaded with purpose; separate parameter and return sections. However, the sentence 'The 3D asset has built-in materials.' adds marginal value and could be integrated. No wasted words beyond that.

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 output schema and no annotations, the description leaves significant gaps: it doesn't mention that user_prompt exists, doesn't explain relationship with sibling tools (poll_hunyuan_job_status, import_generated_asset_hunyuan), and doesn't clarify if import is automatic or manual.

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 description must compensate. It describes text_prompt and input_image_url but omits user_prompt entirely, which is a parameter in the schema. Descriptions are brief and lack formatting constraints.

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

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

Description clearly states it generates a 3D asset via Hunyuan3D from text and/or image and imports into Blender. However, it doesn't differentiate from sibling Hunyuan vs Hyper3D tools, and the import timing is slightly ambiguous.

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

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

No guidance on when to use this tool vs alternatives (e.g., Hyper3D tools) or on prerequisites like choosing text vs image. Does not explain that the job is asynchronous or that polling may be needed.

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 the generated model has built-in materials and normalized size, and that re-scaling may be useful. It also explains the bbox_condition parameter's effect. No destructive or safety issues mentioned, but the tool is generative and likely safe.

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

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

The description is well-structured with a clear opening, behavioral notes, and bullet-pointed parameters. It is concise but could be slightly more streamlined. The parameter list is helpful.

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 4 parameters, no output schema, and no annotations, the description covers basic usage but lacks details on the output format beyond a success/failure message. The import step is mentioned but not detailed. For a complex generative tool, more context on post-generation workflow would improve 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?

Schema description coverage is 0%, so the description must compensate. It explains input_image_paths, input_image_urls, and bbox_condition well, but fails to mention the user_prompt parameter, leaving it undocumented. This gap reduces 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 generates a 3D asset using Hyper3D from images and imports it into Blender. It also mentions built-in materials and normalized size, distinguishing it from siblings like generate_hyper3d_model_via_text.

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

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

The description explains when to use input_image_paths vs input_image_urls based on the Hyper3D Rodin's mode. It does not explicitly list alternatives, but the sibling tool names provide context. The 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?

The description says the model has built-in materials and normalized size, and re-scaling may be needed. However, it does not disclose if the process is synchronous or async, nor does it mention any authorization or rate limits. With no annotations, this is a moderate disclosure.

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 relatively short but includes some redundant phrasing (e.g., 'the desired asset' repeated). It front-loads the main action but lacks bullet points or clear separation of parameter details.

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 and no annotations, the description should provide a fuller picture. It misses details on error handling, status polling (since siblings exist), and the nature of the success/failure message. The omission of user_prompt further reduces 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?

Schema coverage is 0%, so the description must explain parameters. It covers text_prompt and bbox_condition, but entirely omits the user_prompt parameter. This is a significant gap, leaving the agent unaware of a third 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 generates a 3D asset via text description and imports it into Blender, distinguishing it from the sibling tool that uses images. The verb 'Generate' and resource '3D asset using Hyper3D' are specific.

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 via text prompt but does not explicitly state when to use this tool over alternatives like generate_hyper3d_model_via_images or other modeling tools. No guidance on when not to use it or prerequisites.

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 provided, so description carries full burden. It only says 'returns a message' without detailing side effects, potential errors, or what triggers a failure. Minimal 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?

Two clear, front-loaded sentences with no unnecessary words. Efficient for the simple action described.

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, the description captures the basic behavior. However, missing details on the parameter and the format of the returned message reduce completeness. Adequate but not thorough.

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

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

Schema has one parameter 'user_prompt' with default empty, but description does not explain its purpose or usage. With 0% schema coverage, this is a critical gap.

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

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

The description clearly states the tool checks if Hunyuan3D integration is enabled, with a specific verb and resource. While it doesn't explicitly differentiate from siblings like generate_hunyuan3d_model, the purpose is distinct and understandable.

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 prerequisites (e.g., Blender running) or suggest using this before generation tasks.

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 must disclose behavior. It mentions returning a message but does not specify the message structure, possible values, or error conditions. The purpose of the user_prompt parameter is not explained, leaving a significant 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?

The description is two sentences, concise and front-loaded with the action. Every word is necessary.

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

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

Despite low complexity, the description omits the return value format and the purpose of the user_prompt parameter. It is not complete for effective tool invocation without additional inference.

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 one parameter (user_prompt) with no description, and the tool description does not explain its role. With 0% schema coverage, the description fails to add any meaning to the parameter.

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

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

The description clearly states the action ('Check if... enabled') and the resource ('Hyper3D Rodin integration in Blender'). It distinguishes from siblings like get_hunyuan3d_status and poll_rodin_job_status by targeting a specific 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 description implies the tool should be used before Hyper3D Rodin features are accessed, but it does not provide explicit when-not or alternative directives, such as comparing with get_hunyuan3d_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, and the description fails to disclose behavioral traits such as read-only nature, error handling (e.g., when object_name is not found), or what 'detailed information' includes. It mentions 'user_prompt' for telemetry but omits other behavioral details.

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

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

The description is extremely concise with two sentences and a parameter list. It front-loads the purpose and provides compact parameter semantics 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?

Given the simplicity of the tool and lack of output schema, the description is somewhat incomplete. It does not describe the return format, what 'detailed information' entails, or behavior when the object does not exist. However, it provides the core purpose and parameter documentation.

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

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

The input schema has 0% description coverage, so the description compensates by explicitly stating the meaning of each parameter: 'object_name' is 'The name of the object to get information about' and 'user_prompt' is 'The original user prompt... for telemetry'. This adds needed context beyond parameter names.

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

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

The description clearly states the tool's action: 'Get detailed information about a specific object in the Blender scene.' It uses a specific verb ('get') and resource ('object'), and distinguishes itself from sibling tools like 'get_scene_info' which pertains to the entire 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 provides no guidance on when to use this tool versus alternatives, such as 'get_scene_info' or 'execute_blender_code'. It does not specify 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 provided, so the description carries full burden. It only states the basic purpose without disclosing any behavioral traits like side effects, rate limits, or error behavior. For a read-only query, it is minimal.

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

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

The description is extremely concise: two sentences plus parameter list. It is front-loaded with the purpose and wastes no words. Every line adds value.

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

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

Given the tool's simplicity and lack of output schema, the description is adequate but not complete. It explains what it does and the parameters, but omits expected return format, possible errors, and edge cases. A more complete description would mention the return structure.

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

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

The schema has 0% description coverage, but the tool description explains both parameters: asset_type with allowed values and user_prompt as telemetry. This adds significant value beyond the schema, which only has defaults. A higher score would require more detail on parameter constraints.

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

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

The description clearly states the action ('Get a list of categories'), the resource ('for a specific asset type on Polyhaven'), and distinguishes from sibling tools like search_polyhaven_assets and download_polyhaven_asset. It is specific 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?

No guidance is provided on when to use this tool vs alternatives, such as search_polyhaven_assets for searching assets. The description lacks context for when this tool is appropriate or when to choose another.

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 provided, so description carries full burden. It only mentions returning a message, omitting details on side effects, permissions, or errors. For a read-only check, minimal disclosure but still 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?

Two sentences, no wasted words. Efficient and directly to the point.

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 and a simple check, the description lacks explanation of the user_prompt parameter and how it affects the result, leaving the tool's behavior incomplete 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?

The input schema includes an optional 'user_prompt' parameter (default ''), but the description never mentions it, adding no meaning beyond the schema. With 0% schema description coverage and no parameter explanation, this is a critical gap.

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

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

The description clearly states the verb 'Check' and the resource 'PolyHaven integration' in Blender, distinguishing it from sibling tools like download_polyhaven_asset 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 for verifying integration status before other PolyHaven operations, but does not explicitly state when not to use or provide 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?

No annotations are provided, so the description must disclose behavioral traits. It mentions 'Get detailed information' but does not state whether the operation is read-only, any side effects, or performance implications. The agent has insufficient information to assess safety.

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 short and to the point, with no wasted words. However, it could include more critical information without becoming verbose, such as output summary or usage context.

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 with one parameter and a clear purpose. The description covers the parameter adequately but omits details about the output format or fields, leaving the agent uncertain about what 'detailed information' entails.

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

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

The description explains the purpose of 'user_prompt' (telemetry) beyond the schema's bare field title. With 0% schema description coverage, this explanation adds significant meaning, though it could further specify the expected format or content of the prompt.

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

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

The description clearly states the tool retrieves detailed information about the current Blender scene, which is a specific verb-resource combination. It distinguishes from sibling tools focused on downloading, generating, or importing assets, but 'detailed information' remains vague without specifying what details are provided.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it discuss prerequisites or limitations. The agent is left to infer usage context from the tool name alone.

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

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

No annotations present, so description carries full burden. Discloses return type (Image) and purpose, but lacks details on error behavior, rate limits, or any side effects. 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?

Description is concise (three sentences plus parameter list) and front-loaded with purpose. The parameter list adds context for uid but is somewhat redundant with schema. No wasted words.

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

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

Given only two parameters, no output schema, and no annotations, the description covers core purpose and usage guidelines but falls short on parameter semantics for 'user_prompt' and return format details beyond 'Image'. Adequate but 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?

Schema description coverage is 0%, and description only clarifies the 'uid' parameter (obtained from search_sketchfab_models) while completely ignoring the 'user_prompt' parameter. This is a significant gap.

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

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

Explicitly states the verb 'Get' and the resource 'preview thumbnail of a Sketchfab model by its UID', clearly distinguishing it from sibling tools like search_sketchfab_models and download_sketchfab_model.

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

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

Provides clear context: 'Use this to visually confirm a model before downloading.' Indicates relationship with search_sketchfab_models for obtaining the UID, effectively guiding when and when not to use.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure, but it only states that the tool returns a message. It does not mention side effects (likely none), authentication needs, or the format/type of the return value. This is insufficient for a tool that likely performs a safe read operation.

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

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

The description consists of two short, direct sentences with no redundant or extraneous information. It is efficiently front-loaded and every word serves a purpose.

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

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

Given that there is no output schema and only one simple parameter, the description should fully explain the return value and behavioral context. It only vaguely mentions 'a message' without specifying format, type, or possible values, leaving the agent uninformed about what to expect.

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

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

The input schema has one parameter 'user_prompt' with 0% description coverage, and the tool description does not mention or explain this parameter at all. The description adds no meaning beyond the schema's bare existence, 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 the tool checks if Sketchfab integration is enabled in Blender and returns a message about feature availability. This is a specific verb+resource combination, and it distinguishes from sibling tools like search or download that perform different actions.

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 used to verify Sketchfab availability before using other Sketchfab features, but it does not explicitly state when to use it versus alternatives like search_sketchfab_models or download_sketchfab_model. No exclusion criteria are provided.

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

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

No annotations provided. Description discloses return type (Image) but omits behavioral traits such as whether the viewport must be active, or if it captures overlays. Basic transparency but incomplete.

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?

Description is concise with two focused paragraphs. No extraneous text. However, the default mismatch reduces clarity and could be considered a minor inefficiency.

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?

Parameters and return are covered, but missing details about image format, what 'current viewport' includes (e.g., UI elements), and behavior in multi-viewport setups. Adequate for a simple tool but not comprehensive.

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

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

Schema has 0% description coverage; description adds meaning for both parameters. However, the default for max_size conflicts with schema (800 vs 1000), causing confusion. user_prompt is explained as telemetry, which is helpful.

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

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

Description clearly states the tool captures a screenshot of the current Blender 3D viewport, using specific verb and resource. No sibling tool duplicates this functionality, so differentiation is not required.

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?

Description provides basic usage context (captures current viewport) but lacks guidance on when to use versus alternatives, or prerequisites like viewport visibility. Minimal support for decision-making.

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?

Mentions return value indicates success. No annotations provided, so description carries burden. Lacks details on side effects, error behavior, or authorization needs.

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

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

Concise sentences with clear front-loading of purpose, followed by parameter details and a usage rule. No extraneous text.

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

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

Covers parameters and return type. No output schema, so description mentions success check. Could be improved by noting behavior if generation task is not 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 has 0% coverage, but description explains each parameter's purpose (name as object name, task_uuid and request_id with their sources) and adds critical constraint mutual exclusivity. Fully compensates for missing schema descriptions.

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

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

Clearly states 'Import the asset generated by Hyper3D Rodin', specifying verb and resource. Distinguishes from sibling tools like import_generated_asset_hunyuan by naming the model provider.

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 explicit guidance on using task_uuid vs request_id based on mode, and warns to give only one. Does not explicitly state prerequisites or when not to use, but the context is 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?

No annotations are provided, so the description must disclose behavioral traits. It only states it imports and returns success, omitting details like destructiveness, side effects, or error handling. This is insufficient for a tool with no annotations, leading to a low score.

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, stating the main action first. It covers parameters and return value in a few sentences without fluff. Every sentence serves a purpose.

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

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

For a simple tool with 2 required parameters and no output schema, the description covers the essentials: purpose, when to use, parameter meanings, and return. However, it lacks error handling context and prerequisites (e.g., generation must be complete). Still, it is largely 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 schema has 0% description coverage, so the description adds value. It explains that 'name' is the object name in scene and 'zip_file_url' is from the generate step, which goes beyond the schema's minimal titles. This provides meaningful context, earning a 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 states it imports an asset generated by Hunyuan3D after task completion, making the purpose clear. It distinguishes from download/generate tools, but there is a sibling 'import_generated_asset' without Hunyuan suffix, which could be confusing. The mention of 'Hunyuan3D' provides specificity, earning a 4.

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 says 'after the generation task is completed' and references the zip_file_url from the generate step, giving context on when to use. However, it does not explicitly say when not to use or mention alternatives, such as the generic import_generated_asset tool. Thus, it is adequate but not thorough.

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, so description carries full burden. It explains return status values ('RUN', 'DONE'), polling nature, and response field ResultFile3Ds. Lacks mention of error states or rate limits, but adequate for a simple polling 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?

Well-structured with bullet points and front-loaded purpose, but contains redundancy (mentions ResultFile3Ds twice) and could be more concise.

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

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

For a low-complexity tool (1 param, no output schema), description covers purpose, parameter, return format, and polling behavior. Lacks error examples but sufficient for 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%, but description adds clear context for the single parameter job_id, stating it comes from the generate model step, which is essential.

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

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

Description clearly states it checks Hunyuan3D generation task completion. Identifies specific resource and verb. However, does not explicitly distinguish from sibling 'get_hunyuan3d_status', though the polling behavior implies repeated checks.

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 guidance on when to stop polling (status 'DONE' or failed state) and references job_id from generate step. No explicit when-not to use or comparison with alternatives like get_hunyuan3d_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 full burden. It explains the polling nature and expected final states (Done, Failed, Canceled, COMPLETED, IN_PROGRESS, IN_QUEUE). However, it lacks details on timeouts, retry expectations, or consequences of polling before readiness.

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 verbose, repeating similar structure for each mode. It could be condensed into a simpler explanation without losing meaning. The front-loading is decent but gets buried in details.

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 complexity (two modes, no output schema, no annotations), the description partially covers return values and termination conditions. However, it omits guidance on parameter combination handling and error recovery, leaving 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?

With 0% schema coverage, the description must explain parameters. It maps 'subscription_key' to MAIN_SITE and 'request_id' to FAL_AI, but it doesn't clarify that only one is needed based on mode or how to choose which to provide. Both are optional in schema, leading to ambiguity.

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 it checks if Hyper3D Rodin generation is completed and distinguishes between two modes (MAIN_SITE and FAL_AI). However, it's not immediately clear which mode applies or how the tool determines mode, and the purpose is muddled by the lengthy mode-specific details.

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

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

The description provides guidance on when to proceed based on final status values but fails to differentiate this tool from siblings like 'get_hyper3d_status' or 'poll_hunyuan_job_status'. No explicit when-to-use or when-not-to-use advice is 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?

No annotations are provided, and the description only discloses that it returns a list with basic information. It does not state whether the tool is read-only, any authentication requirements, rate limits, or other behavioral traits.

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 structured with a clear parameter list. It is front-loaded with the main purpose. Minor improvement could be made by removing the parameter details if the schema is also expected to document them.

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 3 parameters, no output schema, and no annotations, the description provides basic functionality but lacks details on result structure, pagination, or error handling. It is minimally adequate.

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

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

The description adds meaning to all three parameters: asset_type lists allowed values, categories notes optional comma-separated list, and user_prompt explains telemetry purpose. With 0% schema coverage, this compensates well.

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

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

The description clearly states the tool searches for assets on Polyhaven with optional filtering, using a specific verb and resource. It distinguishes from sibling tools like search_sketchfab_models and download_polyhaven_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 implies usage for searching Polyhaven assets but does not specify when to use this tool versus alternatives, nor when to avoid it. There is no mention of prerequisite conditions or 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, the description must fully disclose behavior. It states the return format (formatted list) but omits side effects, auth requirements, rate limits, or error handling. A search tool is typically read-only, but the description does not confirm this.

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

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

The description is concise, with a single-line purpose and a bulleted parameter list. It is front-loaded, but the parameter list could be more structured (e.g., using a table). Still, it avoids 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?

Given no output schema, 5 parameters (one undocumented in description), and no annotations, the description is incomplete. It does not cover return value details, error scenarios, or edge cases like empty results. The missing 'user_prompt' parameter limits 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?

Schema coverage is 0%, so the description should explain all parameters. It describes 4 of 5 parameters but misses 'user_prompt'. Explanations are minimal (e.g., 'text to search for' for query). No additional meaning beyond basic types.

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

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

The description clearly states the tool's purpose: search for models on Sketchfab with optional filtering. It distinguishes from sibling tools like search_polyhaven_assets (different platform) and download_sketchfab_model (different action).

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

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

The description implies usage for searching Sketchfab models but does not explicitly state when to use this tool over alternatives, nor does it provide when-not-to-use guidance. Context signals show siblings like search_polyhaven_assets, but no comparative guidance is 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?

No annotations are provided, so the description carries the full burden. It mentions 'returns a message indicating success or failure' but does not disclose side effects (e.g., overwriting existing textures), prerequisites, or error conditions. Behavioral traits are minimal.

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 two clear sentences and parameter bullet points. However, the parameter section could be integrated more efficiently, and there is slight redundancy with the schema.

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

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

Given no output schema and no annotations, the description should cover prerequisites, behavior, and all parameters. It lacks details on the user_prompt parameter, fails to explain 'apply' in context (e.g., material assignment), and does not describe the return value format.

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

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

Schema coverage is 0%, so the description must compensate. It adds meaning for object_name and texture_id but completely omits the user_prompt parameter. This leaves a parameter undocumented, reducing clarity for the agent.

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 action: 'Apply a previously downloaded Polyhaven texture to an object.' It uses a specific verb and resource, and distinguishes this tool from siblings that handle downloading, importing, or generating 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 by mentioning the texture must be previously downloaded, but does not explicitly state when to use this tool over alternatives or provide exclusions. The parameter note 'must be downloaded first' is a weak guideline.

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