BlenderMCP

by naab007

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.5.5
Disambiguation3/5
Many tools have clear distinct purposes, but there is overlap among viewport capture tools (capture_viewport_angle, capture_contact_sheet, get_viewport_screenshot) and 3D generation tools (generate_3d_from_image, generate_hunyuan3d_model, generate_hyper3d_model_via_images, etc.). These groups could confuse an agent when choosing the appropriate tool.
Naming Consistency3/5
Most tools use snake_case with verb_noun pattern, but there are inconsistencies: 'add' vs 'create' vs 'generate' for similar operations (add_primitive vs create_camera vs generate_3d_from_image). Also singular/plural mismatch in set_control_point vs get_control_points.
Tool Count2/5
92 tools is extremely high for an MCP server. While Blender is complex, this many tools makes it difficult to navigate and likely includes many specialized functions that could be merged or omitted.
Completeness4/5
The tool surface covers a wide range of Blender operations including modeling, materials, lights, cameras, animation, rendering, and integrations. Missing some advanced features like armature editing or sculpting, but for most 3D tasks it is quite comprehensive.
Average 3.8/5 across 92 of 92 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey all behavioral traits. It states 'absolute scale' but omits details such as coordinate system, allowed value ranges, or what happens if the object does not exist. The description is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it sacrifices necessary detail. While not verbose, it is too sparse to be maximally helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0% parameter coverage, the description is critically incomplete. It does not explain return values, error conditions, or provide any contextual information beyond the basic action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must explain parameters. It only mentions 'each axis' without specifying that x, y, z are scale factors or that default 1 means no change. The parameter semantics are not effectively communicated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Set the absolute scale of an object on each axis,' clearly indicating the action (set), the resource (object scale), and that it operates per-axis. This distinguishes it from sibling tools like move_object or rotate_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No context is provided on when to use this tool versus alternatives such as relative scaling operations or object transformations. There is no guidance on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of disclosing behavior. It fails to specify what 'detailed information' includes (e.g., transforms, materials, modifiers) or whether the tool is read-only and has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but lacks sufficient detail to be fully helpful. It is not verbose, but also not optimally informative for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of many sibling tools and the lack of output schema, the description should convey what kind of information is returned (e.g., dimensions, location, parent). It does not, making it incomplete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 beyond the schema. It only restates that object_name is the object's name, which is already evident from the property name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets detailed information about a specific object in the Blender scene, using a specific verb and resource. However, it does not differentiate itself from sibling tools that also retrieve object-specific data (e.g., get_mesh_stats, get_vertex_positions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_mesh_stats or get_scene_info. The agent receives no context about optimal use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It does not disclose important behavioral traits such as what happens if the material doesn't exist, if the slot index is out of range, if the operation is destructive (overwrites existing material), or any error conditions. The description only mentions the prerequisite that material must already exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one clear purpose sentence followed by a brief parameter list. It is front-loaded and contains no unnecessary information. Could be slightly more structured, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple assignment tool, the description lacks completeness. It does not mention return values, side effects, or prerequisites such as the object needing material slots. Given many sibling tools and no output schema, more context is needed to ensure correct usage, especially regarding when to use this versus other material-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema titles by providing brief explanations: 'Target object', 'Material to assign (must already exist)', and 'Material slot index (default 0)'. However, it does not specify constraints like slot must be non-negative or that material_name must match an existing material exactly. Given 0% schema description coverage, the description partially compensates but is not detailed enough for a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: assign an existing material to an object's material slot. It uses a specific verb and resource, and the purpose is distinguishable from siblings like create_material or set_object_material_color, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It mentions the material must already exist, but does not provide context such as 'Use after create_material' or 'For changing color, use set_object_material_color instead.' Lacks when-not-to-use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks annotations, so description must disclose side effects. It does not state whether the original object is deleted or modified, whether new objects are created, or any limitations on mesh type. This is a significant gap for a transformative operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with a clear header and bullet list. It avoids unnecessary text. However, it could include a bit more context (e.g., side effects) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers the basic purpose and parameters. However, it omits behavioral details (what happens to original object, new object creation) and error conditions, leaving gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning by explaining the 'name' parameter as 'Mesh object name' and listing method options with brief meanings. However, it does not specify defaults, constraints, or valid values (e.g., case sensitivity). Provides some value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (separate) and resource (mesh object) and that it results in multiple objects. It is specific enough to distinguish from sibling tools like join_objects or subdivide_mesh, though it could explicitly differentiate from similar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mention prerequisites (e.g., mesh must be selected) or scenarios where one method is preferred. Only parameter explanations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description implies a mutation (changing active camera) but does not disclose side effects, error behavior if the camera name is missing or invalid, or any other consequences. The phrase 'to an existing camera object' is a precondition but not behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the parameter listing duplicates schema information. It is front-loaded with the main action, but the param section could be omitted or integrated more efficiently. Still, no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema tool with no annotations, the description lacks completeness. It does not explain what happens if the camera name does not exist, whether the active camera is changed immediately, or any return value. More context would be beneficial for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (the schema has no description for the 'name' property). The description adds 'Camera object name' which is minimal and largely redundant with the property name. It provides no additional meaning beyond what is obvious from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Set the active render camera to an existing camera object.' It uses a specific verb ('set') and resource ('active render camera'), clearly distinguishing it from siblings like 'create_camera' or 'render_from_camera'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Siblings such as 'render_from_camera' also involve cameras but without setting active. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only states the operation; missing details on side effects, reversibility, or whether the scene must be loaded. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise with no fluff: two lines plus a parameter list. Structured with a param description, though slightly too brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 and no output schema, the description is adequate but lacks context about when to use (e.g., animation workflows) and whether it updates the viewport.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description adds 'Target frame number,' which explains the parameter's role beyond its type and title. Could include valid range or starting point.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set the current scene frame (scrubs the timeline),' using a specific verb and resource. It distinguishes from siblings like 'add_keyframe,' though could be more precise about the timeline context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'add_keyframe' or 'set_render_settings.' No prerequisites or common scenarios mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only states that arbitrary code is executed, without mentioning side effects, security implications, potential crashes, or whether the code runs in a sandbox. This is insufficient for a potentially destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, using two sentences. The first defines the tool, the second gives advice. It could be considered concise, but it might benefit from slightly more detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (executing arbitrary code), the description lacks essential details: no mention of error handling, return behavior, Blender environment specifics, or limitations. This makes it dangerously incomplete for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage (description does not repeat schema). The parameter description 'The Python code to execute' merely restates the schema's type and name, adding no meaningful semantics about formatting, constraints, or execution context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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-resource pair. It distinguishes itself from sibling tools that perform specific Blender operations, as this is a generic code execution tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises breaking code into smaller chunks and doing it step-by-step, implying it should be used for complex scripting. However, it does not explicitly state when to use or not use this tool versus alternatives, leaving the context implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'Return...' without clarifying whether the tool is read-only, has side effects, requires permissions, or any other behavioral context. For a stats-gathering tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (two sentences plus a parameter list) and front-loaded with the main purpose. Every sentence is functional, but the structure could be improved by grouping related information (e.g., a separate usage note).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations. The description leaves 'detailed topology statistics' vague; the agent cannot infer the return format (e.g., counts, dictionaries) or understand edge cases. Given the lack of output schema, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 notes that 'name' is a 'Mesh object name,' adding a type constraint beyond the schema's 'Name' title. However, this is minimal; the description does not explain the expected format or hint at validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'detailed topology statistics for a mesh object,' using a specific verb-resource pair. This differentiates it from sibling tools that return specific mesh components (e.g., get_vertex_positions, get_faces, get_edges).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it does not explain that for individual component queries one should use other sibling tools, nor does it mention prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility. It mentions the prerequisite of a Principled BSDF node, but does not disclose whether the tool replaces existing textures, what happens to image file errors, or any side effects on the material graph. This leaves significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a one-line summary followed by a parameter list. No extraneous information, though the parameter descriptions could be integrated more tightly into the narrative. Still, it is efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's main action and parameter meanings, and notes the node prerequisite. However, it lacks details on return values, error conditions, and whether the operation is additive or replaces existing textures, leaving gaps in understanding for a complex operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool description compensates by explaining each parameter's role, providing allowed values for texture_slot, and clarifying the requirement for material_name. This adds substantial meaning beyond the schema's bare titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it loads an image and wires it into a material's texture slot, using specific verbs and resources. However, it does not explicitly distinguish from sibling tools like `set_texture`, which could be a similar operation, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description lists parameters but does not provide context for appropriate usage, such as when a texture needs to be newly loaded versus reassigned, or prerequisites beyond the node requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states 'Returns a list of matching assets with basic information,' which is vague and omits critical details such as whether the operation is read-only, rate limits, authentication requirements, or how results are ordered/paginated. The lack of side-effect clarity is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence explaining the tool's purpose followed by a two-line parameter breakdown. Every word serves a purpose, and the structure is easy to scan. No extraneous content exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only two simple parameters, the tool lacks an output schema and the description does not detail the return format (e.g., which fields like 'name', 'url', 'thumbnail' are included). Without this, an agent cannot reliably parse the results. Additionally, no mention of pagination, limits, or error handling is made. The description is incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the input schema provides 0% description coverage, the description compensates by listing both parameters and adding key semantics: asset_type receives explicit allowed values (hdris, textures, models, all) beyond the schema's 'string' type, and categories is clarified as a comma-separated filter. This enables correct parameter usage, though the valid category values are not enumerated (likely obtainable via sibling tool).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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,' specifying the verb (search), resource (assets on Polyhaven), and the ability to filter. This distinguishes it from sibling tools like search_sketchfab_models, but it could be more precise about whether it searches all public assets or only those with specific criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filtering but provides no guidance on when to use this tool versus alternatives like get_polyhaven_categories or download_polyhaven_asset. There is no advice on prerequisites (e.g., needing categories beforehand) or when not to use it, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It fails to state that this is a read-only operation, nor does it describe any side effects or requirements like permissions. 'List' implies no mutations, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no fluff. It front-loads the purpose in the first sentence and then explains the parameter. Every word adds value for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 and no output schema/annotations, the description covers the basic action and parameter. However, it lacks explanation of the output format (what does 'list' return?), leaving some uncertainty for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaningful parameter semantics by listing example Blender object types (MESH, CURVE, etc.) and indicating the expected values. This helps the agent understand valid inputs, though the list could be more exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists objects by type, using specific verb 'List' and resource 'objects in the scene'. It is distinguishable from siblings like 'select_objects' or 'get_object_info', but could be more explicit about the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for filtering objects by type, but does not mention when not to use or provide comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior fully. It states returns a message indicating availability, but the instruction 'Don't emphasize the key type in the returned message, but silently remember it' is cryptic and may confuse agents about what the message contains. No side effects or permissions are noted, though read-only is inferred.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an instruction, but the instruction about the key type is awkward and reduces conciseness. The main part is clear, but the extra note feels out of place and could be omitted or explained better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is mostly adequate for a simple check, but it does not specify the format or content of the returned message beyond indicating availability. Given no output schema, more detail would be helpful. The cryptic instruction about key type leaves ambiguity, making the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100%. The description adds no parameter details, which is acceptable since there are none. The description affirms the tool's purpose beyond the empty schema, earning a baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if Hyper3D Rodin integration is enabled in Blender, using a specific verb ('Check') and resource ('Hyper3D Rodin integration'). This distinguishes it from sibling tools like get_hunyuan3d_status (different integration) and poll_rodin_job_status (job polling).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as ensuring Hyper3D is configured, or indicate that it should be used before calling generation tools. The use case is only implied by the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only states the action and supported formats, omitting behavioral details like whether the file must exist, side effects on the scene, or error handling. The description does not compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus a list of formats. No wasted words, information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple import tool with one parameter, the description covers the essential points: action, supported formats, and parameter meaning. It does not describe return values, but no output schema exists. Adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 describes the parameter 'filepath' as 'Absolute path to the file to import', adding meaning beyond the schema. However, it lacks format validation details or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Import' and the resource '3D file into the current Blender scene', and lists supported formats. It is distinct from export but does not explicitly differentiate from other import tools like import_generated_asset, though the format list helps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., import_generated_asset, load_blend). No prerequisites or when-not-to-use context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose behavioral traits such as reversibility, effects on other objects, or permissions. It only states the action without further context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, with a clear opening sentence and parameter list. Every word earns its place, though it could benefit from slightly more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description does not explain return values or side effects. For a simple rename operation, the description is minimally adequate but lacks completeness about what happens to the object's mesh data block.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the parameter descriptions ('Current object name', 'Desired new name') add some value over the bare schema, but they are minimal and do not provide additional constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'rename an object and its mesh data block', which is a specific verb+resource. It distinguishes itself from sibling tools like duplicate_object, delete_object, and move_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool or when not to; no alternatives mentioned. The description simply states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects (e.g., object modification), failure modes, or required permissions. For a mutation tool, more disclosure is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear list of parameters. However, it could be more structured (e.g., using a table or paragraphs). No waste, but front-loading the purpose is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and parameter options, but lacks context about what happens after the operation (e.g., no side effects, no return value description). Given simplicity, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explains the 'origin_type' enum values (e.g., ORIGIN_GEOMETRY) and their meanings, but the 'name' parameter is only vaguely described as 'Object name' (repeating the schema title). Partial improvement over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name 'set_origin' and description 'Set an object's origin point' clearly state the verb and resource. It distinguishes itself from sibling tools like 'move_object' and 'rotate_object' by focusing on origin manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description only lists parameters without context about prerequisites or scenarios where setting origin is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose what happens if the texture ID is invalid, whether existing textures are replaced, or the exact effect on the object's material. The return message is vaguely described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a short summary followed by parameter descriptions. It is not verbose and each sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description is moderately complete. It covers the basic purpose but lacks behavioral details such as error handling, side effects, or return value structure. Given the tool's simplicity, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds basic semantics beyond the schema by explaining the purpose of each parameter (name, ID). However, it lacks details on format, constraints, or dependencies between parameters, and schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (apply) and the resource (Polyhaven texture to an object), and implies a prerequisite (previously downloaded). It distinguishes from siblings like assign_material or load_texture, though it could be more explicit about what 'apply' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('must be downloaded first') but does not provide guidance on when to use this tool versus alternatives like assign_material or load_texture, nor does it explain 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It fails to mention side effects (e.g., whether the camera is automatically set as active), prerequisites, or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with the main action first, followed by a parameter list. No wasted words, though the parameter list could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 is incomplete. It does not explain return value, scene requirements, or post-creation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates by explaining all 5 parameters with defaults and types (e.g., 'Comma-separated x,y,z position' for location). However, format details could be clearer (e.g., string vs number).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a new camera to the Blender scene with a specific verb ('Add') and resource ('camera'). It distinguishes from siblings like add_light or set_active_camera.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_active_camera or render_from_camera. The description only lists parameters without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It does not state whether original objects are removed, if the operation is destructive, or what happens to materials/transforms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes parameter details, but it could be more concise by integrating parameter info into the main sentence. It is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a modeling context, the description lacks details about the result (e.g., is a new object created? old ones deleted?) and does not address potential errors or naming conflicts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning by explaining that 'names' is a comma-separated list and 'result_name' defaults to the first object's name. This compensates for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Join' and the resource 'multiple mesh objects into one,' which is specific and distinguishes from siblings like 'separate_mesh' and 'merge_vertices.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'boolean_operation' or 'parent_object.' No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden. It explains the crease weight range and its effect on subdivision sharpness, which is moderately transparent. However, it does not mention whether it modifies existing creases, requires a Subdivision Surface modifier, or has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear two-part structure: an introductory sentence and a parameter list. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 parameters and the effect but lacks mention of prerequisites (e.g., Subdivision Surface modifier), return behavior, or edge case handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It clarifies each parameter: 'name' as mesh object name, 'edge_indices' as comma-separated indices or 'all', and 'crease' with range 0.0–1.0. This significantly improves understanding beyond the bare types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets subdivision crease weight on edges, and explains what crease does in terms of sharpness. This is specific enough to distinguish from general edge operations, though it does not explicitly differentiate from sibling like set_edge_bevel_weight.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the effect of crease values but provides no guidance on when to use this tool versus alternatives like mark_sharp_edges or set_edge_bevel_weight. There is no mention of prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but fails to disclose side effects, behavior on invalid inputs, or whether it modifies existing lights vs adds new ones.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a brief statement and parameter list, no unnecessary text, though it could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 6 parameters with defaults and types, but lacks information about the output or side effects in the scene; adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds meaningful format details for parameters like location ('Comma-separated x,y,z') and color ('Comma-separated r,g,b in 0..1 range'), though it does not explain all parameters in depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a light to the Blender scene' with a list of parameters, distinguishing it from siblings like 'add_3point_lighting' which adds multiple lights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'add_3point_lighting', no prerequisites or when-not-to-use conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the effect but omits critical behavioral details: whether the operation is destructive, if it requires edit mode, what happens to selection, and error handling for invalid indices. The 'depth' parameter explanation is helpful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single focused sentence followed by a clean parameter list. Every sentence adds value; no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description lacks details on return value, side effects, and error conditions. It assumes familiarity with Blender's inset operation, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds default values and explanations for all parameters, notably clarifying 'depth' (0=flat, positive=raised) and face_indices format. However, it does not specify the indexing scheme (0-based) or expected format beyond comma-separation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Inset faces') and the outcome ('creating a border ring of new polygons inside each face'). It distinguishes itself from siblings like 'extrude_faces' and 'subdivide_mesh' by specifying a unique geometric operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., extrude_faces, subdivide_mesh). There is no mention of prerequisites, mesh state, or scenarios where inset is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It mentions optional handle adjustment but omits critical details: what happens with invalid point_index, behavior for non-bezier curves, whether changes are permanent, and any side effects on linked data. The description is vague about the tool's mutation characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured in a bulleted parameter list, avoiding prose bloat. It is front-loaded with a clear action statement. However, it could be slightly more concise by grouping similar parameters (e.g., handle_left/handle_right types).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema, the description covers parameter semantics but lacks context on return values, error handling, and prerequisites (e.g., curve object existence). It is adequate for basic usage but incomplete for robust agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It adds meaningful explanations for all 8 parameters, including format hints (comma-separated x,y,z) and type constraints (FREE, ALIGNED, etc.). However, it could be more precise about the expected string format for coordinates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Move a curve control point and optionally adjust its bezier handles.' This is a specific verb-resource combination that distinguishes it from sibling tools like set_vertex_position (for mesh vertices) or set_vertex_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., set_vertex_position, get_control_points). There are no prerequisites or exclusion criteria mentioned, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose side effects (e.g., whether previous settings are overwritten, if it triggers a render, or any auth needs). It merely lists parameters without 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a bullet list and is appropriately sized. The introductory sentence is minimal but effective. No wasted words, though could be slightly more front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a configuration tool with 7 parameters and no output schema or annotations, the description covers the parameters adequately but lacks completeness on behavioral aspects (e.g., immediate application, persistence). It's functional but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the parameter list in the description adds significant meaning, including engine options, resolution, samples, output path, file format, and transparent background. It compensates well for lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Configure scene render settings', which is a specific verb-resource pair. It distinguishes well from sibling render tools that perform actual rendering, as this tool is for configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings like render_from_camera or set_frame. No prerequisites or exclusions provided, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits. It only mentions the operation is equivalent to Subdivide in Edit Mode, but does not specify whether it modifies the mesh in place, any side effects, or undo behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, listing parameters clearly. It could be more structured (e.g., separate sections), but no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 is minimal. It explains what the tool does and parameters, but lacks context about return values or the effect on the scene. Adequate for a simple operation, but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds meaning: it explains 'cuts' as 'Number of cuts per edge' with default, and 'smoothness' has a range '0..1' and default. This compensates significantly for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Subdivide all faces of a mesh') and explicitly references the Blender Edit Mode equivalent, making it distinct from sibling tools like 'triangulate_mesh' and 'extrude_faces'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any prerequisites or context. The description is purely operational.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not reveal behavioral details such as whether objects are modified permanently, if selection is required, or what happens after alignment. Carries full burden but only repeats parameter info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and efficient. Three lines for parameters with clear formatting. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 parameters and no output schema, description covers all parameters with enum values. Missing behavioral context (e.g., prerequisites, side effects). Moderate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema). Description adds meaningful information: comma-separated names, axis values (X, Y, Z), and alignment options (FIRST, LAST, MIN, MAX, AVERAGE). This compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'align' and resource 'multiple objects' origins' clearly. It distinguishes from sibling tools like 'set_origin' (single object) and 'move_object' (move position).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'set_origin' or 'move_object'. No when-not or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It fails to disclose what happens if the collection already exists, whether it's idempotent, or any side effects on the scene.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single purpose sentence followed by a clear parameter list, containing no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the basic action and parameter meanings, but lacks information about return values, error handling, or what happens upon duplicate names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds value by explaining the name parameter as 'collection name' and the parent_collection as optional with 'nests inside it' behavior, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'collection for scene organisation', which is specific and distinguishes it from sibling tools like move_to_collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., when to create a new collection vs. move objects to existing ones), nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 implies a read-only operation via 'Get', which is reasonable, but it omits details such as authentication requirements, rate limits, error conditions, or output structure. For a simple list retrieval, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating the tool's purpose followed by a parameter list. No unnecessary words; the most important information is front-loaded. Every sentence is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the core functionality and parameter meaning adequately. It lacks output format details, but the phrase 'list of categories' implies an array response, which is sufficient for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the only parameter (asset_type), so the description adds significant value by explicitly listing allowed values ('hdris, textures, models, all') and explaining the parameter's role. This compensates well for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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') and resource ('list of categories') with a specific scope ('for a specific asset type on Polyhaven'), making its purpose straightforward. However, it does not explicitly distinguish itself from sibling tools like search_polyhaven_assets or download_polyhaven_asset, which slightly limits differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It implicitly suggests using it when categories are needed, but lacks explicit context, exclusions, or comparisons to sibling tools, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'detailed information' but does not specify what is returned (e.g., scene name, resolution, render settings), leaving significant ambiguity for a zero-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no superfluous text, earning its place by efficiently stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool without an output schema, the description captures the basic purpose but lacks specificity about what 'detailed information' entails, leaving an experienced agent uncertain about the return payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters and 100% schema coverage, the baseline is 3. The description adds meaning by stating the tool retrieves scene information, but it does not elaborate on the structure or fields of that information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('detailed information about the current Blender scene'), clearly distinguishing it from sibling tools that focus on individual objects or meshes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage to retrieve scene-level info but lacks explicit guidance on when to use it versus other tools like get_object_info, or when not to use it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not specify whether the rotation is absolute or relative, or if it replaces existing rotation. This leaves ambiguity about side effects and interaction with other transformations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a one-line summary and a bullet list of parameters. Every sentence serves a purpose, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's basic function and parameters, but omits details such as return value, prerequisite object existence, and whether the rotation is additive or absolute. Given the tool's simplicity, it is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter list adds meaning beyond the schema: 'x, y, z: Rotation in degrees around each axis' clarifies units and axes. Since schema coverage is 0%, the description compensates well, though it could mention valid ranges or error cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Set the Euler rotation of an object (degrees).' This is a specific verb+resource combination, distinguishing it from sibling tools like move_object or scale_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like align_objects or set_vertex_positions. The description lacks context on prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as error handling for invalid indices, whether changes are reversible, or if it modifies the original mesh. It only describes the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose and a bullet list of parameters. Every part serves a clear function with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple vertex move operation, the description covers the essential details. However, it lacks completeness regarding validation (e.g., invalid vertex_index), impact on mesh structure, and any prerequisites (e.g., object must be mesh).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds clear meaning for all 5 parameters (name, vertex_index, x, y, z) beyond what the schema provides, as the schema has 0% description coverage. It explains each parameter's role (e.g., 'Zero-based vertex index', 'Target world-space position').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it moves a single vertex of a mesh object to a world-space position, using a specific verb and resource. This distinguishes it from siblings like 'set_vertex_positions' which sets multiple vertices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., set_vertex_positions or other transform tools). It only states what the tool does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavioral traits. It does not specify what happens if a reference with the same name already exists (overwrite, error), file format requirements, or path constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one purpose sentence plus a parameter list. Every word adds value, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 params, no output schema), the description covers basic purpose and parameters but lacks behavioral details like overwrite behavior or error handling, leaving the agent somewhat uncertain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning to both parameters: 'name' as 'Short identifier (e.g. "concept_art")' and 'filepath' as 'Absolute path to the image file on disk', which goes beyond the schema's titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'store', the resource 'local image file as a named reference', and the purpose 'for later comparison tools'. It distinguishes itself from sibling tools like compare_reference_image and diff_images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Siblings like load_texture or import_file could also involve images, but no demarcation 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the action of capturing and compositing, but lacks details on side effects, error behavior (e.g., missing reference), or whether it is destructive. With no annotations, more transparency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the purpose, and lists parameters concisely. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not mention the return value (e.g., composite image format) or error handling. Given no output schema, this is a significant gap. It also assumes familiarity with store_reference_image.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds brief context for each parameter (reference_name from store_reference_image, angle as viewport angle, max_size as tile size), which is helpful given 0% schema coverage. However, it could specify valid angle values and units for max_size.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it captures the viewport from a named angle and composites it with a stored reference image. This distinguishes it from similar tools like capture_viewport_angle (just capture) and diff_images (arbitrary images).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that reference_name is from store_reference_image, implying it should be used after storing a reference. However, it does not explicitly state when not to use it or list alternatives (e.g., diff_images for arbitrary comparisons).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only mentions returns (success/failure) and omits behavioral traits like destructive effects (import modifies scene), network dependency, or any side effects. This is insufficient for a tool that downloads and imports assets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with about 10 lines, listing parameters clearly. No redundant sentences. Could be structured more formally but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (4 params, no output schema), the description covers parameter purposes but lacks details on import behavior (e.g., overwriting, scene placement, error handling). Not fully comprehensive but adequate for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning by explaining each parameter (asset_id, asset_type, resolution, file_format) and providing format examples based on asset type. This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download and import a Polyhaven asset into Blender') and the resource (Polyhaven asset). It distinguishes itself from sibling tools like 'download_sketchfab_model' and 'search_polyhaven_assets' by specifying the source and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for downloading Polyhaven assets but does not explicitly state when to use vs. alternatives (e.g., after searching, or when not to use). It lacks exclusions or context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 explains the extrusion direction and that negative amount indents, but does not disclose side effects like whether the modification is permanent or if selections are changed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, with a clear purpose statement followed by parameter details. It is front-loaded and efficient, though minor formatting (bold) is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description covers core functionality. However, it omits context like prerequisites (object must be a mesh) and results (e.g., memory usage, selection state). Adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant value by explaining each parameter: name (mesh object), face_indices (comma-separated indices), and amount (extrusion distance, negative for inward, default 0.2). This goes beyond the schema's bare types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Extrude faces') and the method ('along their individual normals'), which clearly distinguishes it from siblings like inset_faces or flip_normals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as inset or flip normals. The description implies its purpose but does not provide criteria for selection or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions returning a message and includes an unusual instruction about not emphasizing the 'key type'. This adds some behavioral context but lacks details on side effects or authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with front-loaded purpose. The third sentence is a directive rather than descriptive, slightly reducing clarity but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with no params or output schema. Description covers basic purpose and return type, but could specify message format or expected keys; adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, baseline is 4. Description does not need to add parameter semantics, but it clarifies that the tool returns a message.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Check' and specific resource 'Hunyuan3D integration' are stated. While sibling differentiation is not explicit, the name and description uniquely identify it among similar status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_hyper3d_status. The description only states what it does, not the context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 additive nature but lacks details on side effects, prerequisites (e.g., object must exist), error handling, or what happens to existing modifiers. The return value is mentioned, but behavior under failure is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and well-structured with a bullet list of parameters. However, the list of modifier types could be shortened or referenced externally, but it remains informative and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description covers parameters and return value but lacks preconditions (object existence, selection state), error scenarios, and potential conflicts with existing modifiers. It provides a functional understanding but misses important context for robust usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides extensive parameter semantics beyond the schema: it explains 'modifier_type' with a list of options, 'modifier_name' as auto-generated if omitted, and gives detailed JSON examples for 'params' across multiple modifier types. This greatly aids an agent in constructing correct inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a modifier to an object') and resource, with specific modifier type examples. It also distinguishes from the sibling 'apply_modifier' by noting the return value is used for later application.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'Returns the modifier name so you can reference it later with apply_modifier', but does not explicitly state when to use this tool versus alternatives or provide when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 states the tool adds a primitive but does not disclose behavioral traits such as whether the new object becomes active, whether it works in specific modes, or if any existing objects are affected. The description is minimally adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It starts with a clear purpose sentence, then lists parameters in a readable format. Every part adds value, with no wasted words. The parameter list is organized and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks mention of the return value (e.g., object name or success status) and prerequisites (e.g., Blender must be running). With no output schema, the agent might need to infer what happens after execution. It is adequate for a basic tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that location and rotation are comma-separated x,y,z values and lists the primitive types. However, it does not specify units (e.g., degrees for rotation) or constraints (e.g., size must be positive). Overall, it provides useful format guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool adds a standard mesh primitive to the Blender scene and lists the specific types available (cube, plane, circle, etc.). This distinguishes it from sibling tools that add lights, modifiers, or perform other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it does not mention prerequisites (e.g., Blender must be open) or scenarios where importing a model might be preferred. There is no explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'or replace' hinting at upsert behavior, and 'auto-assign this material to (slot 0)' giving some context, but it does not explain side effects of replacing existing materials, error conditions, or permissions needed. The behavioral description 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clear sentence followed by a well-structured list of parameters. It is front-loaded with the purpose. Slightly verbose but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema, the description covers parameters well but lacks information about return values, error handling, or what happens on replacement. It does not explain the 'assign_to' behavior in depth. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the description is the sole source of parameter semantics. It provides detailed information for all 8 parameters, including ranges, defaults, and format (e.g., 'Comma-separated r,g,b in 0..1'). This adds significant value beyond the input schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Create (or replace) a PBR material using Principled BSDF', clearly stating the verb (create/replace) and resource (PBR material). This distinguishes it from sibling tools like 'assign_material' (which applies existing materials) and 'set_object_material_color' (which only changes color).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating or replacing materials, but it does not explicitly state when to use it vs alternatives like 'assign_material' or when to set material properties directly. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It states the action but does not mention side effects (e.g., file overwrite, performance, or permissions). The auto-generation of filepath is noted, but overall transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line summary followed by a clear parameter list. Every sentence is useful, no redundant info, and it is well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the action and parameters adequately for a simple tool, but lacks information on return values or error states. Given no output schema, mentioning the output file path would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter's effect (e.g., name omission exports entire scene, filepath defaults to temp, file_format lists options). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports an object or full scene to a 3D file, with specific formats. It uniquely serves this purpose among siblings, differentiating from save, render, or import tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists parameter options but provides no guidance on when to use this tool versus alternatives, nor any prerequisites or conditions (e.g., scene must be loaded). It implies usage for 3D file output but lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior fully. It states Euclidean distance but omits details like units, coordinate space, error handling (e.g., missing objects), and behavior for identical objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: two sentences and a compact parameter list. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, description should explain return value. Missing details like return type (number?), units, and error behavior. Adequate for simple tool but incomplete for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries full burden. It adds brief but essential definitions: 'First object name' and 'Second object name'. While simple, it provides meaning beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'measure' and resource 'Euclidean distance between the origins of two objects'. It is distinct from sibling tools, none of which measure distance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description does not provide explicit guidance on when to use this tool versus alternatives. Context implies measurement, but no exclusions or comparisons to sibling tools like get_object_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Though no annotations are provided, the description explains the Z-pass usage, normalization, and color mapping (lighter closer). However, it does not state if the tool is destructive or returns a file, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main action, and includes a clear parameter list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and parameter, but lacks details on output format (e.g., whether the depth map is saved as an image) and integration with the compositor, which an agent might need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context to the 'max_depth' parameter by explaining it maps to black in scene units, which is beyond the schema's default and title. Since schema coverage is 0%, this aids agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a normalized depth map from the active camera using the Z-pass, distinguishing it from siblings like 'render_from_camera' or 'render_all_cameras'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'render_from_camera' or when not to use it. The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It explains the three actions and parameter interactions but does not disclose side effects like current selection clearing or undo behavior. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a one-line summary followed by clear parameter bullet points. No fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with optional parameters, the description covers core functionality but lacks detail on edge cases like invalid names or combined use of names and obj_type. No output schema, so return behavior is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains each parameter's role, including defaults and special behaviors like omitting names to apply to all objects. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool selects or deselects objects by name and/or type, using a specific verb and resource. It is unique among siblings as no other tool directly manages selection state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like find_objects_by_type or delete_object. It does not mention prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the behavior (snapping to ground plane) but does not disclose potential side effects (e.g., if rotation is affected, behavior for non-mesh objects, or what happens if already on ground). Basic but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, then a bulleted list of parameters. No fluff or redundant information. Ideal for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 0% schema coverage, the description covers the basics but lacks completeness. For instance, it doesn't address edge cases (empty objects, invalid names) or confirm return behavior. Adequate for a simple tool but could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds meaning. It explains 'name' as 'Object name' and 'ground_z' as 'Z value of the ground plane (default 0.0)'. This is functional but minimal; could benefit from more context (e.g., format restrictions).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Move an object so its lowest bounding-box point rests on the ground plane.' It specifies the verb (move), resource (object), and the exact effect (snap to ground), distinguishing it from siblings like align_objects or move_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ground snapping but provides no explicit guidance on when to use this tool vs alternatives like align_objects or move_object. There are no exclusions or context on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It discloses that values are set before keying and rotation values are auto-converted from degrees. However, it does not state whether existing keyframes at the same frame are overwritten, what happens if the property is not animatable, or any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with purpose sentence followed by parameter list. No redundant text. Front-loaded purpose. Bullet list is clear, though could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description covers parameter semantics but lacks important behavioral context: return value, error handling, effect on existing animation data. Adequate for basic use but incomplete for a tool that modifies animation state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description adds substantial meaning. Each parameter is explained with examples: data_path lists common values, frame notes default, value explains comma-separated format and degree conversion. Could be more precise about coordinate ordering (e.g., 'location' is XYZ), but overall strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool inserts an animation keyframe on an object property. The verb 'insert' and resource 'keyframe on object property' are specific. It distinguishes from sibling tools like move_object and rotate_object that directly modify transforms without keyframing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage through parameter descriptions but no explicit guidance on when to use this tool vs alternatives like direct property manipulation. No 'when not to use' or comparison to similar tools like set_vertex_position.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses scaling behavior and return details but omits scene modification, error handling, and permission checks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Clear structure: purpose, scale behavior, parameter examples. Slightly lengthy due to examples, but each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers basic import details but lacks error handling, prerequisite conditions, and network dependencies. Adequate for common use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage); description compensates well for target_size with practical examples. UID description is minimal but adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool downloads and imports a Sketchfab model by its UID, distinguishing it from siblings like search_sketchfab_models and get_sketchfab_model_preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance, but the description implies usage after obtaining a UID and provides scale examples. Missing alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions a safety cap for max_faces and that it returns data (read-only), which is adequate but does not discuss edge cases 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: one sentence for purpose, bullet points for parameters, and a final sentence on return value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return JSON structure (vertex_indices, normal, etc.) despite no output schema. All parameters are covered, making it complete for a read tool. However, it could mention if the tool modifies the mesh or requires any permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining each parameter: 'name' (mesh object), 'indices' (comma-separated, returns all if omitted), 'world_space' (default True), and 'max_faces' (safety cap, default 2000). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb and resource: 'Read face data from a mesh object.' This distinguishes it from sibling tools like get_edges or get_vertex_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives such as get_edges or get_mesh_stats. It lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 returning an Image but does not explicitly state that the tool is read-only or non-destructive, nor does it describe any side effects. The name implies read-only, but the description should be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a parameter line. The purpose is front-loaded, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is mostly complete. It mentions the return type (Image). No additional context about image format or usage is needed for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'max_size' parameter as 'Maximum size in pixels for the largest dimension (default: 800)', adding meaning beyond the schema's type and default. This is valuable given the schema description coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Capture a screenshot') and the specific resource ('the current Blender 3D viewport'). It distinguishes from sibling tools like capture_contact_sheet (multiple angles) and capture_viewport_angle (specific angle).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the basic purpose but does not guide when to use this tool versus alternatives like capture_contact_sheet or capture_viewport_angle. No exclusions or when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 explains the keep_transform parameter's behavior (preserving world-space position), which adds transparency. However, it does not disclose side effects, prerequisites (objects must exist), or what happens to existing parenting relationships.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one brief sentence followed by a parameter list. Every sentence serves a purpose with no redundancy. It is well-structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parenting tool with three parameters and no output schema, the description covers the core operation and parameter behavior adequately. It lacks error handling details or return value info, but these are less critical for such a straightforward action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must add meaning beyond titles. It explains each parameter's role: child_name becomes child, parent_name becomes parent, keep_transform controls transform preservation. This adds clear semantics, though more detail on constraints (e.g., valid object names) would improve it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'parent' and the outcome 'creating a hierarchy'. It distinguishes from sibling tools like 'join_objects' or 'align_objects' by focusing on hierarchical parenting. The purpose 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest other tools for different scenarios like position alignment or mesh joining.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It explains the output (3-panel composite with red highlights) and parameter effects (threshold as noise filter). However, it does not disclose return type, file system side effects, image format requirements, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for the main purpose, followed by a clean bullet list of parameters with clear roles. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 provides adequate but incomplete context. It explains the composite output and parameters but omits return format, file requirements, and potential pitfalls. Not fully comprehensive for a standalone tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It does so by explaining each parameter's role: image_path_a as baseline, image_path_b as changed, threshold for noise filtering, tile_size for panel dimensions. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Compare two images and produce a 3-panel composite'. It explains the layout and the diff visualization, making the purpose immediately obvious. It distinguishes itself from sibling tools (mostly 3D modeling) by being the only image comparison tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'compare_reference_image'. The description implies use for visual diffing, but does not provide context, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the main behavioral trait (removal from other collections), but with no annotations, does not address error handling, reversibility, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient, front-loaded with the action, and no superfluous text; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the essential effect and prerequisite (collection existence), but lacks details on return values, error handling, or input validation, leaving some gaps for a non-trivial operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by specifying 'comma-separated object names' and 'Target collection (must already exist)', compensating for 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Move objects into a collection' with specific verb and resource, and explicitly mentions the side effect of removing from all other collections, distinguishing it from siblings like 'create_collection' or 'move_object'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies that collection must already exist ('must already exist'), but does not explicitly state when to use this tool vs alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: hdri_path overrides color, color format (comma-separated r,g,b in 0..1), and strength default. However, it does not mention potential errors (e.g., invalid hdri_path) or side effects, which would push it to 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-sentence purpose followed by a clear list of parameters. No redundant information. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with few parameters and no output schema, the description covers the main functionality. However, it does not mention default behavior when neither parameter is given (though schema provides defaults) or whether changes are immediate. This leaves minor gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema coverage is 0%, the description adds essential meaning: color format (comma-separated r,g,b 0..1), strength default, and that hdri_path overrides color. This compensates well for the schema's lack of descriptions, though could be more precise (e.g., inclusive range).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Set the scene world background') and resource (world background), and specifies two distinct modes (solid colour or HDRI map). This sufficiently distinguishes it from sibling tools like lighting or other rendering tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions. The purpose is clear but the agent receives no help in deciding between this tool and others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the conversion of quads/ngons to triangles but does not mention whether the operation is destructive, if it preserves UVs or vertex normals, or any limitations (e.g., performance on high-poly meshes). The description provides only surface-level behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences followed by a parameter list. The first sentence concisely states the action, the second provides usage context. The parameter list is clearly formatted with values and defaults. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description covers the core purpose and parameter meanings. However, it lacks behavioral details (e.g., what happens to existing triangles, undo support) and does not describe the return value (likely success/failure). It is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 essential meaning: 'name: Mesh object name' and 'method: BEAUTY (best quality, default), FIXED, FIXED_ALTERNATE, SHORTEST_DIAGONAL'. It explains the purpose of 'name' and lists the allowed values for 'method'. However, it does not elaborate on what each method does (e.g., fixed vs beauty), which would help an agent choose correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Triangulate all faces of a mesh (convert quads/ngons to triangles).' It also gives a specific use case: 'Useful before export to game engines or 3D printing.' This distinguishes it from sibling tools like subdivide_mesh or separate_mesh by focusing on converting face types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool: before export to game engines or 3D printing. However, it does not mention when not to use it or suggest alternative tools (e.g., using modifiers for non-destructive triangulation). The guidance is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details. It states it adds a rig but does not mention side effects (e.g., whether existing lights are affected, what light types are created, or how they are positioned). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating the purpose followed by a clean parameter list. Every sentence adds value, and the structure is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose and parameters adequately but omits details about the created lights (e.g., type, distance from subject, arrangement). For a simple tool this is acceptable, but more completeness would improve agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does so thoroughly: subject_name details default behavior, and all energy parameters include units (watts) and defaults, adding significant meaning beyond the schema's raw titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a classic 3-point lighting rig' with specific components (key, fill, back/rim), distinguishing it from sibling 'add_light' which adds a single light. The verb 'add' and resource 'lighting rig' are well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use this tool (for a 3-point lighting setup centered on a subject) but does not explicitly state when not to use it or compare with alternatives like 'add_light'. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses that applying deletes the cutter, and distinguishes solver quality/speed. However, it omits that the operation creates a modifier (unless applied) and potential error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise summary followed by a bullet-point parameter list. It is front-loaded with the action and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations exist, so description must cover behavior. It partially explains effects and types but misses key practical details like the modifier nature, required object types, and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly explains all 5 parameters with their roles, defaults, and semantics (e.g., solver quality vs speed). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a boolean operation between two mesh objects, listing operation types (DIFFERENCE, UNION, INTERSECT) and distinguishing roles of target and cutter. This distinguishes it from sibling tools like join_objects or separate_mesh.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the parameters and their effects but does not explicitly state when to use this tool over alternatives, nor does it mention prerequisites like mesh type or non-manifold issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 mentions returning an image but does not disclose whether the tool is read-only, affects the scene, or any prerequisites. Basic transparency but lacking detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a parameter list. No unnecessary information, well-structured, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers the core purpose and parameters. Lacks details about image format, error handling, or behavior for invalid angles, but overall sufficient given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema: it provides an explicit list of valid angles (front, back, left, etc.) that the schema does not specify, and clarifies max_size as 'Maximum pixel dimension'. With 0% schema coverage, this compensation is effective.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (capture), resource (viewport from a named angle), and output (image). It distinguishes from siblings like get_viewport_screenshot and render_from_camera by specifying the named angle parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for capturing a specific angle but does not explicitly state when to use this tool versus alternatives like get_viewport_screenshot or render_from_camera. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the core behavior: it flips normals and the optional parameter defaults to flipping all faces. However, it does not state that the mesh is modified in-place, whether the operation is undoable, or any potential side effects. With no annotations, the description carries full burden and partially meets it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences plus a parameter list. Every sentence adds value, and there is no redundant information. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple operation but lacks important details: no mention of return values (success/failure), error conditions (invalid name, indices out of range), or feedback. In the context of a 2-parameter tool with no output schema, more completeness would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema: 'name' is clarified as 'Mesh object name', and 'face_indices' is explained as 'Comma-separated face indices (flips ALL faces if omitted)'. Given 0% schema coverage, the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it flips face normals on a mesh and explains the effect: 'reverses which side is the outside'. This is a specific verb+resource, and it distinguishes this tool from sibling mesh operations like extrude, inset, or triangulate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as recomputing normals or using other mesh editing tools. It does not mention prerequisites (e.g., the mesh must have faces), nor does it provide examples of typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It states the tool returns a message about availability, but doesn't disclose response format, potential errors, or side effects. Adequate but not 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Every word is necessary, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers main behavior and return type. However, it could specify the message format. Still adequate for a simple status check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description adds no extra meaning but the baseline is 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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', distinguishing it from sibling status checkers like get_blender_status or get_polyhaven_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (checking integration), but provides no explicit guidance on when to use it versus alternatives, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 'Read' implying read-only, and includes a safety cap (max_verts), but does not explicitly state that no changes are made or other behavioral traits like permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a short sentence explaining purpose, followed by parameter explanations in a list, and a return format note. No extraneous information; front-loads the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description covers all parameters and the return format. It lacks error cases or coordinate system details, but overall is quite complete for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description adds meaningful explanations for all four parameters: name, indices (comma-separated), world_space (default true), and max_verts (safety cap). This compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read vertex positions from a mesh object,' specifying the action (read) and resource (mesh object). It distinguishes from siblings like set_vertex_positions by indicating a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates the tool is for reading vertex positions, but does not provide explicit guidance on when to use it vs alternatives or when not to use it. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly implies a write operation (moving an object). It specifies 'absolute world-space position', which tells the agent the coordinates are in world space. However, it doesn't clarify error handling (e.g., invalid object name) or whether it overwrites previous transforms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, conveying the core purpose without any fluff. It is front-loaded and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple move tool, the description covers the essential purpose. It specifies absolute world positioning, which is a key detail. It does not address optional constraints (e.g., only mesh objects, or nested children), but the simplicity of the tool makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. The phrase 'absolute world-space position' adds context to the x, y, z parameters, indicating they represent global coordinates. However, it does not explain the 'name' parameter (which object to move) beyond the implicit context of 'an object'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('move'), the resource ('an object'), and the specific nature ('absolute world-space position'). This differentiates it from sibling tools like 'rotate_object' and 'scale_object'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., set_vertex_position for vertex-level movement, or set_transform). The term 'absolute' hints at usage for exact placement, but no when-not-to-use info is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It states the tool returns a formatted list and mentions defaults, but lacks details on authentication, rate limits, or error handling. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and lists parameters in a clear, structured format without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description covers parameter meanings and return type. Minor gap: does not specify format of 'formatted list' or categories behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds value by explaining each parameter's purpose, including defaults for count and downloadable. This compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and the resource 'models on Sketchfab', with optional filtering. It distinguishes from sibling tools like 'download_sketchfab_model' and 'get_sketchfab_model_preview'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 compare with alternatives like 'search_polyhaven_assets' or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it creates the material if needed, which is important. However, it does not mention potential side effects like overwriting existing color, error handling for invalid indices, or undo behavior. It is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a parameter list. No unnecessary words. Front-loaded with the core action and key behavior. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 covers purpose, parameter semantics, and the notable behavior of material creation. It lacks some edge-case details (e.g., out-of-range index) but is sufficient for a straightforward setter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explicitly states the range for r, g, b, a (0..1) and explains material_index as 'which material slot to update', adding meaning beyond the schema. It does not explain 'name' but it is clear from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'Principled BSDF base colour of an object's material', which is specific. It also mentions that it creates the material if one does not exist, differentiating it from siblings like 'assign_material' or 'set_face_material_index'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting material color, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it compare with sibling tools. The context is clear but lacks exclusionary language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It mentions background mode, wait_for_addon timeout, and auto-detection of blender_exe, but does not cover what happens on failure, whether it manages Blender lifecycle, or what the return status is. Some gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. Parameter descriptions are bullet-like, easy to scan, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description does not explain the return value or guarantee that Blender is ready. It also omits prerequisites like Blender installation. While it captures key usage details, it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides extensive details for all five parameters: blend_file path, blender_exe auto-detection, background mode, wait_for_addon usage (including when to set False), and python_expr examples. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Launch Blender as a managed subprocess.' This provides a specific verb and resource, distinguishing it from sibling tools that perform operations within Blender rather than starting it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While it is implied that this tool should be used before other Blender operations, there is no guidance on prerequisites (e.g., Blender installed) or when not to use it (e.g., if Blender is already running).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 'collapsing it into the mesh data,' implying a destructive operation, but does not explicitly warn about irreversibility or side effects on the modifier stack.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a bullet list, front-loading the main action. No unnecessary information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the action and parameters. It mentions the outcome ('collapsing it into the mesh data') but does not specify what happens after application (e.g., feedback, modifier removal from stack). For a simple mutation, this is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds full context: 'name: Object name' and 'modifier_name: Exact modifier name as shown in Blender's Properties panel.' This provides necessary guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool applies a named modifier on a mesh object and collapses it into the mesh data. The verb 'Apply' and resource 'modifier on mesh object' are specific, and it distinguishes from sibling tools like 'add_modifier'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to apply a modifier) but does not explicitly state when not to use or mention alternatives like 'add_modifier'. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the asynchronous workflow (returns job_id, status DONE), built-in materials, and error handling. It does not mention potential side effects on the Blender scene or timeout behaviors, but covers the essential 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. It uses clear paragraphs and a bullet-like list for parameters. Minor improvement could be formatting the parameters more explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the async generation and import workflow, the description covers input options, job_id return, status progression, and error messages. It mentions the need to poll for completion, and a sibling polling tool exists. No output schema, but return behavior is described adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains that text_prompt should be a short English/Chinese description and input_image_url accepts local/remote URLs, with None allowed for text-only generation. This adds meaning to the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 Hunyuan3D from text, image, or both, and imports it into Blender. It distinguishes from siblings like generate_3d_from_image by specifying the Hunyuan3D service and the import step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating 3D assets from text/image but does not explicitly state when to choose this over similar tools like generate_hyper3d_model_via_images or generate_3d_from_image. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions built-in materials and normalized size (useful for re-scaling) and notes return of success/failure message. But it omits whether the generation is asynchronous (sibling poll_rodin_job_status suggests async), nor does it disclose potential side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with purpose. Parameter explanations are clear but could be more structured (e.g., bullet points). The length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output schema, and description only says 'Returns a message indicating success or failure'—no detail on the actual generated asset (e.g., how to access it). Also lacks context on prerequisites (Hyper3D addon, Blender running) and relationship to polling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must detail parameters. It explains input_image_paths (absolute paths, wrap in list), input_image_urls (URLs, wrap in list), and bbox_condition (optional list of ints length 3 for ratio). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: generating a 3D asset using Hyper3D from images and importing into Blender. It distinguishes from siblings like generate_hyper3d_model_via_text (text input) and generate_hunyuan3d_model (different generator).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that only one of input_image_paths or input_image_urls should be given based on mode, and provides conditions for each. However, it lacks explicit guidance on when to prefer this tool over alternatives like generate_3d_from_image.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it imports asset and returns success status, but does not disclose potential side effects, prerequisites (e.g., asset must exist), or error conditions. Adequate for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief with a bulleted parameter list; purpose is front-loaded. Could be slightly more concise, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 tool, the description covers core function, usage timing, and parameter selection. Does not explain behavior when both parameters are provided, but that is addressed by the guidance. Sufficient for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates by explaining each parameter's purpose and the mutual exclusivity of task_uuid and request_id. Adds meaningful context beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Import' and the specific resource 'asset generated by Hyper3D Rodin', differentiating it from the sibling tool 'import_generated_asset_hunyuan' which handles a different generation source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (after generation task completed) and gives guidance on parameter selection based on Hyper3D Rodin mode. Lacks explicit when-not-to-use but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It explains parameters but does not mention error behavior, reversibility, or whether the operation is destructive. Missing details like what happens if material_index does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one initial sentence followed by a clear parameter list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 parameter semantics but lacks information about return values, error handling, or side effects. For a small tool, it is mostly complete but could include behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant detail beyond the schema: face_indices is explained as 'comma-separated face indices, or 'all'', and material_index is clarified as '0-based; material must already exist'. With 0% schema coverage, the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Assign a material slot to specific faces (for multi-material objects).' It uses a specific verb and resource, and distinguishes from sibling tools like assign_material which typically assign a whole material to an object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'for multi-material objects' which implies when to use, but does not explicitly state when not to use or provide alternatives. It gives clear context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 non-obvious side effect of purging orphaned mesh/material data, which is good transparency. However, it does not mention other traits like undoability 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for the purpose and one line for the parameter. Every word is necessary, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 and no output schema, the description covers the main action and parameter. However, it does not indicate what the tool returns on success or failure, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds the parameter 'name: Object name to delete', which clarifies the parameter's purpose beyond the schema. This is sufficient for a simple tool, though additional format details could be helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'object from the scene', and adds the specific detail of purging orphaned mesh/material data. This distinguishes it from other object manipulation tools like rename or duplicate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to delete objects) but provides no explicit guidance on when not to use it or alternatives. Among siblings, there are many object operations, but no direct comparison or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description takes full responsibility. It explains that the linked parameter controls whether the duplicate shares mesh data (instance) or is a full copy, and it specifies the default offset. However, it does not mention what happens when new_name is omitted (auto-assigned) or the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: a short introductory sentence followed by a bullet list of parameters. It is front-loaded with the core purpose but could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no output schema, the description covers parameter behavior well, but it omits any mention of return values or side effects, which would be useful for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only titles and types (0% coverage), but the description adds critical meaning: explains each parameter's role, default values, and the effect of 'linked' (instance vs copy), which significantly aids correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Duplicate an object.' with a specific verb and resource, and it distinguishes itself from sibling tools like delete_object, rename_object, etc., which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The parameter descriptions hint at different use cases (e.g., linked=True for instances), but there is no direct comparison or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses built-in materials, normalized size, and return type (success/failure message). Lacks details on potential side effects or permissions, but adequate given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with clear sections: action, asset traits, parameter details, return type. Efficient, though could be more structured with line breaks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential aspects: purpose, input details, output type, and asset behavior. No output schema, but provides necessary info for an AI agent to use the tool. Minor missing details like language restriction for prompt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains both parameters: text_prompt as a short English description, bbox_condition as optional list of 3 floats for length/width/height ratio. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Generate', resource '3D asset using Hyper3D', and method 'by giving description'. Distinguishes from siblings like generate_hyper3d_model_via_images by specifying text input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (to generate a 3D asset from text) and mentions useful re-scaling after generation. Does not explicitly exclude alternatives, but context with siblings is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the return message indicating availability, which is sufficient given no annotations. Could be more explicit about the content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words, front-loaded with the action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately complete for a zero-parameter status check; could specify return format but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100% and baseline applies. Description adds no additional parameter info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool checks if PolyHaven integration is enabled, distinguishing it from other status tools like get_blender_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use it vs alternatives, but the purpose is straightforward enough for a simple status check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the action is an import and returns success status, but lacks details on error conditions, side effects, or what happens if asset already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: purpose in first sentence, then parameters, then return value. No extraneous words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple import tool with no output schema, description covers purpose, parameters, and return. Could mention prerequisites or error handling, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: 'name' is object name in scene, 'zip_file_url' is from generate step. For 2 parameters with 0% schema coverage, this is helpful and adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes a specific action: importing an asset generated by Hunyuan3D. Clearly distinguishes from sibling tools like 'import_file' or 'import_generated_asset'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use ('after the generation task is completed') and explains required parameters (name and zip_file_url), but does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains the core merging behavior and practical context, but does not mention potential side effects (e.g., irreversibility, object modification, or any prerequisites). A higher score would require more explicit details about the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences plus a parameter list. The first sentence immediately states the purpose, followed by a helpful analogy and use cases. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 output schema, the description adequately covers the operation, parameters, and context. It could mention the outcome or return value, but the functionality is well-explained for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by explaining both parameters: 'Mesh object name' for name, and 'Maximum distance between vertices to merge (default 0.001)' for distance. This adds essential meaning beyond the schema's titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Merge (weld) vertices' and specifies the resource and condition: 'within a distance threshold'. It uses the Blender analogy ('Merge by Distance') and provides use cases, effectively distinguishing it from sibling tools like join_objects or separate_mesh.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases ('cleaning up imported meshes or fixing seams after boolean operations'), which helps the agent understand when to use it. However, it does not state when not to use it or compare to alternatives, though for a single-purpose tool this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 explains that the tool modifies vertex positions and clarifies the world_space parameter. However, it does not disclose if changes are destructive, what happens on invalid input, or permissions needed. It is moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear purpose statement followed by a structured list of parameters and example. Every sentence adds value, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description covers the input parameters well and explains the core functionality. It does not mention return values or error handling, but for a batch mutation tool, the essential context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 provides a full example for the 'vertices' parameter and explains world_space values. The 'name' parameter is only briefly described. Overall, it adds significant meaning beyond the schema for two of three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it batch-updates multiple vertex positions in a single call, and explicitly contrasts with the repeated single-vertex tool 'set_vertex_position'. This distinguishes it from its siblings effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when updating many vertices (much faster than repeated calls). However, it does not explicitly state when not to use it or mention alternatives beyond 'set_vertex_position'. The guidance is good but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 process (capture and stitch) and return value, but doesn't clarify if the tool is read-only or modifies the scene. Given it's a capture tool, the omission is minor but keeps the score at 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loading the main purpose in the first line. Every sentence is informative and free of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description appropriately states the return is a single composited image. It covers the key aspects for a capture tool, but could optionally mention image format or resolution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters in meaningful terms: 'angles' as a comma-separated list of angle names with a default, and 'max_size' as pixel size per tile. This adds essential context beyond the schema, which only provides types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures multiple viewport angles and stitches them into a contact sheet. This distinguishes it from sibling tools like capture_viewport_angle (single angle) and get_viewport_screenshot (single image).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use when you need a composite of multiple angles in one image. It doesn't explicitly state when not to use it or mention alternatives, but the context from sibling tools helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description details parameters and their effects (e.g., background removal, resolution trade-off) but does not disclose potential side effects (e.g., file overwriting), permissions, or error conditions. It adds value beyond the schema but lacks full behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is efficient: a short purpose statement, a prerequisite sentence, and a bulleted parameter list. No redundant information; all sentences add value. Well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and moderate complexity (5 params, 1 required), the description covers purpose, prerequisites, and all parameters. It does not explicitly describe the return behavior (e.g., path to generated file), but generating a .glb file is implied. Slightly more detail on output would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter (image_path, output_path, foreground_ratio, mc_resolution, no_remove_bg) with meanings, defaults, and optionality. This is highly informative for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool generates a 3D mesh (.glb) from a single image using the local TripoSR model. This specific verb+resource combination distinguishes it from sibling tools for other 3D generation methods (e.g., generate_hunyuan3d_model, generate_hyper3d_model_via_images).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states a prerequisite: 'You must call load_img_to_3d_model() first.' This provides clear when-to-use guidance. However, it does not mention alternatives or when not to use this tool, though the prerequisite effectively implies the required context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it is a read operation returning different control point data per curve type and details parameters. However, it does not mention error conditions (e.g., if the object is not a curve) or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a clear structure: main purpose in the first sentence, then return types, then parameter list. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameters, and return types per curve type. Without an output schema, it provides valuable context. It could be more complete by mentioning that the object must exist and be a curve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: name as 'Curve object name' and spline_index as 'Which spline within the curve (default 0)', adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads control points of curve objects (BEZIER, POLY, NURBS) and specifies the returned data per type, differentiating it from sibling tools like get_vertex_positions or set_control_point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of exclusions or contexts where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description identifies the tool as read-only ('Read edge data') and mentions the safety cap (max_edges) with default. Without annotations, it adequately discloses the read nature and safety limit, though no further behavioral details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence defining purpose, one listing returned data, then a clear parameter list. Every word adds value, and key info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, and returned data fields. Without an output schema, it could provide more detail on the structure of 'vertex pair' (e.g., indices or coordinates), but it is sufficiently complete for a read operation on edges.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds extensive meaning to all parameters: name (mesh object), indices (comma-separated, returns all if omitted), max_edges (safety cap, default 5000). This fully 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads edge data from a mesh and lists the specific fields (vertex pair, sharp flag, etc.), distinguishing it from sibling tools like get_faces or get_vertex_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose is clear, but no explicit guidance on when to use it versus alternatives (e.g., get_mesh_stats) or when not to use it. The description lacks contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently discloses the destructive action (replacing the scene) and the loss of unsaved changes. However, it does not mention file existence requirements or loading dependencies, but for a simple load operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a parameter list. It front-loads the purpose and warning, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers essential behavior (opening a file, replacing scene, warning about unsaved changes). It could mention that Blender must be running, but that is likely implicit. Overall, it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage (no descriptions), so the description must compensate. It provides 'filepath: Absolute path to the .blend file to open', adding meaning (absolute path, file type) beyond the schema's title and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Open a .blend file, replacing the current Blender scene.' It specifies the verb 'open' and the resource '.blend file', and distinguishes from siblings like import_file by noting the replacement behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a warning about unsaved changes being lost and advises to save first, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools like import_file for adding assets without replacement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes visual effect (hard crease vs smooth blend) but does not disclose whether operation is additive or overwrites existing sharpness, or any side effects on modifiers. With no annotations, description carries full burden, adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise one-paragraph structure with clear separation of purpose and parameter descriptions. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameter details, and visual output. Missing notes on prerequisites (auto-smooth enabled, Edge Split modifier) and reversibility. Given complexity, adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant value beyond schema: explains edge_indices format ('comma-separated or all') and sharp parameter meaning (true=hard, false=soft). Schema coverage was 0%, so description compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: marking edges as sharp or soft, and explicitly links it to auto-smooth and Edge Split modifier. It distinguishes from siblings like set_edge_crease by focusing on smooth shading behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: sharp edges create creases under smooth shading, soft edges blend. Implicitly tells when to use, but does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the polling behavior, return formats (list vs single status), and failure indicators ('Failed', 'IN_PROGRESS', etc.). No annotations were provided, so the description carries full burden and does well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with mode-specific sections. It is somewhat lengthy but each part adds value. The first sentence front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 statuses and completion criteria for both modes. It covers the polling nature adequately, though timeout or retry guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds critical context linking subscription_key to MAIN_SITE and request_id to FAL_AI, specifying where each parameter is used. However, it doesn't provide format constraints or defaults beyond what the schema shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check if the Hyper3D Rodin generation task is completed.' It differentiates between two modes (MAIN_SITE and FAL_AI) and thus distinguishes from sibling tools like poll_hunyuan_job_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (after generation step) and provides polling guidance: 'only proceed if the status are finally determined'. It does not explicitly exclude alternatives but the context from sibling names is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that it renders all cameras simultaneously, returns a composite contact sheet, saves individual renders to a directory, and describes parameter effects (e.g., samples ignored for EEVEE). It could mention potential performance impact or if scene state is altered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, with the main purpose front-loaded in the first sentence. Each subsequent sentence adds value (parameter details, return info). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 what is returned (contact sheet) and that individual renders are saved. It could clarify the format of the contact sheet (e.g., image file) but is otherwise sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds all parameter meaning: width/height (defaults, per camera), samples (ignored for EEVEE), output_dir (temp dir if omitted). This adds significant value beyond the schema which only has names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a still from every camera simultaneously and returns a contact sheet with labels. This distinguishes it from siblings like 'render_from_camera' (single camera) and 'capture_contact_sheet' (likely viewport-based).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through parameter descriptions but does not explicitly state when to use this tool over alternatives like 'render_from_camera' for single renders or 'capture_contact_sheet' for viewport captures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds behavioral context: camera_name defaults to active camera, and samples are ignored for EEVEE. However, it does not disclose potential side effects or return details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a front-loaded main sentence and a clear parameter list. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameters well but lacks information about what the tool returns (e.g., image path or data). For its complexity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully by explaining all 4 parameters, including default values, the meaning of null for camera_name, and engine-specific behavior for samples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Render' and resource 'a still from the specified (or active) camera'. It distinguishes from siblings like 'render_all_cameras' and 'capture_viewport_angle' by focusing on a specific camera.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for rendering from a specific camera but lacks explicit guidance on when to use it versus alternatives or when not to use it. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the behavior when filepath is omitted (saves over current file or uses temporary path and returns it). This adds value beyond a basic description, though it does not cover error cases or return success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured: one purpose sentence followed by a parameter block. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, no output schema, and no annotations, the description covers the essential behaviors. It could be improved by mentioning overwrite behavior or error handling, but it is largely complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the filepath parameter's meaning, providing an example, and detailing the two possible behaviors (with path vs. omitted). This adds significant semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Save') and the resource ('the current Blender project as a .blend file'). It uses a specific verb and resource, and effectively distinguishes this tool from siblings like load_blend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to save a Blender file) but does not explicitly state when to use it versus alternatives. No exclusion or alternative tool is mentioned, although the sibling list contains load_blend which is complementary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It clearly explains the toggle action, the effect of 'smooth', and the 'auto_smooth' and 'angle' parameters. It does not mention side effects (e.g., recalculating normals) but the core behavior is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: one sentence for purpose then a clean parameter list. No redundant information or filler. It front-loads the action, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description adequately covers all parameters and the core operation. It could mention that the tool only works on mesh objects (already implied by 'mesh object') and what the result looks like, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 is the sole source of parameter meaning. It provides clear explanations: 'name: Mesh object name', 'smooth: True for smooth, False for flat', 'auto_smooth: Enable auto-smooth', and 'angle: threshold in degrees, default 30'. This adds essential value beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear, specific verb ('Toggle...smooth or flat shading') and identifies the target resource ('mesh object'). This differentiates it from sibling tools like 'flip_normals' or 'set_face_material_index', which address different aspects of mesh appearance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but does not explicitly guide when to use it versus alternatives. It lacks context such as 'Use when you need to control shading appearance for rendering' or exclusions like 'Does not affect flat-shaded materials'. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the effect ('freeing VRAM and memory'), which is beyond the absence of annotations. Simple and clear, though lacks details on idempotency or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Efficient and directly informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, no output schema), the description fully captures its purpose and effect. No additional context needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% by default. Baseline of 4 applies as description correctly reflects no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: 'Stop the local image-to-3D server'. Verb and resource are specific, and the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, such as the sibling 'load_img_to_3d_model'. Usage is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses the tool's behavior: it reports two boolean statuses. No side effects or hidden traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with no parameters, no output schema. Description adequately conveys purpose and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds no parameter info, but schema coverage is 100% and baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports whether Blender is running and whether the MCP addon is reachable. This is specific and distinguishes it from sibling tools that perform actions or modify objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: it's a status check. No explicit when-not or alternatives, but the context is clear for a simple status tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses that the tool returns a thumbnail as an Image, implying a read-only operation. It could mention non-destructive behavior, but overall it's transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a parameter note, front-loaded with the action, and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple preview tool, the description covers purpose, parameter source, and return type. It doesn't specify behavior on invalid UID or thumbnail size, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter uid is explained as the unique identifier from search_sketchfab_models, adding crucial context beyond the schema. With 0% schema description coverage, the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a preview thumbnail by UID and specifies its use for visual confirmation before downloading, which distinguishes it from sibling tools like 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool to visually confirm a model before downloading, providing clear context for when to use it, though it does not list exclusions or alternatives beyond the implied download tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 server runs until unloaded and frees VRAM upon unload. This is sufficient behavioral context for a simple server start, though it omits potential startup time or dependency checks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences plus a parameter line, with no fluff. The purpose is front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (starting a server), the description covers the lifecycle and memory impact. It lacks output schema details but that is acceptable. It is complete enough for the agent to understand the tool's role and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by detailing the single parameter model_dir: 'Path to TripoSR weights directory (uses IMG_TO_3D_MODEL_DIR env var if omitted)'. This adds meaningful guidance beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Start the local image-to-3D inference server (TripoSR).' This specifies the action (start) and the resource (inference server), distinguishing it from siblings like generate_3d_from_image which perform the actual generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'load only when you need it' and explains that the server persists until explicitly unloaded. This provides clear usage context, though it does not explicitly contrast with other tools like generate_3d_from_image or unload_img_to_3d_model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the polling nature, possible statuses ('DONE', 'RUN', failed), and that a 'DONE' response includes ResultFile3Ds with a ZIP path. It does not mention error handling or timeouts, but overall gives a clear behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then details parameters, return values, and a usage note. It is slightly redundant (ResultFile3Ds mentioned twice) but overall efficient. Could be shortened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple polling status tool with one parameter and no output schema, the description covers the key aspects: what it does, how to use it, status values, and expected output. It lacks differentiation from get_hunyuan3d_status and does not mention error states, but is sufficiently complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage with no description for job_id, but the description fully explains it as 'The job_id given in the generate model step.' This adds essential meaning beyond the schema's type only, fully compensating for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if the Hunyuan3D generation task is completed, specifying verb 'Check' and resource 'Hunyuan3D generation task'. It distinguishes from siblings by noting it's a polling API, which differentiates it from non-polling status tools like get_hunyuan3d_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains it is a polling API and advises to only proceed when status is final ('DONE' or failed). It indicates the job_id comes from the generate step. However, it does not explicitly tell when not to use it (e.g., vs. get_hunyuan3d_status) which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 'force' parameter's behavior (kill immediately vs. graceful quit) and the default false, which is good disclosure, though it could mention error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences plus parameter details, and it is efficiently structured with clear purpose and parameter explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 and no output schema, the description provides sufficient context to use the tool correctly, covering purpose and parameter behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining the 'force' parameter, adding meaning beyond the schema by detailing the two modes of operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Close the Blender instance that was started with start_blender()', using a specific verb and resource, and distinguishes itself from sibling tools by explicitly linking to start_blender.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It indicates when to use the tool (after start_blender) but does not provide explicit when-not or alternative tools. The context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effect (edges with weight>0 are bevelled) and the typical workflow, but does not mention any destructive consequences or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear heading, explanatory paragraph, typical workflow example, and parameter list in a compact format. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and no output schema, the description is complete. It covers the purpose, usage, parameters, and typical workflow adequately for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully compensates by explaining 'edge_indices' as 'Comma-separated edge indices, or all' and 'weight' as a range 0.0-1.0. It adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets bevel weight on edges for use with the Bevel modifier in WEIGHT mode. It distinguishes itself from sibling tools like 'set_edge_crease' by specifying the context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
A typical workflow is provided, showing how to use this tool before adding the modifier. It explains the condition (only edges with weight > 0 are bevelled) but does not explicitly state 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![blender_mcp MCP server](https://glama.ai/mcp/servers/naab007/blender_mcp/badges/card.svg)](https://glama.ai/mcp/servers/naab007/blender_mcp)

Score Badge

Copy to your README.md:

[![blender_mcp MCP server](https://glama.ai/mcp/servers/naab007/blender_mcp/badges/score.svg)](https://glama.ai/mcp/servers/naab007/blender_mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/naab007/blender_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server