Blender Copilot MCP Server

by dwgx

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.0.0
Disambiguation3/5
With 307 tools, there is noticeable redundancy (e.g., add_light and light_add, modifier_add and add_modifier). Many sculpt and rigging tools are distinct but similar, potentially confusing an agent. However, most tools have clear, descriptive names that help differentiate them.
Naming Consistency2/5
Naming is inconsistent: some tools use verb_noun (add_light, create_curve) while others use noun_verb (light_add, light_list), and there are duplicate patterns like add_modifier vs modifier_add. No uniform convention is followed.
Tool Count1/5
307 tools is excessive for any MCP server, even one covering Blender's broad feature set. The sheer number overwhelms the agent and increases the risk of misselection, making it poorly scoped.
Completeness5/5
The tool set is remarkably comprehensive, covering everything from basic primitives to advanced sculpting, rigging, physics, rendering, export, and even full VRChat avatar pipelines. There are virtually no missing operations for the intended domain.
Average 3.5/5 across 278 of 307 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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.
This server has been verified by its author.
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?
No annotations provided, so description carries full burden. It mentions detecting and filling holes but doesn't disclose if the operation is destructive, reversible, or requires a specific mesh state. Lacks details on side effects or limitations.
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?
Single sentence, no fluff, but it omits critical information. It is concise but at the cost of completeness. Fails to front-load essential context.
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?
With one parameter, no output schema, and no annotations, the description should provide more context about expected result, return value, or post-condition. It does not mention whether holes are filled on the original mesh or a copy, or if it works on selected vertices.
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%, and description does not explain the single required parameter 'name'. It's unclear whether this refers to the object name, mesh name, or something else. Description adds no value beyond the 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?
Description clearly states it detects and fills holes in a mesh, with a specific method (selecting non-manifold edges). The verb-resource pair is clear, but among sibling tools like 'merge_by_distance' or 'boolean_cleanup', it doesn't explicitly differentiate itself, though the operation is distinct enough.
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 'retopology' or 'boolean_cleanup'. No mention of prerequisites, edge cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the effect is permanent and modifies geometry, implying irreversibility. However, with no annotations, it misses details like undo behavior or required permissions. Basic transparency, not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 11 words, very concise. It front-loads the core action. However, it sacrifices necessary details for brevity in the context of missing annotations.
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 lack of annotations, output schema, and parameter descriptions, the description is too minimal to fully inform the agent. It covers the action but omits parameter semantics and usage context, leaving significant gaps.
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?
No parameter descriptions are provided in the schema (0% coverage) and the description does not explain what 'name' or 'modifier_name' refer to. The agent must infer meanings from context, which is insufficient.
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 a modifier) and the effect (permanently bake into mesh geometry). It distinguishes from adding a modifier, but does not differentiate from the sibling tool 'modifier_apply', which likely has similar purpose.
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 'modifier_apply' or 'modifier_apply_all'. The description does not mention prerequisites or context 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?
The description lacks details about behavioral traits such as whether the tool creates a new material, modifies an existing one, assigns it to a selected object, or has side effects. There are no annotations to compensate, leaving the agent uninformed about the tool'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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and no extraneous words. However, it could be slightly restructured to include parameter explanations without sacrificing brevity.
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 annotations, no output schema, and 4 parameters, the description is too sparse. It does not explain the result (e.g., material node group created), how to assign it, or any necessary conditions (e.g., object selection).
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?
With 0% schema description coverage, the description only adds value for the 'ior' parameter by listing example values. It fails to explain 'name' (material name), 'color' (tint), or 'roughness' (frosted effect), leaving the agent to guess their purpose.
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 'Apply a glass/transparent material to an object' clearly states the verb (apply) and the resource (glass/transparent material). It distinguishes from siblings like create_metal and material_create_pbr by specifying a specific material type, though it could be more explicit about the exact operation (e.g., creating a material node group).
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 IOR values as reference but does not explicitly tell when to use this tool over alternatives like create_metal, material_create_pbr, or assign_material. No context about prerequisites or typical use cases is given.
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 whether it is read-only, what constitutes 'enabled', or what the return value looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The second sentence is unnecessary and introduces confusion, making the description less concise and potentially harmful to correct tool selection.
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 status check with no parameters and no output schema, the description is minimally adequate but lacks clarity on the exact meaning of 'integration enabled'.
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 cannot add meaning beyond the empty schema; baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states it checks if the integration is enabled, but the second sentence about generating models is misleading and likely belongs to a different tool, causing 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 siblings like generate_hunyuan3d_model or poll_hunyuan_job_status; usage context is only implied.
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 discloses that the modifier is removed without being applied, which is a key behavioral trait. However, it does not explain side effects, reversibility, or whether it works for all modifier types. Since no annotations are present, the description carries the full burden but is minimally adequate.
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 short sentence, which is concise but too brief. It omits essential parameter guidance, so while it is front-loaded, it does not earn its place by being complete enough for effective tool invocation.
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 absence of annotations, output schema, and parameter descriptions, the description is incomplete. It fails to explain the return value, prerequisites, or parameter details, making it insufficient for an agent to use the tool correctly without prior domain knowledge.
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?
With 0% schema description coverage, the description must add meaning to the two parameters ('name' and 'modifier_name'), but it does not. The description only states the tool's purpose, leaving the agent to guess what each parameter represents (e.g., 'name' likely refers to the object name, 'modifier_name' to the modifier's name). This is a significant gap.
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 'Remove a modifier from an object without applying it' clearly states the action (remove) and the resource (modifier from an object), and it distinguishes from applying the modifier. However, it does not explicitly differentiate from sibling tools like 'modifier_remove' which may have a similar purpose.
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 'apply_modifier' or 'modifier_remove'. It does not state prerequisites or exclusions, 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?
No annotations provided, so description carries full burden. It discloses that it 'sets' the unit system (mutation) but does not explain side effects, reversibility, or any permissions needed. The behavioral insight 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 short and to the point, with the purpose front-loaded. No unnecessary words. It efficiently conveys the core function and parameter options.
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 sparse schema info, the description should provide more context about return value, error conditions, or prerequisites. It only covers the action and parameters, leaving gaps for an agent to use effectively.
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%, so description must add meaning. It lists parameter values but lacks explanations of what each does (e.g., what 'NONE' system means, how scale_length affects units). Basic info but insufficient.
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 first sentence 'Set scene unit system.' clearly states the verb and resource. The args list specifies system, length, and scale_length, making the scope clear. It is distinct from sibling tools as no other tool mentions units.
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. There is no mention of prerequisites, suitable contexts, or when not to use it. The description simply states what it does without 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?
With no annotations, the description must disclose behavior but only lists actions and parameter ranges. It does not explain side effects (e.g., whether 'create' is idempotent), error conditions, or impacts on existing layers. The 'flatten' action is briefly explained but others lack detail.
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 purpose. The action list is presented in a structured format. However, parameter descriptions could be integrated more tightly, and the overall organization could be clearer.
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 an output schema (presumably), the description does not mention what the tool returns. For a multi-action tool, understanding return values (e.g., list of layers, success flags) is important. Missing behavioral details and incomplete parameter coverage leave significant gaps 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%, so the description should explain all parameters. It describes layer_name and blend_value briefly but omits mesh_name entirely. The action parameter's values are listed but not explained beyond the action names. This leaves a critical required parameter undocumented.
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 purpose as layer-based sculpting using shape keys, and lists actions that cover common operations. It distinguishes itself from other sculpt tools like sculpt_brush_stroke by focusing on layer management. However, it assumes familiarity with the concept of sculpt layers, which could be clarified.
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 vs alternative tools (e.g., sculpt_to_shape_key, sculpt_multires_workflow). There is no mention of prerequisites, order of operations, or context where specific actions are 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?
Although no annotations are provided, the description lacks detail about the operation's irreversibility, effects on other object data, or required permissions. For a destructive operation, more transparency 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 a single concise sentence, appropriately brief. It is well-structured and front-loaded with the verb. However, it could be slightly expanded with usage context without losing conciseness.
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 fails to cover basic behavioral information such as whether the operation can be undone or if it affects animations on child objects. Minimal completeness for a simple tool.
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?
The description does not explain the 'object_name' parameter beyond its name. With 0% schema description coverage, the description adds no semantic meaning, making it hard for the agent to know what value to provide.
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 'Remove' with the resource 'all animation data' from an object, clearly distinguishing it from sibling tools like 'anim_delete_keyframe' which targets specific frames.
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 such as 'anim_delete_keyframe' or 'clear_animation'. No prerequisites 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?
No annotations are provided, so the description must carry the full burden. It mentions 'bake to cache' but does not explain behavioral implications like whether it is destructive, requires pre-setup, or modifies existing simulations.
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 concise at two sentences, with no wasted words. While it could include more detail, it is efficiently front-loaded with essential purpose and usage context.
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, minimal description, and no parameter explanation, the tool definition is incomplete for an agent to use effectively. Important aspects like parameter ranges and behavior are missing.
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?
The description provides no information about the two parameters (start and end) from the input schema. With 0% schema description coverage, the agent gains no additional meaning beyond the schema 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 the tool bakes all physics simulations to cache, with a specific verb 'bake' and resource 'physics simulations'. However, it does not differentiate from sibling tools like 'physics_bake' which may have overlapping functionality.
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 usage hint ('Must be baked before rendering physics simulations'), indicating when to use the tool. Yet it lacks explicit guidance on when not to use or clear alternatives.
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?
The description is misleading by claiming it generates 3D models, which is not its behavior. With no annotations, the description should accurately reflect the tool's action, but it does not. A simple status check is implied, but the generative claim is false.
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 only two sentences, but the second sentence is irrelevant and wasteful. It adds no value and detracts from conciseness. A single sentence would be more 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?
For a simple status check with no parameters and no output schema, the description is mostly adequate except for the misleading second sentence. It would be complete if only the first sentence were 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?
No parameters exist, so schema coverage is 100% by default. The description does not need to add parameter info, and it doesn't. The baseline for zero parameters is 4, and the description does not harm this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states it checks if Hyper3D Rodin integration is enabled, but the second sentence about generating 3D models is confusing and not the tool's purpose. This mix of functionality hurts clarity and does not distinguish it from sibling generation 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 versus siblings like poll_rodin_job_status or generate_hyper3d_model_via_text/images. Description fails to specify that it is for integration availability check, not for generation or job polling.
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?
Provides basic parameter behavior ('Thickness controls inset distance, depth controls push in/out') but omits critical context: whether it works in object/edit mode, if it requires face selection, if it is destructive, or if it applies to all selected objects. No annotations exist to compensate.
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?
Very short and front-loaded, but misses essential information. Every sentence provides some value, but the brevity sacrifices completeness.
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?
Highly incomplete given the tool's complexity. Lacks details on required mode (edit mode), selection behavior, effect on surrounding geometry, and any restrictions. No output schema or annotations to fill gaps.
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?
Adds meaningful descriptions for two of three parameters ('depth' and 'thickness') beyond the schema titles, but does not explain 'name'. With 0% schema description coverage, the description partially compensates but leaves a gap.
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?
Clearly states the action 'Inset all faces of a mesh', which is a specific verb and resource. However, it does not distinguish from siblings like 'extrude_faces' or 'bevel_edges', but 'inset_faces' has no direct sibling, so differentiation is less critical.
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 such as 'extrude_faces' or 'bevel_edges'. Does not mention required context like edit mode or face selection.
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 the burden of disclosing behavior. It importantly notes that the object is removed from current collection(s), which is a key side effect. However, it lacks details on permissions, idempotency, or error handling.
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 short and front-loaded, but its brevity sacrifices valuable information. Every sentence is functional, but the tool would benefit from additional context.
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 tool with 2 parameters and no output schema, the description is insufficient. It does not specify behavior when object or collection is missing, or whether the tool supports moving multiple objects at once.
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 compensate. It only repeats the parameter names ('object', 'collection') without adding semantic meaning beyond the schema property names. The properties are not elaborated.
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 moves an object to a different collection and removes from current collection(s). However, it does not differentiate from the sibling tool 'scene_move_to_collection', which might have a similar purpose.
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, such as 'scene_move_to_collection' or any other collection-related tools. No prerequisites 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides minimal behavioral info beyond the action itself; no disclosure of side effects, required permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but structured with an 'Args' list; however, it could be more concise by removing redundant 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?
Given no output schema and no annotations, and the presence of a similar sibling tool, the description should provide more context about scope, behavior, and differences to be complete.
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 briefly explains both parameters (object_names and collection_name) which the schema lacks, but the explanations are terse and could be more informative.
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 (move objects) and target (collection), but does not differentiate from the sibling tool 'move_to_collection', losing specificity.
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 'move_to_collection' or 'create_collection', and no exclusions or prerequisites 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. Description does not disclose side effects, overwriting behavior, or required permissions for actions like 'init_by_normals'. Lacks safety information.
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 well-structured with a summary and bulleted list of actions. No redundant text, but could be slightly more concise.
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 main actions but lacks detail on default behaviors and parameter constraints. Output schema exists, so return value documentation is not needed, but parameter semantics are incomplete.
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%. Description partially explains parameters only for 'assign_by_position' action. Other parameters like 'face_set_id' and 'params' are left unspecified except for one example.
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?
Description clearly states 'Manage face sets for organized sculpting' and lists specific actions. It distinguishes from sibling sculpt tools by focusing on face set management.
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 sculpt_extract_face_set or sculpt_brush. Lacks context for choosing actions.
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 behaviors. It only lists parameters and does not mention what the tool returns (e.g., list of model metadata), rate limits, or that it requires network access. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with three sentences, front-loading the main purpose. However, it lacks structure (e.g., bullet points) and omits the fourth parameter. Conciseness comes at the cost of completeness.
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?
With no output schema, the description should explain return values. It doesn't. It also ignores the 'categories' parameter. Given the tool's role in a larger workflow (search then download), the description should connect to subsequent steps. It is incomplete for the context.
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%, so description should compensate. It mentions three parameters (query, count, downloadable) but omits 'categories' and does not explain their meaning or constraints. The schema already provides defaults and types; the description adds little value.
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 Sketchfab for 3D models,' identifying the action and resource. It distinguishes from siblings like 'download_sketchfab_model' and 'get_sketchfab_model_preview' by focusing on discovery. However, it does not explicitly differentiate from other search tools like 'search_polyhaven_assets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a basic when-to-use: search for 3D models. But it lacks guidance on when not to use (e.g., for direct download) and does not mention alternatives or prerequisites. The usage context is implied but not explicit.
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 of behavioral disclosure. It reveals the Nishita sky type and parameter meanings, but omits sun_intensity entirely and does not mention side effects (e.g., overwrites existing world texture), required user permissions, or irreversible changes.
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 brief but incomplete due to the missing sun_intensity parameter. It front-loads the purpose well but fails to cover all parameters, which is a significant omission.
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 lack of annotations, output schema, and four parameters, the description is insufficiently complete. It omits one parameter, does not describe the return behavior or effects on the scene, and provides no context for integration with other 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?
Schema description coverage is 0%, so the description must compensate. It provides units and ranges for sun_elevation, sun_rotation, and turbidity, adding meaning beyond the bare schema. However, it completely omits the sun_intensity parameter, leaving it undocumented.
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 a procedural Nishita sky texture for outdoor lighting, specifying the parameter meanings for three of the four parameters. However, it does not explicitly distinguish this tool from other sky/texture or lighting tools among the siblings (e.g., set_world_hdri, add_light), which would push it to a 5.
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 alternative lighting or sky-setting tools. It does not mention prerequisites, context, or scenarios where other tools would be more 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 must fully convey behavioral traits. It only states the action (adding cloth simulation) but does not disclose side effects, such as whether the mesh is modified in-place, whether previous cloth simulations are removed, or any permissions or destructive nature. This leaves significant uncertainty.
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 very concise with two short sentences. No fluff, but could be slightly more structured by separating the parameter explanations. It earns its space.
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 low schema coverage, the description should provide more context about the tool's behavior, prerequisites, and possible errors. It lacks information about what happens after adding cloth, any return value, or how to undo the operation. Incomplete for a simulation tool.
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 description must add meaning. It explains that 'quality' controls simulation accuracy (1-10) and 'mass' is in kg, which adds useful context beyond the schema. However, the 'name' parameter is not explained, and the coverage is incomplete.
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?
Description clearly states 'Add cloth simulation to a mesh object', which is specific. However, it fails to differentiate from the sibling tool 'physics_add_cloth', which appears to perform a similar function. Without distinction, an AI may be uncertain which tool to use.
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. Description does not mention prerequisites, such as whether the mesh object must be selected or if a specific mode is required. There is a sibling 'physics_add_cloth' that likely overlaps, creating ambiguity.
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 the full burden. It only mentions common types and that properties set attributes, but fails to disclose side effects, prerequisites, error handling, or limitations (e.g., what happens if target_name is invalid).
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 (3 sentences) and front-loaded with the purpose. However, the list of types could be better structured or referenced to an external resource. Information density is acceptable.
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 lacks completeness. It does not describe return values, error conditions, or behavior when constraints exceed limits. It is insufficient for an agent to fully understand the tool's capabilities.
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 compensate. It adds meaning for 'constraint_type' by listing common types, but does not explain 'name' (object name?), 'target_name', or 'properties' in detail. The mention of 'Properties dict' is vague.
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 constraint to an object' which is a specific verb+resource. It also lists common constraint types, making the purpose distinct from sibling tools like 'armature_add_constraint' which is armature-specific.
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 explicit guidance on when to use this tool versus alternatives such as 'armature_add_constraint' or 'remove_constraint'. It lacks when-not usage and alternative recommendations.
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 fails to disclose important behavioral traits such as error handling, reversibility, or prerequisites. It only states the action and gives a properties example, leaving many aspects ambiguous.
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 two sentences, front-loading the purpose and then providing a list of types and a properties example. It avoids unnecessary verbosity.
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 complexity of 4 parameters, no output schema, and no annotations, the description is insufficient. It omits details on return values, parameter relationships, and edge cases, leaving the agent underinformed.
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 semantic value for the 'properties' parameter with an example and for 'modifier_type' by listing common values. However, it does not explain the 'name' and 'modifier_name' parameters, and the schema has 0% coverage.
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 'Add a modifier to an object' and lists common modifier types, making the tool's purpose specific. However, it does not differentiate from the sibling tool 'modifier_add', which appears to have similar functionality.
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 'modifier_add' or 'modifier_batch_add'. The description only implies usage by listing common modifier types but lacks explicit context 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 exist, so description must fully cover behavior. It only states the action without mentioning side effects, safety, or constraints (e.g., what happens if start > end, whether existing keyframes are cleared, or if FPS change affects playback). Minimal transparency.
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: one-line summary plus arg list. No wasted words. However, a bit more structure (e.g., clarifying defaults and behavior) could be added without much bloat.
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 3 simple parameters and no output schema, the description lacks important context like return value, error handling, and relation to animation pipeline. Incomplete for a tool that modifies scene state.
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 no descriptions (0% coverage). The description adds brief meaning: start and end are frame numbers, fps with 0 meaning 'don't change'. This is helpful but still leaves ambiguity (e.g., valid ranges, order validation). Adequate but not comprehensive.
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 verb 'set' and resource 'scene frame range and optionally FPS' clearly describes the tool's function. It is distinct from siblings like set_frame (current frame) and set_animation_range (possibly similar but not differentiated). The name indicates it belongs to animation tools, so purpose is clear.
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 why one would use this instead of set_animation_range or other animation tools. Lacks when-to-use and when-not-to-use 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?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states a delete operation, which implies destructiveness, but fails to mention any side effects, error handling, or permissions needed. The description adds little beyond the obvious.
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 concise sentence with no redundant words. It efficiently conveys the core function.
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 parameter set, the description is minimally adequate but incomplete. It does not mention return values (no output schema), error handling, or whether the operation is reversible. The agent may need to infer behavior from the name.
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 sole parameter 'names' is an array of strings. Schema description coverage is 0%, so the description must compensate. However, it merely says 'by their names', which is already evident from the parameter name. It does not clarify expected format, object types, or behavior for invalid names.
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 'Delete multiple objects at once by their names' clearly states the action (delete), resource (objects), and scope (multiple at once, by names). It distinguishes from the sibling 'delete_object' which likely handles single deletion, though it does not explicitly contrast with it.
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 such as 'delete_object' or other removal tools. There is no mention of prerequisites, context, or when not to use batch deletion.
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 full burden. It describes a read-only operation but does not disclose behavioral traits such as whether Blender must be running, latency of connection check, or side effects (none expected). The description is insufficiently transparent for a tool with 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?
The description is a single sentence, front-loaded with the main action. It is concise with no extraneous text. However, it lacks any structural elements like bullet points or additional sentences that might improve clarity for the parameter.
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 simplicity of the tool and the presence of an output schema, the description is adequate in scope but lacking in detail. It mentions three pieces of info (connection status, path, scene summary) but does not differentiate from similar tools like get_scene_info or scene_stats. The output schema likely covers return values, so completeness is moderate.
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%, and the description does not mention the port parameter at all. The agent is not told what the port is for (e.g., Blender server port). The description adds zero meaning beyond the schema for this parameter, which is unacceptable given the low 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 verb 'Check' and the resources 'Blender connection status, executable path, and scene summary'. It is specific and distinguishes from sibling tools like get_scene_info by focusing on connection and executable path.
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 state prerequisites (e.g., Blender must be launched) nor exclusions. The implied usage is checking before other operations, but this is not explicit.
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 the full burden. It states a destructive mutation (removal) but does not disclose reversibility, impact on drivers or constraints, or behavior when object has no animation data.
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 redundancy. Efficiently conveys the core action.
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 one-parameter tool with no output schema, the description is minimally adequate but lacks distinction from numerous sibling animation tools and does not describe return behavior.
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 description does not explain the 'name' parameter beyond what the schema provides (string). It fails to add meaning such as that it must be an object name or that the animation data is removed from that specific object.
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?
Description clearly states the action (Remove) and target (animation data from an object). However, it does not distinguish from sibling tool 'anim_clear_all' which likely clears all animations in the scene, leading to potential confusion.
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 'anim_clear_all' or 'anim_delete_keyframe'. No prerequisites or context 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?
Partially describes scaling behavior ('Scales to target_size') with examples, but omits critical traits like whether the model is imported into the current scene, what happens on duplicate UIDs, error handling, or blocking behavior. With no annotations, the description carries full burden and falls short.
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: one sentence plus inline examples. No wasted words, and the examples are directly relevant. Front-loads the key purpose and scaling behavior.
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 low complexity (2 params, no output schema), the description omits what the tool returns (e.g., import status, object name) and side effects (e.g., scene modification). The scaling examples are helpful but overall incomplete for a download/import operation.
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?
Adds context that 'uid' is a Sketchfab identifier and 'target_size' is the largest dimension in meters, with realistic examples. This goes beyond the schema (which has only param names/types), but does not specify uid format or allowed ranges.
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?
Clearly states 'Download and import a Sketchfab model' with scaling to target_size. Distinguishes from sibling download tools like download_polyhaven_asset or import_generated_asset by specifying the source (Sketchfab) and scaling behavior.
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 searching/downloading from other sources (e.g., search_sketchfab_models first) or handling prerequisites like model UID. Lacks exclusions or context for alternatives.
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 full burden. It only mentions directory creation, but doesn't disclose key behaviors like file overwrite rules, error handling, or return values. For a file export tool, more transparency 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 and front-loaded, with no unnecessary words. However, it sacrifices informativeness for brevity, leaving gaps.
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 tool has 3 parameters and no output schema or annotations, the description is incomplete. It doesn't cover return values, error cases, or detailed parameter explanations.
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%, so description should explain parameters. It lists formats in the description but doesn't describe the filepath format, selected_only behavior, or valid format values. Minimal value added 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?
The description clearly states the tool exports the scene or selected objects to a file, and lists multiple formats. It distinguishes from sibling format-specific export tools by being a unified exporter.
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 the many sibling format-specific exporters (e.g., io_export_fbx, io_export_gltf). No when/not conditions or alternatives 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 exist, so the description bears full burden. It omits behavioral details like whether it modifies the object's modifier stack, if it's safe (non-destructive), or what happens to existing node trees. Only states basic creation with a new node tree.
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 very short and includes an args section, but no superfluous content. Could be more informative without sacrificing conciseness.
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 2 parameters, no output schema, and no annotations, the description is incomplete. It doesn't mention return value, side effects, or how it fits with sibling geometry nodes tools.
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%, so description must add substantial meaning. It merely restates parameter names with short phrases ('Target object', 'Name for the node tree') without explaining constraints (e.g., object must exist, tree_name default behavior). Insufficient to compensate 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 the action (create), the resource (Geometry Nodes modifier), and the target (an object). It distinguishes from sibling tools like geonodes_add_node (adds node to existing tree) and add_modifier (generic modifier).
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 geonodes_add_node or add_modifier. No prerequisites or context provided about existing modifiers or object state.
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 convey behavioral traits. It states the operation but does not disclose that applying modifiers is destructive (permanent bake), requires certain permissions, or has performance implications. The agent is left unaware of 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 a single sentence that front-loads the verb and resource. It is concise with no wasted words. However, it could be slightly expanded to include important caveats without becoming 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 the operation (applying all modifiers) and lack of output schema, the description is too sparse. It omits important context: modifiers are applied in stack order (mentioned, good), but not that this is destructive, that it may fail if modifiers are invalid, or what the return value indicates. The tool does not describe its output, leaving the agent guessing.
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 compensate by explaining parameters. It does not describe the 'object_name' parameter at all; the name is somewhat self-explanatory, but the tool description offers no additional meaning or constraints beyond the schema's 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 action ('apply all modifiers') and target ('object'), and specifies ordering ('in stack order'), distinguishing it from sibling tools like 'apply_modifier' (single) and 'modifier_apply' (likely similar). The verb-resource combination 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?
No guidance on when to use this tool versus alternatives such as 'apply_modifier' for individual modifiers or 'modifier_batch_add' for adding multiple. The description does not mention prerequisites (e.g., object must have modifiers) or context in which applying all is preferable.
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 the full burden. It clarifies that the modifier is removed without being applied (i.e., it is deleted from the stack, not applied to the geometry). This is a useful behavioral detail, but it does not disclose other important traits such as destructiveness (beyond obvious deletion), required permissions, or side effects like undo history.
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 that conveys the core purpose without any wasted words. It is highly concise and to the point, making it easy for an agent to parse quickly.
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 the tool having only two required parameters and low complexity, the description lacks completeness. It does not explain what happens to the object's modifier stack, whether the modifier is immediately deleted, or what the return value is (no output schema). Given the presence of many sibling tools for modifiers, the description should provide more context to avoid confusion, especially with the likely redundant 'remove_modifier'.
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?
The input schema has 0% description coverage for parameters, and the description adds no explanation beyond the parameter names. 'object_name' and 'modifier_name' are self-explanatory by name, but the description does not provide any additional context such as required format, allowed values, or relationship between parameters. The agent must rely solely on the parameter names.
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 (remove), the resource (modifier), and the context (from an object without applying it). However, it does not distinguish this tool from the sibling 'remove_modifier', which likely has a similar purpose. The verb 'Remove' and the phrase 'without applying' help differentiate from modifier_apply but not from other remove 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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., object must have the modifier), nor any exclusions or recommendations. The description does not help the agent choose between this and similar modifier tools like modifier_batch_remove or remove_modifier.
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, but it only states the action. It does not mention side effects (e.g., overwriting existing bakes), requirements (objects must have physics), or any destructive aspects.
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 action, followed by parameter explanations. It uses minimal words effectively, though the parameter descriptions could be slightly more detailed without harming conciseness.
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 tool has 3 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, prerequisites (e.g., objects must have physics simulation), or the exact scope of 'all objects in the scene'. More context is needed for a baking operation.
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 meaning beyond the schema by naming and briefly explaining each parameter. However, for bake_type, it only says 'ALL (all physics), or specific type' without listing the acceptable specific types, which is a significant gap.
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 'Bake' and resource 'physics simulation for all objects', making the purpose specific. However, it does not differentiate from the sibling tool 'bake_physics', which likely serves the same function.
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 per-object physics baking or other bake tools. The description lacks any context on prerequisites or conditions.
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?
The description implies a destructive operation (removal) but does not disclose side effects, such as whether the constraint is permanently deleted or if it affects other objects. No annotations are present to compensate for this lack of transparency.
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 a single, focused sentence with no redundant words. It is concise and directly states the core function, though it sacrifices completeness.
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?
With two required parameters, no output schema, and no annotations, the description is insufficient for an AI agent to use the tool correctly. It omits context about which objects support constraints, the scope of removal, and error handling.
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%, meaning the description adds no detail beyond parameter names. The parameters 'name' and 'constraint_name' are not explained (e.g., what object does 'name' refer to? what format for 'constraint_name'?). The description fails to provide necessary semantics.
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 'remove', the resource 'constraint', and the qualification 'by constraint name', making the purpose unambiguous and distinct from sibling tools like 'add_constraint' or 'modifier_remove'.
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 such as 'armature_add_constraint' or 'remove_modifier'. The description does not mention prerequisites, edge cases, or complementary tools.
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 implies a write operation by using 'set', which is appropriate. However, without annotations, it fails to disclose any side effects, such as whether setting the frame triggers renders or affects playback state, leaving the agent with basic but incomplete behavioral understanding.
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 a single, clear sentence with no unnecessary words. However, it could include a brief parameter hint 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?
For a simple one-parameter setter with no output schema, the description covers the basic purpose. However, it lacks parameter details and usage context, which are important given the large number of sibling tools.
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?
The single parameter 'frame' (integer) has no description in the schema (0% coverage) and the tool description adds no meaning—no range, unit, or constraints. This forces the agent to guess valid values.
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 'Set the current frame in the timeline' clearly states the verb ('set'), resource ('current frame'), and location ('timeline'), distinguishing it from siblings like 'anim_set_frame_range' and 'set_keyframe'.
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 such as 'anim_set_frame_range' or 'set_keyframe'. The description does not specify prerequisites (e.g., an existing timeline) or 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?
With no annotations provided, the description must disclose behavioral traits. It states the basic action but does not explain key behaviors: whether it overwrites existing keyframes, what happens with null value (delete keyframe?), interpolation implications, or validation of data_path. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences with a line break. It front-loads the main action and then provides parameter hints. No redundant information. Could be slightly restructured for clarity 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?
Given the tool has 4 parameters, no output schema, and no annotations, the description is insufficient for an agent to fully understand input constraints and results. Missing: what the tool returns (success indicator?), error conditions (invalid data_path, non-existent object), and behavior when `value` is omitted. The description covers only basic semantics without addressing completeness for reliable invocation.
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 description should compensate. It provides examples for `data_path` and explains that `value` can be list for vectors or float for scalars. However, it does not describe `name` (object reference) or `frame` (units, range), and does not mention that `value` defaults to null (perhaps indicating keyframe removal). Coverage is partial but adds some value over the 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 'Insert a keyframe on an object property at a specific frame', specifying the verb (insert) and resource (keyframe on object property). It differentiates from generic keyframe tools by noting object property context and providing example data paths. However, it doesn't explicitly distinguish from the sibling tool `anim_insert_keyframe`, which may overlap in scope.
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 like `anim_insert_keyframe` or `anim_insert_keyframes_batch`. The description lacks context about prerequisites (e.g., object must exist, must be in animation mode) or when not to use it. The examples are helpful but do not constitute usage 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 are provided, so the description must convey behavioral traits. It states value ranges for colors and scalars but omits critical details: whether the tool creates a new material, modifies an existing one, or if it requires the object to already have a Principled BSDF node. Side effects like overwriting existing node setups are not disclosed.
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, front-loaded with purpose, and provides essential formatting rules without extraneous information. Every word serves a purpose.
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 15 parameters and no output schema, the description is too brief. It lacks context on how the tool interacts with objects and materials, such as whether it creates a new material or modifies an existing one, and what happens if the material does not have a Principled BSDF node.
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 description partially compensates by specifying that colors are arrays [R,G,B] or [R,G,B,A] in 0-1 range and scalars are 0-1 except emission_strength and ior. However, it does not explain the object_name or material_name parameters, leaving some parameters semantically bare.
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 'Full control over Principled BSDF PBR shader', indicating the tool modifies a specific shader. It distinguishes from sibling tools like set_material or set_material_color by focusing on Principled BSDF parameters, but does not explicitly contrast with other material creation 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?
The description says 'Only set the parameters you need', implying partial updates, but does not specify when to use this tool versus alternatives like set_material_color or material_create_pbr. No exclusions or prerequisites are given.
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 should disclose behavioral traits. It mentions generating an asset file but does not warn about overwriting, validation, permissions, or error handling. The behavioral context 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 concise and structured with bullet points and an example. It is front-loaded and each sentence adds value, though it could be slightly more succinct.
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 core functionality but lacks details on prerequisites, error states, or return values (though an output schema exists). It is adequate but not complete for a tool with moderate 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 add meaning. It provides a JSON format example for menu_json and defaults for output_path, which adds value beyond the empty schema. However, project_path is only described as 'Unity project path' without further 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 it generates a VRCExpressionsMenu .asset file from a JSON blueprint, using specific verbs and resources. However, it does not differentiate from the sibling tool 'vrc_generate_expression_menu', which likely serves a similar purpose.
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 'vrc_generate_expression_menu'. The description lacks any usage context or conditions.
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 does not disclose side effects, permissions, return format, units, or behavior on invalid inputs. It only states 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?
Extremely concise: a single sentence followed by a bullet list of parameters, front-loading the key action.
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 measurement tool with 2 parameters and no output schema, the description is minimally adequate but lacks units, return value, and error handling context.
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 coverage is 0%, but the description only repeats the schema titles ('First object name', 'Second object name'), adding no meaningful semantics beyond what the schema already 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 the action 'Measure the distance between two objects (center to center)', using a specific verb and resource. It distinguishes from sibling tools like measure_alignment, measure_dimensions, etc.
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, no exclusions or prerequisites 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 are provided, so the description carries full burden. It does not disclose side effects, whether it creates a new object or modifies an existing one, or any authorization needs. The parameter list is basic and lacks 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with a long parameter list. The first sentence is clear, but the list could be more concise. Not all sentences add value.
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?
With 8 parameters, no output schema, and no annotations, the description is inadequate. It does not explain return values, errors, or how the particle system is added (e.g., creates new or modifies existing object).
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 description compensates by listing parameters with brief explanations. However, these explanations add minimal meaning beyond the schema field names (e.g., 'Emitter object', 'Number of particles').
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 states 'Add a particle system to an object' which is a specific verb+resource. It lists parameters but does not distinguish from siblings like physics_add_cloth or physics_add_rigid_body.
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 guidance or alternatives are provided. The purpose is implied by the function name, but no exclusions or context for choosing this over other physics 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?
With no annotations, the description carries full burden for behavioral disclosure. It does not mention potential side effects (e.g., file overwriting), dependency on current render settings, or any performance implications. Only basic parameter behavior is 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 short and front-loaded with the purpose. The parameter descriptions follow in a compact format with no redundant information. It is brief but contains essential details.
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 lacks completeness. It does not mention prerequisites (e.g., a scene must be open), any output or return value, or how the tool interacts with render settings. For a tool with no output schema and no annotations, more context is 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?
The description adds meaningful context to both parameters: filepath (optional, defaults to scene default) and open_after (opens in viewer if True). This goes beyond the schema, which only provides 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 the verb 'render' and resource 'single frame (still image)'. However, it does not differentiate from the sibling tool 'render_image', which may have a similar purpose, leading to potential 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 is provided on when to use this tool versus alternatives like render_animation or render_image. The description lacks context for appropriate usage scenarios.
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 conveys that rotation uses degrees by default and supports relative rotation, which are key behavioral traits. However, it does not specify the coordinate system, rotation order, or what happens when degrees=False. This leaves some ambiguity for an AI agent.
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, only two sentences with no extra information. It is well-structured and to the point.
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 six parameters and no annotations or output schema, the description is insufficient. It fails to explain the coordinate system, rotation order, or the role of each axis parameter. The tool's behavior is only partially described.
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 description only explains the 'degrees' and 'relative' parameters, leaving the x, y, z, and name parameters unaddressed. The schema provides their types and defaults, but the description does not add semantic meaning such as that x,y,z are Euler angles or that they represent rotation around respective axes.
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?
Clearly states 'Rotate an object', providing a specific verb and resource. The mention of degrees and relative mode adds clarity. However, it does not explicitly differentiate from sibling tools like translate_object or scale_object, but the name and context make the distinction clear enough.
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 translate_object or align_objects. The description does not provide any context about typical use cases or 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 bears full responsibility. It discloses that the tool removes orphaned data with zero users, implying it is a safe, destructive operation. However, it does not mention reversibility, required permissions, or side effects (e.g., if the scene unsaved changes). The disclosure 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first states the action, the second elaborates on scope and benefit. No extraneous details. However, it could benefit from bullet points or structured format for parameter mapping.
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 4 boolean parameters, no output schema, and no annotations, the description provides a reasonable overview but lacks details on return value, error conditions, or performance impact. It does not explain what happens if all parameters are false, or whether the operation can be undone. Completion is adequate but not thorough.
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%, yet the description only lists the categories (materials, meshes, images, textures) without explaining the boolean parameters (e.g., how toggling each works). It partially compensates by enumerating the data types, but it fails to add meaning to the schema, such as default behavior or interaction between parameters.
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 removes orphaned data blocks (materials, meshes, images, textures) to reduce file size. The verb 'clean up' and resource 'unused data blocks' are specific. It distinguishes from siblings like 'optimize_scene' or 'decimate' by focusing on unused data removal, but could be more explicit about when to use this over 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?
The description lacks any guidance on when to use this tool vs. alternatives. It does not mention prerequisites, typical workflow contexts (e.g., before export), or when not to use it. This omission forces the agent to infer usage from the general 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, so the description must cover behavioral traits. It explains the axis and align_to options but does not disclose side effects (e.g., whether it modifies object origins, transforms, or requires specific modes). It offers minimal insight beyond the basic operation.
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, using two sentences with no wasted words. It front-loads the core action and then lists the options clearly.
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?
Despite the tool's simplicity, the description lacks information about what exactly gets aligned (position, rotation, scale?) and the result. With no output schema and no annotations, the description is adequate but not fully complete for a confident agent invocation.
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 no parameter descriptions (0% coverage), so the description must add meaning. It explains the 'axis' and 'align_to' parameters with their options, but it does not explain the 'names' parameter (only that it is required). This partial coverage earns a mid score.
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 ('Align multiple objects along an axis') and lists the axis and alignment options. It is specific and distinguishes it from similar tools like center_objects or distribute_objects, though it doesn't explicitly contrast them.
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 vs alternatives, no prerequisites, and no context about when alignment is appropriate. It simply states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does not disclose behavioral traits such as permissions required, side effects (e.g., overwriting existing keyframes), or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the main action, and uses a clear docstring format. No redundant 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?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is insufficient. It lacks usage examples, error handling, return value information, and edge case behavior.
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?
All 5 parameters are briefly described in the docstring, adding meaning beyond the schema (e.g., 'Channel index (-1 = all channels, 0=X, 1=Y, 2=Z)'). However, the 'value' parameter is only described as 'Optional value to set before keying' without further detail.
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 'Insert a keyframe on an object property' and lists specific parameters. It distinguishes itself from siblings like anim_delete_keyframe and anim_insert_keyframes_batch by specifying the action on a single keyframe.
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., anim_insert_keyframes_batch) or any prerequisites. The description lacks context about appropriate 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 provided; description does not disclose behavioral traits beyond purpose. E.g., no mention of whether changes are permanent, if they affect all animation tracks, or if undo is supported.
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 (two sentences plus Args list) and front-loaded with purpose. No wasted text, but could be slightly more structured for readability.
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 animation context, description lacks completeness. No mention of return values, prerequisites, or examples. Agent may not know when animation data exists or how the tool handles errors.
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 0%; description lists parameters with examples (interpolation types, easing) but provides only minimal explanation. Adds some meaning beyond schema but insufficient to fully understand each parameter's effect.
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 'Set interpolation type for all keyframes on an object' with a specific verb and resource. Distinguishes from sibling animation tools like anim_insert_keyframe or anim_bounce.
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 vs alternatives. Does not mention prerequisites (e.g., object must have keyframes) or scenarios where another tool would be better.
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 combining materials and repacking UVs, but does not disclose whether the operation is destructive, if it modifies original materials, or what output is generated (e.g., saved file, added nodes).
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 main sentence and parameter explanations in a structured Args list. No redundant 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?
Despite having 3 parameters and no output schema, the description does not specify the output format, how the atlas is saved, or potential side effects. It also does not differentiate from similar sibling tools like vrc_bake_atlas in this context.
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 Args section adds meaning beyond the schema: mesh_names is described as a JSON array, atlas_size as resolution, output_path as custom path. With 0% schema description coverage, this provides necessary context, though descriptions are brief.
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 specific action: baking multiple meshes' diffuse colors to a single texture atlas, and mentions combining materials and repacking UVs. This distinguishes it from other baking tools like bake_ao or bake_normal_map.
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 bake_textures or vrc_bake_atlas. The description implies it's for combining diffuse colors of multiple meshes, but lacks when-not-to-use or alternative references.
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 does not mention whether the tool is destructive, requires specific permissions, or affects the scene beyond creating files. The behavioral implications are unclear.
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 reasonably concise with a summary and Args list, but the Args section largely duplicates the schema's parameter names and defaults, making it somewhat redundant. Could be more streamlined.
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 (7 parameters, no output schema), the description covers the main purpose and parameter details but misses high-level behavior like output format, potential side effects, or prerequisites. Moderately complete but with gaps.
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 for parameters like 'bake_types' (JSON array), 'output_dir' (Blender path format), and 'high_poly' (optional high-poly mesh). However, it does not explain defaults or valid ranges for enums.
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 'Bake texture maps from a mesh (or high-poly to low-poly)', specifying the action (bake) and resource (mesh), and differentiates from more specific sibling tools like 'bake_ao' or 'bake_normal_map'.
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 general baking tool versus specific alternatives (e.g., bake_ao, bake_normal_map). The description lacks exclusions or 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 provided, so description carries full burden. It implies mutation but does not disclose whether it creates a new material or modifies existing, nor does it mention side effects, permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, front-loaded with purpose, and provides useful color examples. 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description is too sparse. It lacks return value information, error handling, and selection prerequisites, making it incomplete for effective use.
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?
With 0% schema description coverage, the description partially compensates by explaining color with examples and noting roughness default. However, it omits any explanation of the required 'name' parameter, leaving a significant gap.
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 ('apply'), resource ('metallic material'), and target ('object'), with a default color specified. It distinguishes from sibling material tools like create_glass and create_emission.
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 material_create_pbr or other material presets. Missing context for selection and prerequisite conditions.
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 carries the full burden. It only lists parameters and does not disclose behavioral traits such as whether the object is added to the active collection, any side effects, return value, or permissions required.
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 Docstring style, starting with the purpose and listing parameters. It is appropriately sized and front-loaded, though the Args section is slightly informal.
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 7 parameters, no annotations, and no output schema, the description covers parameter semantics well but lacks behavioral context (e.g., return value, scene integration). It is adequate but has gaps.
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 provides explanations for each parameter, such as 'extrude: Extrusion depth for 3D effect' and 'align: LEFT, CENTER, RIGHT, JUSTIFY, FLUSH', adding meaning beyond the schema's type and default values.
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 states 'Create 3D text object', which is a clear verb+resource. However, among sibling tools there is also 'create_text', and no differentiation is provided, so it does not fully distinguish from similar 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 versus alternatives like 'create_text', 'create_curve', or other object creation tools. The description does not mention intended context 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?
With no annotations, the description must carry the full burden of behavioral disclosure. However, it only states the conversion action without revealing side effects (e.g., whether the original curve is removed, how mesh is positioned, or any required object state). This 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single-sentence main purpose and a structured Args section. Every word earns its place, but it may be too terse to convey all necessary information without becoming unclear.
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 lacks contextual completeness. It does not explain what the resulting mesh is named, whether it stays in place, or any constraints (e.g., curve must be selected). A more complete description is needed for a tool with these characteristics.
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 includes an Args section with a brief line for each parameter ('Curve object to convert' and 'Keep the original curve object'), adding some meaning beyond the schema titles. However, with 0% schema coverage, more detail would be expected. The information is minimal but functional.
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 specific verb-resource relationship: 'Convert a curve to mesh geometry.' It uniquely identifies the tool's function among many curve-related siblings, as no other tool directly converts a curve to mesh.
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 over alternatives, nor does it mention any prerequisites, contraindications, or typical use cases. The lack of usage context reduces its helpfulness for an AI agent deciding between 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?
With no annotations, the description carries full burden for behavioral disclosure. It does not mention consequences such as permanence, effects on children or associated data, or error handling, which are critical for a deletion operation.
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 concise, but at the expense of completeness. While it is front-loaded, it could include more critical details without excessive verbosity.
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 yet destructive operation, the description omits important context like success/failure behavior, what happens if the object doesn't exist, and whether the action is undoable.
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 parameter 'name' has 0% schema description coverage, and the description only restates 'by name' without adding meaning beyond the schema. It fails to specify the expected format or uniqueness of the name.
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 deletes an object by name, with a specific verb and resource. It distinguishes from sibling tools like batch_delete, which deletes multiple objects.
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 use for deleting a single object by name, but provides no explicit guidance on when to use this tool versus alternatives like batch_delete or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 key behavioral traits such as whether the operation modifies geometry in place, affects UVs, or works on non-manifold meshes. The minimal description 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence front-loaded with the action. No extraneous words, achieving high conciseness.
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 tool's complexity and lack of annotations, the description omits important context such as return value, required object state (e.g., edit mode), and behavior on selections. It is not complete enough for reliable agent use.
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%, yet the description only partially explains the 'offset' parameter as 'offset distance'. It does not clarify the 'name' parameter or provide details like units or range, leaving the agent with limited parameter 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 extrudes all faces of a mesh along normals by an offset distance. It uses a specific verb and resource, distinguishing it from sibling tools like bevel_edges or inset_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 conditions for usage. This leaves the agent without context for proper tool 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. The description does not disclose whether the tool is read-only, requires special permissions, or has side effects. It only states it generates a report, which implies reading, but this is not explicit.
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 single sentence and a short argument list. No redundant information, but it could be slightly more structured with a clearer separation of purpose and parameters.
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 fails to explain what metadata is included in the report or the structure of the output. Since no output schema is provided, the agent must infer the format, which is insufficient for a report generation tool.
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 meaning to 'mesh_name' (name of the face mesh) and 'format' (output format choices: markdown or json), which goes beyond the schema's bare string type. However, it does not list all possible values for format or specify constraints.
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 'Generate' and the resource 'a complete report of all shape keys with metadata', distinguishing it from sibling tools like ft_combine_shape_keys or ft_validate_shapes which perform different operations on shape keys.
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 such as ft_validate_shapes or ft_combine_shape_keys. No conditions, 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.
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 mentions generation but does not indicate async behavior, job polling, or result retrieval. Sibling tools like poll_rodin_job_status suggest async workflow, but the description omits this critical 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 concise, with a clear two-sentence structure: purpose then parameter details. No extraneous information, though it could be slightly more organized.
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 moderate complexity (generation tool, no output schema, no annotations), the description fails to explain the output (e.g., model reference ID), workflow steps (e.g., import or poll), or integration with sibling tools. Incomplete for effective use.
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 description adds value by specifying 'English description' for text_prompt and 'optional [L,W,H] ratio' for bbox_condition. However, it lacks details like units or value ranges, leaving some ambiguity.
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 'Generate', the resource '3D model', and the method 'from text description using Hyper3D Rodin'. It effectively distinguishes from sibling tools like generate_hunyuan3d_model and 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 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. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
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 the full burden of disclosing behavior. It rephrases parameter names slightly (e.g., 'Write .mtl file' for export_materials) but does not explain side effects (e.g., file overwrite policies, file system dependencies, or whether the export applies to the entire scene or selection). The behavioral impact is largely assumed.
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 line for the operation and a compact list of parameters with inline annotations. No extraneous text. The purpose is front-loaded. Every word earns its place.
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 simplicity (6 parameters, no output schema, no annotations), the description covers all parameters with basic explanations. However, it omits important context: whether it exports the current scene, the need for an active scene, file path conventions, or overwrite behavior. The description is adequate for a simple exporter but lacks detail for full self-sufficiency.
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 value beyond the parameter names. It provides brief explanations (e.g., 'Output .obj path', 'Export only selected') that clarify parameter intent. However, these are very close to the parameter titles and lack additional context like constraints or example values. The explanations are functional but minimal.
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 exports to OBJ format, denoted as 'universal mesh exchange', which conveys purpose and scope. While the name alone indicates the format, the description reinforces the specific action. Although it doesn't explicitly contrast with sibling export tools (e.g., FBX, GLTF), the uniqueness is implied by naming the 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 guidance is provided on when to use this tool versus alternatives like io_export_fbx or io_export_gltf. There is no mention of prerequisites, best practices, or scenarios where OBJ is preferred. The description lacks any context for decision-making.
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 carries full burden for behavioral disclosure. It states it adds studio lighting but does not mention side effects, such as whether existing lights are replaced or if specific prerequisites exist (e.g., a scene must be open). This is minimal transparency.
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 the purpose. The 'Args' section is clearly structured. No redundant information exists, though it could be slightly more concise by removing the extra line breaks.
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 setup tool, the description mentions the lights and white world but does not address whether it creates new objects or modifies existing ones, or if it requires a selection. No output schema exists, and behavioral context is limited. 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?
The input schema has 0% description coverage, but the description's 'Args' section adds meaning: it explains 'target_location' as scene center point and 'temperature' with three options and their color temperatures. This is valuable beyond the schema's defaults and 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 up studio lighting with softboxes, specifying '4 area lights + white world'. This is a specific verb and resource. However, it does not differentiate from the sibling 'setup_studio_lighting', which has a nearly identical name.
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?
There is no guidance on when to use this tool versus alternatives like 'light_setup_three_point' or 'add_light'. No prerequisites or exclusions are mentioned. The description only lists parameters without 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?
With no annotations, the description carries full burden. It states assignment but does not detail side effects (e.g., whether existing materials are replaced), error behavior if material or object doesn't exist, or undo impact. Only the slot_index arg gives a hint about appending vs replacing.
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 one-line purpose followed by a structured arg list. No unnecessary words. However, it could be slightly improved with a more natural prose intro.
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 and lack of output schema, the description covers the basic operation but lacks error handling details, confirmation of success, and does not mention whether the operation is undoable. Missing some context for a complete 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?
Despite 0% schema coverage, the description provides meaningful context for all three parameters: object_name, material_name (with precondition hint), and slot_index (with usage explanation). This adds 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?
Description clearly states 'Assign a material to an object' with specific verb and resource. It distinguishes from sibling 'batch_assign_material' by implication of single object, but does not explicitly differentiate, preventing a top score.
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 like 'set_material' or 'batch_assign_material'. Prerequisites are only hinted at in the arg descriptions (material must exist). No when-not or alternative tools 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 provided, the description carries full burden. It implies a read operation but does not confirm lack of side effects. No mention of error behavior, performance impact, or whether the object must be selected.
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 of 8 words, no unnecessary information. Front-loads the core action clearly.
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?
No output schema; description only vaguely mentions 'current settings' without return format details. Lacks info on error handling, required object state, or what constitutes a 'modifier' in the context.
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 description adds no meaning beyond the parameter name 'object_name'. It does not specify the expected format, that it must be an existing object's name, or any constraints.
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 'list' and resource 'modifiers on an object', and adds context 'with their current settings'. It distinguishes from sibling tools like modifier_list_types (which lists modifier types globally) and modifier 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 vs alternatives. No mention of prerequisites (e.g., object must exist) or when not to use it. Siblings include many modifier tools, but no comparative 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 effects. It does not mention if the operation is destructive, reversible, affects children, or requires object selection. Only states it sets origin.
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?
Two sentences, first states purpose, second lists types. Efficient and front-loaded, but could be slightly more structured with bullet points for types.
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 annotations and no output schema, the description lacks important context: what happens to the object's location, is it destructive, any undo implications, prerequisites (e.g., object must be selected). Incomplete for a mutation tool.
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?
Parameter 'name' is not described (implied). 'type' is explained with a list of enum values, adding meaning beyond the schema which lacks descriptions. However, schema coverage is 0%, so description should do more.
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 the specific verb 'Set' and resource 'origin point of an object', and lists distinct types. This clearly distinguishes it from sibling tools like 'center_objects' or 'apply_transform'.
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 (e.g., center_objects, apply_transform). No mention of prerequisites, when to choose one type over another, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must fully disclose behavior. Covers format, engines, and samples, but omits side effects (e.g., file overwrite), permissions, and return value. Provides only partial transparency.
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 concise sentences, front-loaded with key information. Every sentence adds value with no 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?
Covers format and engines but omits resolution parameters and output details. Given 5 parameters and no output schema, the description leaves notable gaps, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning to filepath (format from extension), engine (lists two), and samples (quality vs speed). However, resolution_x and resolution_y are not explained, and default behavior for engine (null) is unclear. With 0% schema coverage, description partially compensates.
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?
Clearly states the tool renders the scene to an image file, with format auto-detection and engine options. Slightly lacks explicit differentiation from render_still, but the name and mention of 'image file' imply single frame vs animation.
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_animation or configure_render. Lacks context for engine selection or sample count recommendations.
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 behavior fully. It explains parameter meanings but does not specify what happens when both color and hdri are set (e.g., which takes precedence), or the effect of strength on each mode. Missing behavioral details like scene-scope or persistence.
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 stating purpose followed by a clean list of arguments. Every sentence adds value, no wasted words. The structure front-loads the main action, making it 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?
Given three parameters, no output schema, and sibling tools that overlap, the description is incomplete. It fails to explain behavior when both background types are set, the role of strength, or how this tool relates to the specialized siblings. Decent for a simple tool but lacking depth for informed use.
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 description must compensate. It adds meaning for all three parameters: color as RGB 0-1, hdri_path as file path, strength as multiplier. However, it does not explain default interactions (e.g., if color is null) or parameter constraints beyond basic type. Adequate but not thorough.
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 explicitly states 'Set world background — solid color or HDRI', clearly identifying the verb and resource. However, it does not distinguish this combined tool from sibling tools `set_world_color` and `set_world_hdri`, which are separate; lacking sibling differentiation prevents a 5.
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 the separate color/HDRI tools. There is no mention of prerequisites, whether to use this for combined effects, or any exclusion criteria. The agent receives no context for tool 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 fully disclose behavioral traits. It indicates the tool modifies scale (relative or absolute) but fails to mention that it changes the object's transform in place, whether it is undoable, or if it affects children or constraints. The description is incomplete 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences, front-loading the purpose in the first sentence. It is efficient but omits some details, earning a high score for conciseness without being 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 the tool has 6 parameters, no schema descriptions, and no output schema, the description is insufficient. It does not explain prerequisites (e.g., object existence), side effects (e.g., affects object's transform), return values, or how it interacts with other transformations (e.g., overwriting vs accumulating). The description leaves significant gaps for an agent to invoke correctly.
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 documentation coverage is 0%, so the description must compensate. It explains the 'uniform' parameter (scale equally when set) and 'relative' parameter (multiply vs absolute). However, it does not explain the x, y, z parameters individually or the required 'name' parameter. The description adds partial value but is not comprehensive.
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 scales an object, using a specific verb and resource. It distinguishes from sibling tools like rotate_object and translate_object, but does not explicitly differentiate from similar tools like apply_transform which also handles scaling.
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 guidance on how to use the uniform and relative parameters, but does not specify when to use this tool over alternatives (e.g., batch_transform for multiple objects or apply_transform for permanent scaling). No exclusions or prerequisites 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 fully disclose behavior. It implies mesh modification but does not state that the operation is destructive, requires sculpt mode, or what side effects occur (e.g., undo stack, symmetry behavior). The description lacks critical 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 well-structured with a clear purpose statement at the start and parameters listed in a readable format. It is not overly verbose, though some parameter lists could be shortened.
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 an output schema (not shown), the description does not mention return values or success/failure. It omits prerequisites (e.g., model must be in sculpt mode), side effects, and behavioral constraints. For a complex tool with 14 parameters, this is insufficient.
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 explain parameters. It covers most key parameters (brush_type, falloff, direction, stroke_points, radius, strength, etc.) but misses others like mesh_name, use_symmetry_x/y/z, and auto_smooth default meaning. It adds context but is incomplete.
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 is a 'Professional sculpt brush with ALL 30+ brush types and full parameter control.' It lists the brush types, falloff, and parameters, distinguishing it from sibling tools like sculpt_brush_stroke which likely have less control.
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., sculpt_brush_stroke, sculpt_mask). There is no mention of prerequisites such as the mesh needing to be in sculpt mode, nor 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 are provided, so the description must convey behavioral traits. It lacks details on prerequisites (e.g., must be in sculpt mode), side effects (e.g., overwrites existing colors), or whether operations are destructive.
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 short and uses bullet points for actions, making it scannable. However, the param examples could be better integrated.
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 the presence of an output schema (unseen), the description omits return value information, preconditions (e.g., mesh selection), and does not fully specify params for all actions (e.g., 'curvature_color' lacks param details).
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 partially compensates by explaining action values and providing example param structures for some actions. However, the 'color' parameter format is only briefly mentioned, and 'mesh_name' is not described.
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 manages vertex colors for sculpt-mode painting and lists specific actions (create, fill, paint_sphere, etc.), making its purpose distinct from sibling 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 versus alternatives (e.g., other sculpt tools like sculpt_brush or texture_paint_fill). The actions are listed but not contextualized.
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?
The description fails to disclose behavioral traits such as return format, pagination, error handling, or side effects. Since annotations are absent, the description bears full responsibility for transparency, but it only lists input parameters without explaining output behavior or operational 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 extremely concise—two sentences covering purpose and parameter details. It is front-loaded with the verb and resource, and every word adds value. 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?
Given the absence of annotations and output schema, the description leaves significant gaps. It does not explain return values, behavior on no results, or how the tool interacts with siblings like download_polyhaven_asset. Users are left guessing about the tool's full 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 must compensate. It adds meaning by listing valid values for 'asset_type' (hdris, textures, models, all) and describing 'categories' as a comma-separated list. This aids understanding beyond the schema, but it could further specify where to obtain valid categories (e.g., referencing get_polyhaven_categories).
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 ('Search PolyHaven assets') and mentions optional filtering. It lists the two parameters with their allowed values, making the purpose clear. However, it does not explicitly differentiate from sibling tools like download_polyhaven_asset or get_polyhaven_categories, which could cause confusion about when to use this tool.
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 usage guidelines are provided. The description does not specify when to use this tool versus alternatives (e.g., get_polyhaven_categories for listing categories, download_polyhaven_asset for downloading). It lacks any contextual cues for when the search is appropriate or what preconditions exist.
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 the action without mentioning side effects (e.g., whether existing keyframes are affected), required scene state, or destructive nature.
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 wasted words. Front-loaded with the core action. Highly concise.
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 and lack of output schema, the description is minimally adequate. It explains the main purpose but lacks details on validation, return values, or interaction with other animation settings.
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 0% schema coverage, the description adds meaning by mentioning 'frame range' for start/end and listing standard FPS values. However, it does not clarify units or constraints beyond what the schema provides.
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 'Set' and the resource 'animation frame range' and optional FPS. It is specific but does not explicitly differentiate from sibling tool 'anim_set_frame_range' which appears to have the same purpose.
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 anim_set_frame_range or anim_insert_keyframe. It only states what it does without any context on 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; description only lists parameters without disclosing side effects, overwriting behavior, or restrictions. It does not fully compensate for missing 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 and front-loaded, but could be better structured (e.g., bullet points). 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?
Covers all parameters with examples, but lacks information on return values, behavior when parameters are null, and edge cases. 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?
Description adds meaning to all 5 parameters beyond the schema (which has 0% coverage). Provides example values and context for location, rotation, focal length, target, and depth of field.
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?
Description clearly states it configures the scene camera and lists parameters. It distinguishes itself from sibling tools like 'render_set_camera' by focusing on scene camera settings, though not explicitly.
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 (e.g., 'render_set_camera'), no prerequisites 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. It only reveals that keep_transform affects whether the child maintains world position. No mention of destructive actions, permissions, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficiently conveying the core action and one key parameter detail. No wasted words.
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 insufficient. It lacks details on what 'child' and 'parent' expect (object names?), any prerequisites, error conditions, or return values.
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%, and the description only adds meaning for 'keep_transform' by explaining its effect. The required parameters 'child' and 'parent' have no additional description, so the tool does not compensate for low 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 verb 'Set' and resource 'parent-child relationship', and distinguishes from sibling 'clear_parent'. It also adds a key behavioral note about the keep_transform parameter.
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 like 'clear_parent' or other hierarchy tools. The description implies usage but does not provide context 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 full burden. It states it generates an asset but does not disclose side effects like file overwriting, permissions required, or behavior on invalid JSON. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, starting with a clear purpose then listing parameters. The JSON example is verbose but informative. No wasted sentences, though could be slightly shorter.
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 (JSON input) and presence of an output schema, the description covers the basic generation task but lacks context on what an AnimatorController is, error handling, or how to determine if the JSON is valid. Adequate but not thorough.
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 listing parameters and providing a detailed JSON format example for animator_json. It explains the required structure beyond the schema's 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 generates an AnimatorController from a JSON blueprint. It specifies the verb and resource, but does not explicitly differentiate from sibling tools like vrc_generate_animator, 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, no prerequisites or exclusions mentioned. The description assumes user knows the context, which is insufficient for an AI agent.
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 for behavioral disclosure. It does not mention side effects like overwriting existing materials, whether materials are created in Assets, or any permissions needed. The description only states the action without behavioral nuances.
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 front-loaded purpose and a bulleted parameter list. It avoids unnecessary words, though the parameter list could be integrated more cohesively. Overall, it is efficient and scannable.
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 presence of an output schema, the description need not detail return values, but it lacks information on error conditions, file creation behavior, and whether materials are saved automatically. The parameter explanations are sufficient for basic usage 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?
The description adds meaningful context beyond the schema, explaining the preset values and their mappings to avatar parts, as well as the default shader. However, 'project_path' is only briefly described as 'Unity project path', and 'output_dir' is not elaborated further. The schema coverage is 0%, so the description compensates well.
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 generates preset materials for common avatar parts, specifying the preset types (avatar_basic, avatar_full) and shader. This distinguishes it from generic material creation tools, though it does not explicitly differentiate from the sibling 'material_create_preset'.
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 'material_create_preset' or other material-related tools. The description lacks context on prerequisites, such as requiring an open Unity project or that the output directory should exist.
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 states 'Add' (a mutation operation) but does not clarify side effects, prerequisites, or whether components replace or append. The output schema exists but is not 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 front-loaded with the purpose. The included JSON example is clear, though slightly lengthy. Every sentence provides necessary 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 lack of annotations and the presence of an output schema, the description adequately covers input parameters but omits details about return values, error conditions, and prerequisites. It is minimally complete for a simple 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 description coverage is 0%, so the description adds significant meaning beyond the input schema. It explains the purpose of each parameter and provides a detailed format for contacts_json, including field names and allowed values.
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 states 'Add VRC ContactSender/ContactReceiver components from JSON blueprint', which clearly identifies the verb, resource, and source. However, it does not differentiate from sibling tools like vrc_setup_contacts, which may serve a similar purpose.
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 a usage scenario but no guidance on when to use this tool versus alternatives. It does not mention when-not-to-use or suggest alternative 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?
Annotations are absent, so the description must bear the burden. It only mentions 'simple projection methods' and parameter names/types but does not disclose whether existing UVs are overwritten, error conditions, or 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 short and includes an args section. No waste, but could be more structured (e.g., separate sections).
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, no annotations, and only 3 parameters with limited explanation. The description covers basic usage but lacks details on return value, errors, or prerequisites. Adequate for a simple 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 compensates by explaining each parameter: object_name as target mesh, projection enumerates three specific methods, scale as UV scale factor. This adds meaning beyond the schema's default values and 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 states it projects UV coordinates using simple projection methods (cube, cylinder, sphere), which is specific. However, the tool name 'uv_project_from_view' suggests view-projection, while the description lists cubic/cylindrical/spherical projections, which may cause slight confusion. It distinguishes from sibling UV tools like 'uv_unwrap' or 'uv_smart_unwrap' by focusing on simple geometric projections.
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 other UV mapping tools (e.g., 'uv_unwrap', 'uv_smart_unwrap') or when not to use it. No prerequisites 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?
No annotations are provided, so the description carries full burden. It states the output is a JSON config for Unity import but does not disclose behavioral traits like idempotency, overwriting behavior, validation, or side effects. Given the lack of annotations, 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 concise and well-structured, with a clear purpose statement followed by a bulleted parameter list. No superfluous text.
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 complexity of VRChat PhysBone configuration and the presence of many sibling tools, the description provides adequate context for the basic purpose but omits workflow constraints or dependencies (e.g., requiring existing bone hierarchy). The output schema exists, so return values are covered elsewhere.
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 all three parameters with examples and listing allowed values for the preset. This compensates well for the minimal 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 it generates VRChat PhysBone configuration for a bone chain, using a specific verb and resource. However, it does not differentiate from the sibling tool 'vrc_setup_physbone_chain', which might have overlapping or complementary functionality.
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 or situations where it is inappropriate, leaving the agent to infer usage from 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?
With no annotations provided, the description carries full burden but only states 'Delete a keyframe' without disclosing side effects, prerequisites (e.g., existence of keyframe), or failure modes, making it insufficient for a destructive operation.
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 main sentence and a parameter list, front-loading the action and containing 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?
Despite having 4 parameters and no annotations or output schema, the description omits return behavior, error conditions, and how to format parameters like data_path. It does not leverage sibling context to differentiate from similar tools, leaving gaps for reliable agent usage.
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 lists parameter names with brief explanations (e.g., 'Target object name', 'Frame number to delete'), adding some meaning beyond the schema's bare types and names. However, given 0% schema coverage, more detailed semantics (e.g., data_path format) would improve clarity.
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 'Delete a keyframe from an object property' with a specific verb and resource, effectively distinguishing it from sibling tools like anim_insert_keyframe and anim_clear_all.
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 such as anim_clear_all or anim_insert_keyframe, leaving the agent without context for proper 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 fully disclose behavior. It does not mention what happens to the original object, whether the operation is destructive, or how a null offset behaves (which is allowed in the schema).
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, front-loading the main action, and includes a helpful example. However, it lacks structured formatting.
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?
With no annotations, no output schema, and 0% schema description coverage, the description should provide more context about the operation's effects, return value, and edge cases. It leaves significant gaps for a 4-parameter tool.
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 description explains count, offset, and use_relative, but fails to describe the required 'name' parameter (which specifies the object to array). With 0% schema description coverage, this omission is significant.
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 'Create a linear array of an object,' which is a specific verb and resource. It distinguishes itself from siblings like 'create_circular_array' by specifying 'linear'.
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 use for linear arrays but does not explicitly state when to use it versus alternatives like 'create_circular_array.' No when-not or exclusion guidance is provided.
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 states 'Applies modifier immediately', indicating that the decimation is applied destructively. However, with no annotations, it fails to mention other behavioral traits such as whether the operation is reversible or what happens to the original mesh data. Some transparency is present 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?
The description is extremely concise at three short sentences with no wasted words. It front-loads the main action and provides essential detail about the ratio parameter. Every sentence earns its place.
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 lack of output schema and 0% schema coverage, the description is incomplete. It does not explain the 'name' parameter, nor does it describe the return value or side effects beyond applying the modifier. With many sibling tools, more context about the tool's scope and behavior 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?
The description explains the 'ratio' parameter with a clear example ('Ratio 0.5 = reduce to 50% of original faces') and its effect. However, the 'name' parameter is not explained, leaving the user to infer it likely refers to the object name. With 0% schema coverage, the description should cover both parameters.
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 'Reduce mesh polygon count', which is a specific verb and resource. However, it does not differentiate from the sibling tool 'vrc_decimate' which likely serves a similar purpose for VRChat. The purpose is clear but lacks distinction.
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 such as 'vrc_decimate' or other modifier-related tools. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states headless mode, opens file, runs code, optionally saves. This is transparent about the core workflow. However, it lacks details on error conditions, timeout behavior (though a timeout parameter exists), or what happens if the file is missing. It provides moderate transparency.
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 with no extraneous words. Essential information is front-loaded. It earns its space efficiently.
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 tool has 4 parameters, no output schema, and many sibling tools, the description is insufficient. It does not explain that the code is Python, the required file path format, or that the script runs in Blender's Python environment. For a batch modification tool, more context is needed for effective use.
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 should compensate. It only mentions the code and save parameters implicitly ('optionally saves'). The blend_file parameter is not described, and timeout is not mentioned at all. The description adds very little to the schema, leaving the agent to guess parameter meaning and format.
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 executes Python code on an existing .blend file in headless mode. It specifies the action (execute, open, run, optionally save) and the resource (existing .blend file), which distinguishes it from siblings like `execute_code` that likely run on the current scene. However, the distinction could be sharper.
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 says 'Great for batch modifications to existing files', providing a usage context. But it does not explicitly state when not to use it (e.g., when you need a visual interface) or mention alternative tools like `execute_code` for scripts without a file. The guidance is implied but not comprehensive.
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 carry behavioral info. It mentions creating bones and shapes but does not disclose side effects like overwriting, idempotency, or error conditions when parameters conflict.
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 two-paragraph structure with front-loaded purpose. The Args section is clear, though it could be more integrated into the main text.
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?
Adequate for a straightforward creation tool, but missing naming conventions for bones and shapes, potential error handling, and interaction with other face tracking setup 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?
Schema coverage is 0%, but the description adds brief parameter descriptions (e.g., 'creates bones (requires armature)') that clarify relationships. However, it does not explain format constraints or default behavior 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 the tool creates tongue bone chain and blend shapes for face tracking, with specific verbs and resources. It distinguishes from sibling tools like ft_setup_eye_tracking_full.
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. No prerequisites or exclusions are mentioned, leaving the agent to infer context from sibling names.
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 behavior. It states 'list' implying a read-only operation, but fails to mention output format (e.g., text, JSON), side effects, or whether connections are returned in a structured way. This is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. However, it is perhaps too concise, lacking necessary detail on parameters and output, which slightly reduces its effectiveness.
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 lack of annotations and output schema, the description is incomplete. It does not explain what 'connections' entails, the format of the returned data, or any constraints (e.g., only top-level nodes). This leaves significant gaps for the 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?
The input schema has 0% parameter description coverage, and the description does not elaborate on the 'tree_name' parameter (e.g., how to specify a tree, valid values, or format). It merely mentions 'in a Geometry Nodes tree,' which adds minimal value beyond the schema's field 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?
The description uses a specific verb 'List' and clearly identifies the resource 'all nodes in a Geometry Nodes tree with their connections,' effectively differentiating it from sibling tools like geonodes_add_node and geonodes_connect.
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 any guidance on when to use this tool versus alternatives, such as when a user needs to inspect node topology versus adding or connecting nodes. No usage context 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?
No annotations are provided, so the description must fully disclose behavior. It lists parameters but omits any behavioral traits such as whether the export overwrites files, requires specific object types, or affects the scene. The defaults for booleans are implied but 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 highly concise: one sentence of purpose followed by a clean bullet-like list of arguments. It is front-loaded with the core function and uses no superfluous words.
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 annotations, no output schema, and low schema coverage, the description lacks essential context. It does not explain return values (e.g., success/failure), side effects, prerequisites (e.g., active object must be selected for selected_only), error handling, or how the export interacts with the scene (e.g., does apply_modifiers modify the original object?).
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 description must add meaning. It does so by listing each parameter (filepath, selected_only, apply_modifiers, ascii_format) with brief explanations, such as 'ASCII STL (True) or binary (False, smaller file)'. However, the explanations are minimal and could provide more detail (e.g., path format, modifier behavior).
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 'Export to STL format (3D printing)', which specifies the verb 'export' and resource 'STL format', and distinguishes from sibling export tools (e.g., io_export_fbx, io_export_obj) by naming the specific 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 guidance is provided on when to use this tool versus alternatives like io_export_fbx or io_export_gltf. The description implies it is for 3D printing, but does not explicitly state context 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. The description does not disclose behavioral traits: whether it replaces existing textures, if a Principled BSDF node is created automatically, or dependencies. The single action 'Add' is vague regarding side effects. With no annotations, the description fails to provide sufficient 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?
Description is concise: one main sentence plus parameter list in docstring format. No unnecessary words. However, the parameter list uses extra whitespace and could be tighter. Still, it's efficient and 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?
No output schema, and description does not mention return values. Given the tool's simplicity (3 parameters, clearly defined), it is minimally complete but lacks details like file path validation, behavior with non-existing materials, and whether multiple textures can be added. For a straightforward operation, it's adequate but not rich.
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 description carries burden. It adds meaning to texture_type by listing four valid options with descriptions (base_color: Albedo/diffuse, etc.), which is helpful. For material_name and texture_path, it merely restates names, offering minimal extra value beyond schema titles. Overall, partial semantic support.
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 an image texture to a material's Principled BSDF. The verb 'add' and resource 'image texture to material's Principled BSDF' are specific, and it distinguishes from sibling tools like set_material_color or set_texture, which may not target Principled BSDF directly.
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_texture or set_principled_bsdf. Missing prerequisites such as material existence or valid texture path. The description does not mention when to choose this over other material editing 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?
With no annotations, the description carries full behavioral disclosure burden. It only describes the basic action but does not disclose error handling, side effects (e.g., what if modifier doesn't exist or position is invalid), or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two lines of purpose plus a parameter list. Every sentence is necessary, and the key information is front-loaded. No waste.
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 tool complexity (reordering modifiers with stack semantics), no output schema, and no annotations, the description is incomplete. It does not cover return values, error conditions, or prerequisites (e.g., the object must have the modifier).
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 for 'position' (0 = top of stack). However, the other two parameters have no additional semantics beyond their names. This partially compensates for the schema's lack, but not 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 verb 'move', the resource 'modifier', and the context 'stack position'. It directly conveys the tool's function and distinguishes it from siblings like modifier_add, modifier_remove, and modifier_list.
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 usage guidelines are provided. The description does not specify when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states the action and parameter meanings, without mentioning side effects, prerequisites (e.g., mesh requirements), or behavior beyond the basic operation.
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 format with a single sentence for purpose followed by a list of argument descriptions. No extraneous text, well-structured.
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 tool has 5 parameters, no output schema, and many sibling physics tools, the description lacks usage context, behavioral details, and expected output. More information is needed 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 description coverage is 0%, so description compensates partially. Each parameter has a one-line explanation (e.g., goal_strength explains scale from floppy to rigid). However, explanations are minimal and lack details on ranges or interactions.
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 'Add soft body physics to an object,' using a specific verb and resource. It distinguishes from siblings like physics_add_cloth and physics_add_rigid_body by specifying 'soft body'.
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 (e.g., cloth or rigid body). The description does not provide context or exclusions, leaving selection to the agent.
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 behavior. It mentions status transitions but lacks details on polling behavior (e.g., rate limiting, timeout, error handling). The description only covers basic status values, leaving significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences, 18 words) and front-loads the purpose. Every word contributes to the core meaning, but it could expand slightly without losing conciseness (e.g., error states). Still, it is well-structured for its simplicity.
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 lack of annotations, output schema, and parameter descriptions, the tool description is incomplete. It does not explain the return format, possible error statuses, or how to interpret the response. For a polling tool, critical context like expected delay or termination conditions is missing.
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% (the job_id parameter has no description in the schema). The tool description does not add any meaning beyond the schema's parameter name 'job_id'. It fails to explain what a valid job_id looks like or where to obtain it, adding minimal 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?
Description clearly states the tool polls Hunyuan3D generation status and defines the statuses ('DONE', 'RUN'). This distinguishes it from sibling tools like get_hunyuan3d_status (which might be a single check) and poll_rodin_job_status (different model). The verb 'poll' and resource 'Hunyuan3D generation status' are specific.
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 after starting a job but does not explicitly state when to use this tool vs. alternatives like get_hunyuan3d_status. No instructions on polling frequency or conditions for stopping. Basic guidance is present but insufficient for optimal agent decision-making.
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?
The description lacks details on whether the operation is destructive, how it affects UVs or vertex colors, and any prerequisites. With no annotations, the description should disclose these 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with purpose, 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?
Covers modes and voxel_size impact but omits output details, object constraints, and any behavioral context. Adequate but not comprehensive for a tool without output schema.
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?
Description adds meaning for 'mode' (lists values) and 'voxel_size' (explains trade-off), compensating for 0% schema coverage. However, 'name' parameter is left unexplained.
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?
Description clearly states 'Remesh an object to create clean, uniform topology,' which is specific and includes modes. However, it doesn't differentiate from the sibling tool 'sculpt_remesh,' which likely performs a similar operation in a different 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 explicit guidance on when to use this tool versus alternatives like decimate, retopology, or sculpt_remesh. The description lists modes but doesn't specify use cases or prerequisites.
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 indicates a mutation (creation) but does not disclose side effects, permissions needed, or behavior when a collection with the same name 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?
The description is very concise: one sentence and a bullet list of arguments. No unnecessary information. The purpose 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 presence of a very similar sibling ('create_collection') and no output schema, the description adequately explains the tool's function and parameters. However, it lacks information about return values, error states, or how the tool interacts with the scene context, leaving some gaps.
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 by explaining 'parent' defaults to Scene Collection and enumerating valid color_tag values ('COLOR_01 through COLOR_08, or NONE'). With 0% schema coverage, this provides necessary detail, though parameter constraints like name format remain unspecified.
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 purpose: 'Create a new collection in the scene.' It specifies the verb and resource. However, the sibling list includes 'create_collection' without the 'scene_' prefix, and the description does not differentiate from that tool, which could confuse an agent.
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 'create_collection' or 'list_collections.' There are no prerequisites, context restrictions, or exclusions stated.
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 bears full responsibility. It mentions saving 'relative to the basis' and auto-creation of basis if missing, but does not disclose side effects like modification of existing shape keys or permanent mesh changes. Safety and prerequisites are not addressed.
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 purpose. Each sentence adds value, though the Args section partially duplicates schema content. Overall 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?
For a tool with 3 params, no output schema, and no annotations, the description covers basic purpose and example usage but leaves gaps about exact behavior (e.g., how shape key is created, impact on mesh). Adequate but not 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?
The Args section adds minimal value: it lists parameter names and provides an example for shape_key_name. For basis_name, it notes auto-creation if missing. Schema coverage is 0%, so description partially compensates but lacks detailed constraints or format information.
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 saves the current mesh state as a shape key relative to the basis. It gives a concrete use case (face tracking workflow). However, it does not explicitly distinguish from sibling tools like 'ft_sculpt_shape_key' or 'cloth_to_shape_key', so it lacks full differentiation.
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 after sculpting a facial pose for face tracking. It does not provide when-not-to-use or alternatives. With many sibling tools, more explicit guidance would be beneficial.
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 fully disclose behavior, but it does not explain whether an existing material is overwritten, what happens if the object has no material, or the effect of the optional material_name parameter.
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: one for purpose and one for the color parameter. It is front-loaded and contains no unnecessary words.
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 tool's simplicity and lack of annotations, the description is too brief. It omits usage guidelines, behavioral details, and full parameter explanations, which are needed for proper selection and invocation.
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 by specifying the color format ([R,G,B] or [R,G,B,A] with 0-1 range), but does not explain object_name or material_name. Schema coverage is 0%, so the description partially 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 the verb 'set or create' and the resource 'simple color material on an object', distinguishing it from sibling tools like material_create_pbr or material_set_texture.
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 like set_material or material_create_pbr. The description does not mention exclusions or prerequisites.
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 should disclose behavioral traits. It only states that it sets visibility, but does not mention error handling (e.g., object not found), side effects, or whether the change is persistent. This is insufficient for a tool with no safety 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?
The description is a single, concise sentence with no wasted words. It could benefit from more detail, but remains efficient for a simple 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?
The description covers the basic function but lacks context on error states, required user permissions, or how it differs from similarly named sibling tools. Minimal completeness for a simple parameter setter.
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 linking 'visible' to viewport and 'render_visible' to render. However, the 'name' parameter is not explained at all (e.g., case-sensitivity, type of identifier). Partial value added.
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 viewport and render visibility of an object, matching the two boolean parameters. It distinguishes from sibling tools like set_collection_visibility which target collections.
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 such as set_collection_visibility or scene_set_visibility. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It lists operations and some parameter details but omits critical information: whether changes are destructive, required permissions, side effects on UV layers, or any error conditions. The term 'UV mapping operations' implies modification, but specifics are absent.
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: a brief introductory line followed by a clear bullet-point list of operations with their parameters. Every sentence adds value, with no redundant or extraneous information. The format is easy to scan and front-loaded with the core 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?
Given the sparse schema, missing annotations, and numerous sibling UV tools, the description provides adequate but not complete context. It covers the operations and their parameters but lacks information about return values (despite an output schema existing), prerequisites (e.g., existing UV layers), error handling, and the overall workflow impact. This leaves gaps for the agent to infer.
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% coverage for parameter descriptions, so the description adds significant value by explaining each operation's custom parameters (e.g., angle threshold for auto_seams, margin for pack_islands). However, the format for the 'params' string is shown but not strictly specified, and the 'operation' parameter values are listed but not enforced as enums.
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 provides 'Advanced UV mapping operations beyond basic smart project' and enumerates specific operations (auto_seams, pack_islands, etc.), effectively indicating its purpose. However, it could better differentiate from sibling UV tools like uv_unwrap or uv_smart_unwrap by explicitly stating when to use this bundled tool versus individual ones.
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 only mentions 'beyond basic smart project' as context, but does not provide explicit guidance on when to use this tool versus alternatives like uv_unwrap or smart_uv_project. No 'when not to use' or prerequisites are mentioned, leaving the agent without clear usage boundaries.
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 states the tool generates a file but does not disclose potential side effects (e.g., overwriting existing files), permission requirements, or error handling for malformed JSON. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with a clear structure: one-line summary followed by parameter list and example JSON. However, the example takes up space and could be 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 that there is an output schema (not shown) and 3 parameters with no descriptions, the description should provide more context. It does not explain the format or purpose of the output .asset file, nor how the JSON blueprint maps to VRC parameters. Feels incomplete for a file generation tool.
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. It lists parameters with a JSON format example for parameters_json, which adds value by showing structure and allowed valueTypes. However, it does not explain the meaning of each field beyond the example, and output_path default is missing.
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: generate VRCExpressionParameters .asset file from JSON blueprint. The verb 'Generate' and resource 'VRCExpressionParameters .asset file' are specific, and the description distinguishes it from sibling tools like unity_setup_expression_menu by focusing on parameters.
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 (e.g., unity_setup_expression_menu). The description does not mention prerequisites, conditions, or exclusions, 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?
Description explains what the tool does but does not disclose behavioral traits such as whether it overwrites existing layers, requires specific Unity project setup, or any side effects. No annotations provided to compensate.
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 concise: one sentence for purpose, one for gesture list, and bullet-pointed parameters. No wasted words; front-loaded with key 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, the description covers the main function and parameters. However, it lacks details on return value (output schema exists but not mentioned) and behavior on existing files. Adequate but not thorough.
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?
Description adds meaning beyond the input schema by explaining each parameter: project_path, output_path, and hand_gestures with allowed values ('default' vs 'custom'). Since schema has no descriptions, this is valuable context.
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?
Description clearly states it creates a VRChat Gesture FX layer with hand gesture states and lists the 8 standard gestures. However, it does not differentiate from the sibling tool 'vrc_setup_gestures', which may have overlapping functionality.
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 (e.g., vrc_setup_gestures). It does not provide exclusions or prerequisites, 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?
With no annotations, the description bears the full burden of behavioral transparency. It only states the operation's basic purpose and parameters. It does not disclose important traits such as whether the operation is destructive, if it modifies the active UV layer, or how it handles seams and overlapping islands.
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 purpose followed by a compact Arg list. It is front-loaded with the core action and efficiently conveys the necessary information without any 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?
Given the lack of output schema and annotations, the description covers the basic purpose and parameters but leaves gaps. It does not explain the result or side effects (e.g., does it modify an existing UV layer or create a new one?), nor does it specify the margin unit or behavioral constraints.
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. Each parameter (object_name, margin, rotate) is briefly explained with a short phrase, adding meaning beyond the schema's titles and types. However, the explanations are minimal and could include acceptable ranges, units, or typical usage notes.
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 (Pack) and the resource (UV islands) with a specific goal (fill UV space efficiently). It distinguishes from sibling tools like uv_unwrap and uv_smart_unwrap by using different terminology, but it does not explicitly differentiate from smart_uv_project or smart_uv_tools, which could overlap.
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 prerequisites (e.g., existing UV unwrap) or when not to use it (e.g., for projection-based tasks). There is no explicit comparison 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?
With no annotations, the description carries the full burden. It only says 'UV unwrap a mesh' without disclosing side effects (e.g., overwrites UV layer, requires existing seams, creates new map). No output schema to clarify return values.
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?
Three concise sentences: purpose first, then param details. No redundant information. Efficiently communicates key points.
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 mesh-modifying tool with no output schema and zero annotations, the description is too brief. It omits prerequisites (e.g., seams must be marked), whether it adds or replaces UVs, and what the result is. Incomplete for safe agent usage.
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 description adds value: explains METHOD and MARGIN. However, the required 'name' parameter is undocumented. Provides partial but helpful context beyond 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 tool does UV unwrapping using seam-based method, distinguishing it from UV projection or smart unwrap. However, it doesn't explicitly differentiate from similar tools like uv_smart_unwrap, which may also use seams but with different algorithms.
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 seam-based unwrapping but provides no guidance on when to use this tool over UV siblings (e.g., uv_smart_unwrap, uv_project_from_view). No exclusions or prerequisites 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 provided, the description bears full responsibility for disclosing behavior. It mentions 'zoom to fit' but does not explain how the viewport is adjusted (e.g., does it change camera type? does it affect locked views?), nor does it address potential side effects or required permissions. The behavioral description is insufficient for an agent to predict the tool'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—two short sentences—and front-loads the essential purpose. Every word contributes meaning without redundancy. It efficiently communicates the core action.
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 (one required parameter, no output schema, no annotations), the description is minimally adequate but lacks details about error handling, behavior when the object name is ambiguous, or what 'focus' entails exactly (e.g., does it change the active view? does it respect locked cameras?). A more complete description would address these edge cases.
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 description coverage is 0%, so the description must compensate. It provides 'Object to focus on' for the only parameter, which adds minimal meaning beyond the property title 'Object Name'. It does not specify format, uniqueness constraints, or behavior if the object is not found.
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 'focus' on the resource 'viewport' for a specific object, with the parenthetical 'zoom to fit' clarifying the behavior. This is distinct from other viewport tools like viewport_set_view which manipulate camera position generally, or viewport_set_shading which changes appearance.
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. There is no mention of prerequisites, typical use cases, or conditions under which another tool might be more appropriate. The description only states the action 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 the description carries full burden. It states the tool sets viewport shading mode but does not disclose side effects (e.g., viewport redraw, persistence), required permissions, or behavior beyond changing mode. The parameter enums are helpful but incomplete for full transparency.
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 (4 lines), front-loads the purpose, and uses a clear docstring format. Every line adds value, though the 'Args' structure repeats schema info slightly. 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, the description covers the basic purpose and parameter options. However, it lacks usage context, prerequisites, and error behavior, making it minimally complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, so the description must compensate. It lists valid values for mode (WIREFRAME, SOLID, MATERIAL, RENDERED) and adds context for studio_light and color_type. However, it does not explain what each mode does or the format for studio_light, leaving gaps.
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 name 'viewport_set_shading' and description 'Set viewport shading mode' clearly specify the action and resource. It distinguishes from siblings like 'viewport_set_overlays' and 'viewport_set_view' by targeting shading mode specifically.
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 (e.g., other viewport settings). The description only states what it does, not when or when not to use it, 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 carry the full burden of behavioral disclosure. It mentions key behaviors (parenting, hierarchy, optional toggle) but omits important details: side effects, required permissions, error conditions, and whether the operation is destructive or reversible. This is insufficient for a tool with 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose but becomes a dense bullet list of parameters. It is somewhat lengthy for the content, though each sentence serves a purpose. Could be streamlined by grouping related parameters or using a more compact format.
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 tool's complexity (7 parameters, no output schema, no annotations), the description is incomplete. It lacks information on return values, error handling, prerequisites (e.g., need an armature and accessory), and does not specify when to use among sibling VRC tools.
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 explain parameters. It does so for all 7 parameters, providing clarity on defaults and format (e.g., 'rotation_correction' with examples 'X90', 'Z-90'). While some descriptions are concise, they add value beyond the schema 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 tool's purpose: 'Attach an accessory object to a bone on the avatar armature.' It uses a specific verb (attach) and resource (accessory to bone), and distinguishes itself from sibling tools by referencing VRCFury's armature link and detailing the parameters.
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 any guidance on when to use this tool vs. alternatives. It does not mention prerequisites, context, or exclusions. The only hint is 'Similar to VRCFury's armature link,' but this does not provide explicit usage 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?
The description explains parameter-specific behavior like rotation controlling direction for SPOT/AREA and size for shadow softness, but does not disclose broader behavioral traits such as side effects, limits, or prerequisites. Since no annotations exist, the description carries the full burden, which it partially meets.
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 brief (three sentences), front-loaded with the primary action, and presents details in a structured list. 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?
Given 7 parameters, no output schema, and no annotations, the description is moderately complete. It covers key parameters but misses 'name' and 'location', and does not mention return values or prerequisites. 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?
With 0% schema description coverage, the description must compensate. It explains type, energy, color, size, and rotation, but omits 'name' and 'location'. This adds value over the schema but is incomplete for all parameters.
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 adds a light to the scene and lists the light types. However, it does not differentiate itself from the sibling tool 'light_add', which likely performs a similar function, leaving 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 like 'light_add' or 'light_setup_studio'. The agent receives no context for selecting this tool over siblings.
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 only states the action without disclosing behavioral traits like whether constraints are appended or replaced, required armature mode (e.g., pose mode), or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact list of arguments, each line conveying essential information. It is well-structured and concise, though slightly verbose with Python-style args formatting.
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 tool has 6 parameters, 3 required, no output schema, and no annotations, the description lacks return value info, success/failure signals, and prerequisites (e.g., armature must be in pose mode). It is incomplete for safe 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?
Despite 0% schema description coverage, the description lists parameters with types and explains constraint_type options (e.g., COPY_LOCATION), target armature/bone usage, and the params dict. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add a constraint to a pose bone,' which is a specific verb and resource. It clearly distinguishes from sibling tools like 'add_cloth' or 'add_modifier' by targeting pose bone constraints.
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 any guidance on when to use this tool versus alternatives (e.g., 'add_constraint', 'remove_constraint'), nor does it specify prerequisites or restrictions.
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 carries the full burden. It states the tool 'applies the result to the mesh' but does not disclose whether the modification is destructive, if undo is supported, or if baking is required. Lacks details on performance impact or blocking 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 concise with a clear header paragraph followed by well-structured parameter descriptions. Every sentence is useful, though the 'Args' list could be integrated more naturally. Overall, it is efficiently written without unnecessary verbiage.
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 complexity of cloth simulation and the absence of an output schema, the description is incomplete. It does not explain what 'applies the result to the mesh' entails (e.g., modifies vertices, creates shape keys) or mention required preconditions like an existing cloth modifier. The lack of behavioral context limits its usefulness 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?
Although schema description coverage is 0%, the description includes an 'Args' section that explains each parameter's role (e.g., 'pin_vertex_group: Vertex group for pinned vertices'). This adds significant meaning beyond the bare schema names and defaults, compensating 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 tool runs a cloth simulation for modeling purposes, with specific examples of draping fabric, cape rest poses, or skirt shapes. It distinguishes itself from sibling tools like 'add_cloth' and 'physics_add_cloth' by focusing on simulation rather than adding a modifier.
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. It doesn't mention prerequisites (e.g., cloth modifier already added) or scenarios where other tools would be more appropriate. Implies usage through examples 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Basic creation behavior is clear, but with no annotations, the description doesn't reveal side effects (e.g., whether object is added to scene, coordinate system, error handling). It explains point format and a few settings, but not overall 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?
Efficient four-sentence description with front-loaded purpose. No unnecessary words; each sentence adds vital information. Well-structured.
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?
Handles key parameters but missing extrude, resolution, and name. Lacks output details (no output schema) and operational context (scene placement, default behavior). Adequate but not fully comprehensive for a creation tool with 8 parameters.
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 explains points format, bevel_depth, close, fill, and type, adding value beyond the raw schema (0% coverage). However, it omits extrude, resolution, and name parameters, leaving gaps.
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 creates a curve from control points and lists available types (BEZIER, NURBS, POLY). This differentiates it from sibling curve tools that are more specialized (e.g., curve_create_circle), but it does not explicitly contrast them.
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 curve_create_bezier or curve_create_nurbs. The description explains how to configure parameters but lacks context for tool 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?
Description lacks disclosure of side effects: whether it replaces existing material, applies to selected object, or creates a new material slot. With no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no redundant information. Every word 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?
Adequately explains purpose and two key parameters, but misses details on the 'name' parameter and overall behavior (e.g., object scope, material slot handling). With no output schema, more completeness would help.
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?
Adds meaning for color (explains RGBA format) and strength (threshold for visible glow in Cycles), partially compensating for 0% schema coverage. However, the 'name' parameter is not described.
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 'apply an emissive material to an object' with specific verb and resource. It distinguishes from siblings like create_glass or create_metal by focusing on emissive (glowing) material.
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 other material creation tools (e.g., create_glass, material_create_pbr). Only parameter hints for color and strength are provided, not 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?
No annotations are provided, so the description must fully disclose behavior. It states 'download and import' but does not explain side effects (e.g., scene changes, overwriting, required internet connection, or authentication). This leaves important behavioral traits undisclosed.
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 with the main action. It avoids fluff but could be better structured (e.g., bullet points for parameters). Still, every sentence adds value.
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 4 parameters, no output schema, and no annotations, the description is incomplete. It does not explain where in Blender the asset is imported, what happens to existing objects, or the return/result. Key context for a download-and-import operation is missing.
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 0% schema description coverage, the description adds meaning for asset_type, resolution, and file_format by listing allowed values. However, the 'asset_id' parameter is not described at all, and the relationship between asset_type and file_format is only partially explained. The description provides some but not comprehensive parameter info.
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 downloads and imports a PolyHaven asset into Blender, specifying acceptable asset types (hdris, textures, models), resolutions (1k, 2k, 4k), and file formats per type. This distinguishes it from siblings like search_polyhaven_assets or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies the tool is for PolyHaven assets, it does not explicitly state when to use it over alternatives or when not to use it. With many sibling tools, explicit guidance on preconditions or exclusions (e.g., needing an asset ID from search) would improve clarity.
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 discloses that it creates 12 shape keys and ensures blink/lowerlid exist, which is behavioral. However, with no annotations, it omits details like prerequisite mesh conditions, potential side effects (e.g., overwriting existing shape keys), or permission requirements. Moderate transparency.
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, using two short paragraphs: one for purpose and one for parameters. No wasted words, and the structure is 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 simplicity (2 params, no output schema, no annotations), the description covers the main functionality. However, it lacks prerequisites (e.g., mesh must be a specific type or have certain topology) and does not mention return values or errors. 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?
Since schema description coverage is 0%, the description compensates by explaining both parameters: mesh_name is the face mesh, armature_name is optional for eye bone configuration. This adds meaningful context beyond the raw schema types 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 sets up extended eye tracking beyond basic blink/lowerlid, listing the 12 specific shape keys created. This differentiates it from simpler eye tracking tools and provides a specific verb+resource.
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 (e.g., ft_create_arkit_shapes or vrc_setup_eye_tracking). The context is implied but not stated, leaving the agent to infer usage without clear exclusion criteria.
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 says 'Add a node', without mentioning what happens on success/failure, whether the tree is modified, or if there are side effects. For a mutation 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 concise: a one-line summary followed by a parameter list. It is front-loaded and easy to scan. The examples for node_type are helpful but could be separated more clearly.
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 moderate complexity and absence of an output schema, the description should explain what the tool returns (e.g., the created node) and any prerequisites (e.g., existence of the tree). It does not, leaving the agent without key information to use the tool effectively.
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 0% schema description coverage, the description adds minimal meaning: it names each parameter and gives brief context (e.g., 'Blender node type (e.g., GeometryNodeMeshPrimitiveCube...)'). However, it does not specify constraints or formats for 'location' or 'name' beyond the schema types, so it adds only limited 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 'Add a node to a Geometry Nodes tree', specifying the verb 'add', the resource 'node', and the context 'Geometry Nodes tree'. This distinguishes it from sibling tools like geonodes_create (creates the tree) and geonodes_connect (connects nodes).
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 no explicit guidance on when to use this tool versus alternatives, or any prerequisites. It is implied that the tree must already exist and that the user wants to add a node, but 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states it creates a geo-nodes setup but does not mention whether it modifies the existing modifier stack, if it is destructive, or what the return value is. These gaps hinder 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear paragraph and parameter list. No filler words. However, the phrase 'Apply a preset:' may be slightly redundant given the tool name. 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?
Given the lack of output schema and annotations, the description does not explain the return value or side effects (e.g., does it modify the object in place? Does it return a success message?). This leaves the agent uncertain about the tool's aftermath.
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% coverage, so the description's Args section adds critical meaning: object_name as surface, instance_type with examples (SPHERE, CUBE, CONE, custom), density as points per unit area, scale, and seed. This compensates well 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 'Apply a preset: scatter instances on a surface' and explains it creates a complete geo-nodes setup for distributing point instances. This verb+resource combo is specific and distinguishes from siblings like add_particles or distribute_objects.
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 explicit guidance on when to use this tool versus alternatives (e.g., add_particles, distribute_objects). No prerequisites or exclusions are mentioned, so an AI agent lacks context to choose between similar 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 bear full responsibility. It states 'set ... default value' but does not disclose behavioral details such as mutation permanence, overwriting existing connections, or error handling. The tool is clearly a mutation, yet no side effects or safety information is conveyed.
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 followed by a bullet list of four parameters. It is front-loaded with the essential purpose, and every line serves a clear function. No wasted text.
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, no output schema, and a 4-parameter tool, the description is incomplete. It omits information about return values, success/failure indications, prerequisites (e.g., tree must be editable), and any constraints. While it covers the basics, it lacks the depth needed for reliable use.
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 includes a parameter list with brief semantics for each argument (e.g., 'tree_name: Node tree name'), adding meaning beyond the bare schema which has no descriptions. However, the 'value' parameter type is vague ('float, int, vector list, etc.'), and the description lacks format details. With 0% schema coverage, this partially compensates but could be richer.
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 ('Set') and the resource ('a node input's default value'). It is distinct from sibling geonodes tools like 'geonodes_add_node' or 'geonodes_connect'. The verb and resource are 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, nor does it mention prerequisites (e.g., the node or node tree must exist). It only states what it does, 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?
No annotations are provided, and the description does not disclose what the return value is (e.g., a ratio, boolean, or list) or any side effects. It vaguely says 'determine how symmetric' but gives no quantitative details. The threshold parameter is explained only in terms of its definition, not its effect.
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 succinct, with a clear purpose sentence followed by a brief explanation and parameter list. No redundant information. It could potentially integrate the parameter descriptions more naturally, but overall it is efficiently structured.
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 explain what the tool returns or how to interpret the result. With no output schema, the agent is left guessing whether the output is a boolean, a numerical value, or a report. This is a significant gap for a measurement tool.
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 description must compensate. It does provide brief parameter explanations (object_name, axis, threshold) that add basic meaning beyond names and types. However, it lacks details on defaults, constraints, or format (e.g., axis values given as example only).
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 mesh symmetry across an axis' and 'Analyzes vertex positions to determine how symmetric the mesh is'. It uses a specific verb-resource combination and distinguishes itself from sibling measurement tools like measure_distance and measure_dimensions.
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 checking symmetry but provides no explicit guidance on when to use this tool vs alternatives (e.g., measure_alignment). No exclusions or comparisons are given, leaving the agent without decision context among many 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?
With no annotations, the description must disclose behavioral traits. It only states that it generates files, but does not discuss side effects, overwrite behavior, permissions, or any other operational aspects.
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 clear sentences about the tool's purpose followed by a well-structured 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 adequately covers the tool's output files and parameters. However, given that this is a pipeline tool with many siblings, the lack of usage guidance and behavioral details partly undermines 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?
The description provides explicit parameter explanations outside the schema, which has 0% coverage. It explains default behaviors for mesh_name and output_dir, and the purpose of avatar_name, adding meaningful semantics.
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 exports configuration JSONs for Unity import and lists specific files. It uses a specific verb and resource, making the purpose clear, but does not explicitly differentiate from related pipeline tools such as pipeline_blender_to_unity.
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 other export or pipeline tools. It does not mention prerequisites, when not to use it, or alternatives.
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?
The description lacks behavioral details beyond the basic operation. It does not disclose what happens when there is nothing to redo, potential side effects, or any error states. Since no annotations are provided, the description should compensate but fails to do so.
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, concise sentence with no unnecessary words. It is front-loaded and to the point.
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 parameters and no output schema, the description is minimal but functionally adequate. However, it lacks context about prerequisites (e.g., that an undo must have been performed) and does not describe any edge cases or behavior in abnormal states.
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?
There are no parameters, and schema coverage is 100%. The description adds no parameter information, but baseline is 3 for high schema coverage. No extra value is provided.
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 ('Redo') and the resource ('the last undone operation in Blender'). It is specific and the purpose is immediately understandable. However, it does not explicitly distinguish from sibling tools like 'undo', but the context of the sibling list implies the relationship.
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 conveys that the tool is for redoing after an undo operation, but it does not provide explicit guidance on when to use it versus alternatives, nor does it mention any preconditions 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 carries full burden. It only states the basic operation and a prerequisite, but does not disclose what happens to the object's material (e.g., replacement, slot assignment), required material existence, or any side effects. This is insufficient for safe use.
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 long, front-loads the action, and contains no extraneous information. Every word is relevant and purposeful.
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 the tool's low complexity, the description omits crucial details: whether the object must have a material, whether the texture replaces or adds, error conditions, and behavior if the texture_id is invalid. The prerequisite is the only additional context beyond the 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 coverage is 0%, yet the description adds no meaningful explanation for either parameter. 'texture_id' is only mentioned as prerequisite, not its format or how to obtain it. 'object_name' has no description. The parameter semantics are completely lacking.
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: 'Apply a previously downloaded PolyHaven texture to an object.' It uses a specific verb and resource, and the prerequisite distinguishes it from generic material tools like 'set_material' or 'material_set_texture'.
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 states the prerequisite: 'texture_id must have been downloaded first via download_polyhaven_asset.' This gives clear context for when to use the tool, though it does not compare directly to sibling tools or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without describing side effects, required object properties, or performance implications. For a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, with no redundant words. It effectively communicates the core functionality without any extraneous 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 provides the essential purpose but omits context such as applicable object types or whether the change is reversible. It is minimally adequate but lacks completeness.
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. It clarifies that 'smooth=True' means smooth and 'False' means flat, which maps the boolean to concrete visual outcomes. However, no further detail is given beyond the schema, and the parameters are simple, so the added value is marginal.
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: setting smooth or flat shading on an object. It specifies the verb ('Set') and the resource ('shading on an object'), with a clear mapping of the boolean parameter. This distinguishes it from sibling tools like 'modifier_preset_smooth_shade' that may use a different mechanism.
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, such as the sibling 'modifier_preset_smooth_shade'. It lacks context on prerequisites, exclusions, or typical use cases, forcing the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It does not disclose whether operations are destructive, require permissions, or are undoable. Modifying actions like 'add_loop_cut' imply geometry changes but are 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro followed by bullet-point parameter details. It is efficient but slightly verbose for the parameter section; still, it avoids 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 the presence of an output schema (not shown), the description adequately covers actions and parameters. However, it lacks information about what each action returns or modifies (e.g., selection changes after 'select_non_manifold').
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 thoroughly by explaining each action and parameter in detail (e.g., action values, default for loop_cuts, edge_index usage). This adds substantial meaning beyond the raw 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 tool's purpose ('Work with edge loops for clean topology') and lists specific actions (analyze, add_loop_cut, select_non_manifold, analyze_poles), distinguishing it from sibling mesh tools. However, it does not explicitly contrast with similar tools like bridge_edge_loops.
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 animation deformation ('Essential for animation deformation') but provides no explicit guidance on when to use this tool versus alternatives, nor 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 carries full burden. It reveals the algorithm is angle-based but does not disclose important traits such as whether it modifies existing UVs, requires edit mode, or has limitations. Insufficient for an agent to fully understand the 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?
Description is brief (3 lines plus parameter list) and well-structured. Every sentence adds value. The parameter block is clear and easy to parse. No wasted words, 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?
Covers purpose and parameters adequately but misses higher-level context: return value (none implied), side effects (UV map modification), prerequisites (mesh must have faces?). With no output schema, more guidance on expected outcome would be helpful.
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 lacks descriptions, but the tool description provides human-readable explanations for all four parameters (object_name, angle_limit, island_margin, area_weight) including defaults and units. Adds meaningful context beyond the schema fields.
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?
Clearly states it performs automatic UV unwrapping using 'Smart UV Project' based on face angles. Provides intended use cases (hard-surface models, mechanical parts, props). However, it does not differentiate from sibling UV tools like smart_uv_project or uv_unwrap.
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?
Suggests when to use (good for hard-surface models) but lacks explicit guidance on when not to use or alternatives. No comparison with other UV unwrapping methods provided.
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 mentions using Blender's automatic weights (heat map) and setting up an armature modifier, which gives some behavioral insight. However, it does not disclose whether the operation overwrites existing weights or modifiers, potential failure cases, or the destructive nature of the 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 uses bullet points for parameters, making it easy to parse. It contains no unnecessary information, though it could be slightly more concise by combining sentences.
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 optional parameters and an output schema, the description is adequate but lacks information about edge cases (e.g., missing mesh/armature) and what the tool returns. The output schema covers return values, so this 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?
The input schema has 0% description coverage, but the description explains both parameters clearly, including default behaviors (empty mesh_name uses 'Body' or first mesh; empty armature_name uses first armature). 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it automatically weight paints a mesh to an armature using Blender's automatic weights and sets up the armature modifier. However, it does not differentiate from the sibling tool 'armature_auto_weight', which may perform a similar task.
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 auto-weight-painting but lacks context about prerequisites, limitations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that ACTIVE is affected by gravity and PASSIVE is a static collider, and notes that MESH collision shape is exact but slow. This adds behavioral context beyond the input schema.
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 concise sentences that front-load the core purpose and then expand on key parameters. No unnecessary words.
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 covers type and collision_shape but omits details on mass, friction, restitution, and does not mention any return value or outcome. For a tool with 6 parameters and no output schema, this is insufficient.
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?
Adds meaning for 'type' and 'collision_shape' by listing valid values and their behavior, but does not explain 'mass', 'friction', 'restitution', or 'name'. With 0% schema coverage, more could be done.
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 'Add rigid body physics to an object' and provides details about types and collision shapes. However, it does not differentiate from the sibling tool 'physics_add_rigid_body'.
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 cloth or soft body physics. The description explains types and collision shapes but lacks context about prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions the bouncing effect but does not state whether it modifies existing animation, creates keyframes, or is reversible. The term 'preset' is ambiguous about actual 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 and front-loaded with the main purpose. The Args list is clear and well-structured. No redundant information, though slight improvement could be made by integrating args description more directly.
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 4 parameters, no annotations, and no output schema, the description adequately covers the main functionality and parameter meanings. However, it lacks information about prerequisites (e.g., object must exist) and the exact nature of the 'preset' created.
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 brief but clear explanations for all 4 parameters (e.g., 'height: Initial bounce height'), adding value beyond schema titles. However, the explanations could be more detail-rich.
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 creates a bouncing animation preset with specific behavior (decreasing amplitude). This distinguishes it from siblings like anim_orbit or anim_set_interpolation, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives. There are many animation-related tools among siblings, but the description does not offer any context about when bouncing is appropriate or what prerequisites exist.
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 behavior. It only states what is created ('single root bone') but not side effects (e.g., selection, active object), state requirements, or whether it operates in object mode. This leaves transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (three sentences) and front-loaded with the core purpose. The parameter listing is efficient, though it slightly overlaps with schema information. 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?
Given no output schema and no annotations, the description could be more complete. It lacks information about return value (e.g., created object name), error cases, or relation to sibling tool create_armature. Adequate for a simple creation tool 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 description adds meaning beyond the schema: it clarifies that location is a 3-element [x, y, z] array. Schema coverage is 0%, so the description carries the full burden. While it doesn't detail defaults or optionality, it provides essential format info, making it 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 action (create) and resource (armature object with a single root bone). It distinguishes from sibling tools like armature_add_bone and armature_add_bones_chain which operate on existing armatures. The specification of 'single root bone' adds precision.
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. There is no mention of prerequisites, context (e.g., object mode required), or when not to use it. Given many sibling tools like create_armature and armature_add_bone, explicit differentiation is needed.
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 indicates it is a read operation ('List') and includes 'hierarchy info', but does not explicitly state it is non-destructive or describe side effects. For a simple query tool, this is adequate but not complete.
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 that conveys the essential information with no wasted words. It is front-loaded and 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?
For a simple listing tool with no output schema, the description provides core behavior but lacks details on return format (e.g., list of names, tree structure). It is minimally complete but could be more precise.
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 no parameter descriptions in schema. The tool description does not elaborate on the only parameter, 'armature_name' (e.g., how to specify it, validation). This leaves agents without guidance on parameter 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 the verb 'List' and the resource 'bones in an armature', and specifies that it provides 'hierarchy info'. This distinguishes it from sibling tools like armature_add_bone or armature_set_pose.
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 vs alternatives, such as armature_set_pose or armature_add_bone. However, the name and description imply it is for querying bone structure, so usage is somewhat 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 states it bevels all edges but does not mention whether it is destructive, modifies the mesh in place, or requires a specific selection mode. The impact on mesh geometry is implied but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two clear, concise sentences with no fluff. It front-loads the main action ('Bevel all edges of a mesh') and then describes the parameters efficiently.
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 complexity of mesh operations and lack of output schema/annotations, the description is incomplete. It does not explain return values, preconditions (e.g., object must be a mesh), or postconditions. More context is needed for safe use.
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. It explains that 'width controls bevel size' and 'segments controls smoothness', which adds value. However, the required 'name' parameter is not explained.
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 bevels all edges of a mesh, with specific parameters (width, segments) for control. It uses a specific verb and resource, distinguishing it from sibling tools like 'add_modifier' or 'bridge_edge_loops'.
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 beveling mesh edges but provides no explicit guidance on when to use this tool versus other bevel methods (e.g., modifier) or prerequisites. No exclusion or alternative tools 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?
The description discloses that apply=True applies the modifier and removes the cutter, but does not mention destructive nature, mesh requirements, or behavior when apply=False. Given no annotations, the transparency is moderate.
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 concise, consisting of three short sentences. It is front-loaded with the core purpose, but could be better structured with bullet points for operations.
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 has 4 parameters, no output schema, and no annotations, the description provides a basic understanding but lacks details on return values, prerequisites, and the full workflow. It is minimally sufficient.
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 0% schema description coverage, the description explains the 'operation' and 'apply' parameters, but 'target' and 'cutter' are only implied as 'two mesh objects'. This adds some meaning but not complete coverage for all four 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 the tool performs a boolean operation on mesh objects, lists the three operation types, and explains the apply behavior. It is specific and unambiguous, distinguishing it from sibling tools like 'boolean_cleanup'.
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 such as 'bmesh_operation' or 'boolean_cleanup'. The description implies usage for boolean operations but does not specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden. It states 'create' but does not disclose side effects (e.g., does it modify existing objects or create new ones?), error conditions, or what happens if no empty is selected. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 sentences) and front-loaded with the main action. Every sentence adds value, no wasted words.
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?
There is no output schema, so the description should explain what the tool returns (e.g., the array object). It also lacks context about required selections (e.g., active object) and error handling. For a 4-parameter creation tool, this is incomplete.
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 meaning for 3 of 4 parameters (count, axis, radius) beyond the schema, but omits the required 'name' parameter. With 0% schema description coverage, the description should cover all parameters, but it does not fully do so.
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 creates a circular array using an empty as pivot. It distinguishes from sibling 'create_array' (likely linear) by specifying 'circular' and the pivot mechanism.
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 parameter usage (count, axis, radius) but does not provide when-to-use or when-not-to-use guidance, nor does it reference alternatives like create_array. It lacks prerequisites (e.g., need an empty) and exclusionary 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?
Briefly describes basic behavior (create + optional parent). With no annotations, it minimally covers the action but omits details like whether it creates an empty collection or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no extraneous words. Efficiently conveys core functionality.
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 creation tool with two parameters and no output schema, the description is largely complete. Minor gap: does not mention that collections can hold objects, but that is implied by 'folder for organizing objects'.
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?
Adds meaning beyond schema by explaining 'parent' as nesting. Schema has 0% description coverage, so description partially compensates, but does not specify format for 'parent' (e.g., ID or name).
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?
Clearly states the tool creates a collection (like a folder) and mentions nesting under parent. However, it does not differentiate from the similar sibling 'scene_create_collection', which could cause confusion.
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 'list_collections' or 'move_to_collection'. Lacks any context on 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 given, so the description carries the burden. It explains behavior for extrude, bevel_depth, rotation, and alignment but omits other important aspects like whether it creates a new object in the scene or affects selection.
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?
Three efficient sentences with no wasted words, front-loaded with the main purpose.
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 no annotations or output schema, the description covers only about half of the 10 parameters. Missing details on key parameters like location, size, and font_path, and assumes basic understanding of 3D object creation.
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 meaning beyond the schema for extrude, bevel_depth, rotation, and alignment, but fails to explain name, size, location, and font_path. With 0% schema coverage, this is only partial compensation.
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 creates a 3D text object, using a specific verb and resource. It is distinct from sibling tools like create_curve or create_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 curve_create_text. The description only explains parameter options, not 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?
No annotations are provided, so the description must fully disclose behavior. It only states generation from text/image, failing to mention whether outputs are synchronous/asynchronous, any authentication requirements, or side effects. Key details like result format or required parameters are omitted.
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, front-loading the core purpose. Every word adds value, with no redundancy or filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 the complexity of 3D model generation, the description is incomplete. It does not explain the result (e.g., file path, URL), whether the process is asynchronous (sibling get_hunyuan3d_status suggests polling), or how to handle timeouts. Many details beyond the input schema remain unaddressed.
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%, but the description adds value by explaining that text_prompt accepts English/Chinese descriptions and input_image_url accepts local or remote URLs. However, it does not specify constraints like max length or file size, leaving the agent to assume basic knowledge.
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: 'Generate 3D model using Hunyuan3D from text and/or image.' It specifies the tool (Hunyuan3D) and input types, distinguishing it from sibling tools like generate_hyper3d_model_via_images (different technology) and get_hunyuan3d_status (status check).
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 models from text/image but lacks explicit guidance on when to choose this tool over alternatives like Hyper3D or how to combine inputs. No prerequisites or exclusions are stated, leaving the agent to infer usage from 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?
Discloses key behavior (merging into first object) but lacks details on whether other objects are removed, supported object types, or error conditions. Given no annotations, more completeness would be expected.
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?
Two sentences with no extraneous content, though the first sentence partially repeats the second. Still, it's efficient and 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 simple tool, the description covers basic purpose and behavior. However, without output schema or annotations, it omits details like supported object types, prerequisites, and what happens to the non-target objects. Adequate but not fully complete.
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 suggests the 'names' parameter is a list of object names and that the first is the target. However, it doesn't confirm that the strings are object names, nor does it specify required format or order, leaving ambiguity despite 0% schema 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 'Join multiple objects into one' with the specific behavior 'merged into the first one in the list.' This distinguishes it from siblings like align_objects or merge_by_distance.
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 such as boolean_operation, merge_by_distance, or separate_object. The description does not mention 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only lists parameters without disclosing side effects (e.g., overwriting existing lights), error cases, or required permissions. The tool mutates the scene, but this is not articulated beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring that is front-loaded with the main sentence. It is concise and easy to parse, though the 'Args:' section could be slightly more terse.
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 all 8 parameters but does not explain parameter dependencies or provide examples. For a tool with no output schema, it adequately documents inputs but misses higher-level context like typical use cases or constraints.
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 value by explaining each parameter (e.g., 'size: Light size (area size, point radius, spot cone)' and units for power/color). However, it lacks details on default behaviors or parameter interactions (e.g., which parameters apply to which light 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 'Add a light to the scene' with a specific verb and resource. This distinguishes it from other tools, though a sibling named 'add_light' exists but is not detailed.
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_light' or other lighting tools. No prerequisites, exclusions, 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 the full burden. It mentions optional assignment but does not specify the target object or how assignment occurs. The behavior for empty material_name ('auto if empty') is vague, and there is no information about return values or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence plus a structured parameter list. Every sentence is necessary and informative without any 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?
Given no output schema and no annotations, the description covers the basic action and parameters. However, it lacks details on assignment target, return value, and edge cases (e.g., empty material_name). The tool's output is not described, which is a gap for a create 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?
Schema coverage is 0%, so the description's parameter explanations add significant value. Each parameter is described with purpose and constraints (e.g., preset_name references, color_override range). The description compensates well for the lack of schema descriptions.
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 states 'Create a material from a preset and optionally assign it,' which clearly identifies the action and resource. It distinguishes from sibling tools like material_create_pbr, but does not elaborate on the assignment process, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by referencing 'material_list_presets' for preset names, but does not explicitly state when to use this tool versus alternatives like material_create_pbr or material_duplicate. No direct 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the main behavioral trait (makes effect permanent and removes from stack), but does not cover potential side effects, failure conditions, or required permissions. Given no annotations, this is adequate 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?
The description is two sentences, front-loaded with the action, and contains no unnecessary words. It is efficiently structured.
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 two-parameter tool with no output schema or annotations, the description provides the core behavior but misses context like parameter details, prerequisites, and error conditions.
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?
The description does not explain the parameters object_name or modifier_name beyond their schema names. With 0% schema description coverage, the tool should compensate but fails to do so.
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 (apply/finalize a modifier) and the resource (modifier on an object), distinguishing it from siblings like modifier_add or modifier_remove.
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 finalizing a specific modifier, but lacks explicit guidance on when to use this tool versus alternatives like modifier_apply_all or what prerequisites are needed.
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 lacks behavioral details such as whether the operation is atomic, handles partial failures, or has side effects beyond adding modifiers.
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. The args list is compact and no unnecessary text.
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 complexity of a batch operation with 3 parameters and no output schema or annotations, the description is too minimal. It does not explain return value, error handling, or how batch addition works.
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%. The description adds basic semantics: object_names is a list, modifier_type references modifier_add, params are overrides. However, it does not fully compensate for the empty 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 tool adds the same modifier to multiple objects at once. It distinguishes from sibling tools like modifier_add (single object) and 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 batch usage but provides no explicit when-to-use or alternatives. The sibling list includes modifier_add for single objects, but no guidance on when to choose this over other methods.
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 states the action but does not disclose important behavioral traits such as whether the simulation auto-starts, if object must be mesh, or if modifications are reversible. It provides basic parameter descriptions 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: one sentence plus a parameter list. Front-loaded with the purpose, no extraneous text. Every sentence adds value.
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 complexity of cloth simulation and no output schema, the description lacks completeness. It does not explain what the tool returns, what happens after addition (e.g., need to bake?), or prerequisites (e.g., topology requirements). For 6 parameters, 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 description coverage is 0%, so the description must compensate. The 'Args' section adds minimal meaning (e.g., quality range '1-80', 'Enable self-collision detection') but does not explain parameter interactions or units (e.g., mass units). Adequate but not rich.
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 cloth physics simulation to a mesh.' This distinguishes it from sibling tools like physics_add_rigid_body or physics_add_soft_body, providing a specific verb and resource.
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 like physics_add_soft_body or physics_add_rigid_body. There is no mention of prerequisites, constraints, or exclusion criteria.
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 full burden. It lists procedural steps but does not disclose behavioral traits such as destructiveness, idempotency, file overwrites, or required Unity environment state. This is insufficient for an agent to understand 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 three short paragraphs: overall purpose, detailed chain, and parameter list. It is front-loaded with the main idea but the chain detail slightly repeats the high-level summary.
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 explains inputs but omits output behavior (despite output schema existing) and prerequisites like Unity project state. For a complex pipeline, this leaves gaps in understanding 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?
Despite 0% schema coverage, the description provides clear one-line explanations for each parameter and notes the conditional dependency of physbones_json on setup_physbones. This adds meaningful context beyond parameter names.
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 is a Unity-side pipeline for FBX imports, avatar descriptor, expressions, and build. It distinguishes itself from sibling tools like unity_import_fbx or unity_setup_avatar_descriptor by encompassing the entire chain, and from other pipelines like pipeline_avatar_from_mesh by specifying FBX input.
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 vs. individual Unity tools or other pipeline tools. There is no mention of prerequisites, 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.
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 creating a meta-rig but does not describe side effects, required context, or what happens to existing objects. Lacks detail on consequences.
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 purpose sentence followed by a parameter list. Structure is front-loaded and easy to parse, though the parameter list could be integrated more naturally.
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 an output schema present, return values need not be explained. The description covers core functionality and parameters but omits prerequisites (e.g., addon state, mode) and does not mention typical usage context. Adequate but with gaps.
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 lists each parameter with allowed values (e.g., rig_type options) and defaults, adding meaning beyond the schema. Could be improved with format hints or constraints.
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 Rigify meta-rig, explaining it is a template for the final rig. It distinguishes from siblings like rigify_generate_rig and rigify_fit_metarig by specifying the type of rig created.
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 an implied workflow with rigify_generate_rig, but no direct comparison or when-not-to-use advice.
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 destructiveness, prerequisites (e.g., sculpt mode), side effects, or what happens to existing detail. The actions imply mesh modification, but details are lacking.
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: a brief intro followed by a bulleted list of actions. Every sentence is informative without redundancy.
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 an output schema, the description does not mention return values or what the tool outputs (e.g., for 'info' action). Prerequisites like mesh mode are omitted. With no annotations, the description should provide more context for a tool modifying mesh topology.
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 the 'action' parameter with a bulleted list of options, 'target_density' as edge length with auto-calculate behavior, and 'detail_regions' as a JSON array with structure. However, the required 'mesh_name' parameter is not described.
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: 'Adaptive detail control — add resolution where needed.' It lists specific actions (auto_detail, add_detail_sphere, etc.) which distinguish it from sibling tools like sculpt_remesh or decimate.
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 lists actions but does not explain contexts or exclusions, nor does it differentiate from siblings like sculpt_remesh or subdivide.
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 convey behavioral traits. It only states that the tool extracts a face set and has thickness for solidify. Missing details include what happens to the original mesh, whether the operation is destructive, prerequisites (e.g., in sculpt mode), and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three short sentences plus an args list. The purpose is front-loaded, every sentence adds value, and there is no redundancy.
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 annotations, no output schema, and 3 parameters with minimal schema details, the description is lacking. It omits information about the resulting object (e.g., new object name, location), selection behavior, and differentiation from similar tools like 'sculpt_extract'.
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 description compensates with an 'Args' block. It adds meaning: mesh_name is the mesh object name, face_set_id starts at 1, thickness is for solidify. However, it does not explain what a face set is or how to obtain the ID, and mesh_name lacks context (e.g., exact naming requirements).
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 first sentence clearly states the action: 'Extract a face set from a sculpted mesh as a separate object.' It also lists use cases. However, it does not explicitly differentiate from the sibling 'sculpt_extract' tool, which may have a similar purpose.
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 clear usage context: 'Useful for creating accessories, clothing pieces, or separating features from a base sculpt.' This tells when to use the tool, but it does not mention when not to use it or suggest alternatives.
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 carries full burden. It lists parameters but does not disclose critical behavioral traits like effect on mesh (e.g., permanent modification), required topology, or mode requirements.
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?
Short and to the point, with bulleted parameter list. No unnecessary fluff, though a brief behavioral note would improve completeness without adding length.
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 parameter meanings and mentions 'no stroke needed', but lacks behavioral context (e.g., what happens to mesh, return value) despite having an output schema not referenced.
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?
Adds some meaning beyond schema (e.g., strength 'can be >1.0', iterations as passes, axes selection). However, key parameter 'mesh_name' and filter_type options lack explanation of impact.
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 'Apply whole-mesh sculpt filter (no stroke needed)', specifying verb, resource, and scope. Lists filter types, distinguishing it from stroke-based siblings like sculpt_brush_stroke.
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?
Implicitly suggests use for whole-mesh effects without strokes, but no explicit comparison to alternative tools (e.g., sculpt_brush_full) or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the effect of two parameters (angle_limit controls island splitting, island_margin adds padding), but does not disclose broader behavior such as whether it creates a new UV layer, overwrites existing UVs, or requires the mesh to be in a specific mode. With no annotations, the description carries full burden, and it only 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 three sentences long, each serving a distinct purpose: stating the function, explaining a parameter, and explaining another parameter. It is front-loaded with the main purpose and efficient 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?
For a simple tool with three parameters and no output schema, the description covers the essential action and parameter effects. However, it omits information about prerequisites (e.g., object selection, mode requirements) and does not reference sibling tools or provide usage context, which leaves some gaps for an agent.
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 0% schema description coverage, the description adds meaning for angle_limit and island_margin beyond the schema defaults, explaining their roles. However, the required 'name' parameter is not described, and the description does not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Automatically UV unwrap a mesh') and the method ('using Smart UV Project'). It implies the target is a mesh via the 'name' parameter, but does not explicitly state which object is operated on. This distinguishes it from generic unwrap tools but lacks specificity on the object 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 is provided on when to use this tool vs. sibling tools like uv_unwrap, uv_smart_unwrap, or uv_project_from_view. There is no mention of prerequisites, context, or alternatives, leaving the agent to infer usage without 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 the description carries the full burden. It states only the basic operation without disclosing behavioral traits such as whether the layer must exist, if the operation is reversible, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two lines for the purpose and two for parameters. It is front-loaded and contains no superfluous 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?
For a simple tool with two required parameters and no output schema, the description covers the essential information. It could mention error conditions or prerequisites, but overall it is adequate.
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 description must compensate. It provides brief descriptions for both parameters ('Target mesh object', 'Name of the UV layer to remove'), adding meaning beyond the schema. However, it lacks details like expected formats or constraints.
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 'Remove a UV layer from an object,' specifying the verb and resource. It distinguishes from sibling tools like uv_add_layer and uv_get_info, 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 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 does not mention when not to use it or provide context beyond the basic operation, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. Fails to disclose error handling, overwrite behavior, channel indexing details, or side effects beyond structure of keyframes.
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 well-structured with purpose first, then argument details, then example. Each sentence adds value, no redundancy or fluff.
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?
Missing behavioral details like return values, error conditions, and confirmation of insertion. Given complexity and lack of output schema, description is incomplete for an agent to fully predict behavior.
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 fully defines parameters: 'object_name' as target, 'keyframes' as list of dicts with required fields and optional index. Example demonstrates structure and usage, adding essential meaning.
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 'Insert multiple keyframes at once', specifying verb and resource. Differentiates from sibling 'anim_insert_keyframe' which handles single keyframe insertion.
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 vs alternatives like 'anim_insert_keyframe'. Does not provide when-not scenarios or 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 carries full burden for behavioral disclosure. It states the tool 'creates' an animation but does not explain side effects (e.g., whether existing animation is overwritten, if keyframes are added, or if object must be selected). No details on error conditions or post-conditions.
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 followed by a clean argument list. No redundant text. Every line adds value. Ideal structure for quick comprehension.
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 has no output schema and 5 parameters. The description adequately covers the parameters and basic purpose but lacks details on return value, error handling, or post-condition effects. For a simple animation tool, this is minimally adequate 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?
Schema coverage is 0%, so the description compensates by listing all 5 parameters with brief explanations. For example, 'center: Center point [x, y, z]' and 'frames: Frames for one complete orbit' add meaning beyond the schema. However, some details are missing (e.g., default center behavior).
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: 'Create an orbital/circular motion animation.' It uses a specific verb ('Create') and resource ('orbital/circular motion animation'), distinguishing it from siblings like anim_bounce (bounce animation) and other animation 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 versus alternatives (e.g., anim_bounce, keyframe tools). No when-not or prerequisite information provided. The agent must infer usage solely from the name and description.
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 must fully disclose behavioral traits. It only describes parameters, omitting side effects (e.g., irreversible modification, selection changes), permissions, mode requirements, or return behavior. 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 concise with a clear, structured list of parameters. It front-loads the purpose and uses a single sentence per parameter. 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?
Given the simplicity of the tool (adding a bone), the description covers basic usage and parameters. However, it lacks details on return values, error handling, or prerequisites (e.g., armature in edit mode). Without output schema, these gaps are noticeable 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?
The description adds meaning beyond the input schema by explaining each parameter's purpose (e.g., head/tail positions, parent_bone, connected). Schema coverage is 0%, so the burden is fully on the description. It partially compensates but could specify formats (e.g., head/tail as [x,y,z] floats).
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 specific action 'Add a bone to an existing armature.' The verb 'add' and resource 'bone' are precise. This distinguishes it from sibling tools like 'armature_create' (creating a new armature) and 'armature_add_bones_chain' (adding a chain of bones).
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, such as 'armature_add_bones_chain' or 'armature_create'. It lacks explicit when-to-use/when-not-to-use context, prerequisites like requiring edit mode, or error 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a geometry modification (creating faces) but does not clarify if the operation is destructive, what happens to the original edge loops, or how to undo it. For a simple operation, basic transparency is achieved, but there is room for more 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 extremely concise: two sentences that cover the action and the essential prerequisite. Every sentence is meaningful and adds value. No wasted words.
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 the tool's simplicity, the description lacks information about return values or success/failure feedback. Combined with an undocumented parameter, the agent has incomplete context to use the tool effectively. Output schema is absent, so the description should at least hint at what the tool returns.
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?
The input schema has one required parameter 'name' with no description, and the tool description does not explain its purpose. Schema description coverage is 0%, so the description must compensate but fails to do so. The agent cannot infer what 'name' refers to (e.g., object name, mesh name).
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 ('Bridge'), the resource ('two selected edge loops'), and the result ('create connecting faces'). It effectively distinguishes from sibling tools like 'extrude_faces' or 'bevel_edges' by specifying the exact mesh topology operation.
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 a clear prerequisite: the object must have exactly two edge loops selected in edit mode. This tells the agent when to use the tool. However, it does not explicitly mention when not to use it or suggest alternative tools for different selection scenarios, which would be helpful.
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 disclose behavioral traits such as destructiveness (e.g., whether source shape keys are modified), permissions, or effects on existing shape keys.
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 plus argument list with no fluff. Every sentence adds value, efficiently conveying core functionality.
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. Adequately describes inputs and purpose but lacks details on behavior when output_name already exists, or return value.
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%. Description adds meaning for 'sources' parameter (JSON array with name and weight), but 'mesh_name' and 'output_name' lack additional explanation 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?
Description clearly states 'Combine multiple shape keys with weights into a new shape key,' using specific verb+resource. This distinguishes it from sibling tools like ft_mirror_shape_key or ft_sculpt_shape_key.
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 guidance. Implied usage is for combining shape keys, but no mention of prerequisites, exclusions, or alternatives like ft_create_arkit_shapes.
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 explicitly states 'WITHOUT executing it' and explains the output is a script for review or manual execution. This clearly communicates the read-only, non-destructive behavior. It lacks details on error handling or permissions, but for a non-executing script generator, the key behavior is well-disclosed.
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, no redundancy, and front-loaded key information. Every word is necessary and contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown in detail) and no annotations, the description adequately explains the return value as a script string. However, it omits details about what the script contains, how to interpret it, or potential limitations, leaving some gaps for a tool that generates code.
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 0% schema description coverage, the description adds moderate value by referencing 'JSON scene description' and directing to build_scene_from_json for format details. This gives context beyond the raw schema but does not comprehensively explain the parameter's expected structure or constraints.
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 generates a bpy Python script from a JSON scene description without executing it, using a specific verb and resource. It distinguishes from the sibling 'build_scene_from_json' by referencing it for the JSON format, but does not explicitly differentiate from other script-execution 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?
The description provides minimal usage guidance: it directs users to 'build_scene_from_json' for the JSON format, implying a workflow dependency. However, it does not specify when to use this tool versus alternatives like execute_code or execute_script_headless, nor does it offer exclusion criteria.
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 only states the basic action without explaining socket compatibility, whether existing connections are replaced, or validation checks. 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 very concise, consisting of one main sentence and a list of arguments. It front-loads the purpose and avoids any unnecessary text.
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 5 required parameters and no output schema or annotations, the description is adequate for a simple connection operation but lacks details on behavior, error handling, or return values. It could be more 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 minimal meaning beyond the input schema by listing parameter names and brief descriptions (e.g., 'source output socket index'). With 0% schema description coverage, this provides basic understanding but lacks detail like valid ranges or formats.
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 'Connect two nodes in a Geometry Nodes tree,' which is a specific verb-resource pair. It distinguishes from sibling tools like geonodes_add_node (adds a node) and geonodes_create (creates a tree).
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, nor does it provide conditions or exclusions. Usage is implied by the action of connecting nodes, but no direct guidance is given.
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. However, it only states that it retrieves categories and lists possible asset_type values. It does not describe output format, network dependencies, or potential errors, which is insufficient for a tool likely requiring external API calls.
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, consisting of one sentence and a parameter hint. Every word serves a purpose with no redundancy, making it efficient 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?
While the tool is simple, the description lacks context about what 'categories' are and what the return value looks like (e.g., a list of strings). With no output schema, the agent is left guessing the response format, which could lead to misuse.
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% coverage and no enums. The description adds critical meaning by listing the allowed values for asset_type ('hdris, textures, models, all'), which is not present in the schema. This significantly aids the agent in 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 the tool retrieves categories for a PolyHaven asset type, specifying the verb 'Get' and the resource 'categories'. It also lists the possible asset_type values, making the purpose unambiguous and distinct from sibling tools like search_polyhaven_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as search_polyhaven_assets or download_polyhaven_asset. There is no mention of prerequisites or exclusions, leaving the agent without context for decision-making.
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 the burden. It implies a read-only operation but does not explicitly state non-destructive behavior or any side effects. The return content is listed, but safety profile is not addressed.
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, front-loaded with purpose, and every word contributes to understanding. 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?
For a zero-parameter tool, the description covers the key outputs adequately. It could mention whether it includes animation data or modifiers, but the listed items are sufficient for a basic 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?
There are no parameters, so schema coverage is trivially 100%. The description adds value by explaining the comprehensive return data, including object details and scene metadata.
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 retrieves complete scene information, listing specific elements like objects, camera, render settings, frame range, and mesh details. However, it does not differentiate from sibling tools such as get_object_info or scene_stats.
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 get_object_info, get_hierarchy, or analyze_scene. It lacks context for selection 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?
The description indicates a read-only check of integration status, which is transparent enough. However, with no annotations, it could further clarify what 'enabled' means or any conditions (e.g., internet required). 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise and front-loaded. The second sentence, 'Sketchfab has a wide variety of realistic downloadable 3D models,' is irrelevant to the tool's function as a status check and adds no value for selection or invocation.
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 status check with no parameters and no output schema, the description covers the basic purpose. However, it does not specify the return value (e.g., boolean or status string), which would improve completeness for an 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?
The input schema has zero parameters with 100% description coverage, so the description is not burdened to explain parameters. It adds context that the tool checks integration status, which is appropriate.
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 Sketchfab integration is enabled in Blender,' specifying a verb ('Check') and a distinct resource (Sketchfab integration). This differentiates it from sibling tools like download_sketchfab_model, 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 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, such as other status-check tools (e.g., get_hunyuan3d_status) or related Sketchfab tools. There is no mention of prerequisites or typical usage scenarios.
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 full burden. It states it sets up three lights but does not disclose whether it creates new lights, auto-positions them at specific angles, modifies existing lights, or any side effects. It lacks detail on the resulting light configuration and potential scene modifications.
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 one-line summary, then a brief purpose statement, followed by a clean 'Args' section. Every sentence is informative and there is no extraneous text.
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 relatively simple, but the description lacks details such as whether it creates new lights or modifies existing ones, default light positions, and what happens if lights already exist. With no output schema and no annotations, an agent might need additional context to use it correctly. However, it provides enough to understand the basic function.
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 for parameters. The description's 'Args' section adds meaning: clarifies 'target_location' as center point, identifies which power corresponds to which light, and explains 'distance' as distance from target. This goes beyond the schema's bare property 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 clearly states the tool sets up classic three-point lighting (key, fill, rim/back) for product shots and character renders. It uses a specific verb 'set up' and resource 'lighting', and distinguishes from sibling tools like 'light_add' and 'light_setup_studio' by specifying the classic three-point 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?
The description mentions it is for 'professional lighting setup for product shots and character renders' but does not explicitly provide when to use this tool versus alternatives like 'light_setup_studio' or 'light_add'. There is no guidance on when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not explicitly state that this is a read-only operation. It fails to disclose what 'objects' includes (e.g., mesh names or object counts) or how the tree structure is represented. No side effects or limitations are mentioned.
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 with no wasted words. It is front-loaded and 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 no output schema, the description only partially compensates. It explains the output is a tree of collections with objects, but lacks specifics on the structure, object types, or whether empty collections are included. This is adequate but not fully 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?
There are zero parameters, so the schema coverage is 100%. With no params, baseline is 4. The description does not need to add parameter details, and it does not introduce ambiguity.
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 'list' and the resource 'collections', and distinguishes it from siblings like create_collection by using 'list'. It specifies 'all collections in the scene' and 'as a tree with their objects', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives like list_materials or get_hierarchy. The description only implies its use for listing collections, but does not exclude scenarios or mention siblings.
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 full burden. It mentions 'Duplicate' and the new_name parameter behavior, but fails to disclose important traits like what happens if material_name doesn't exist, conflict handling, or side effects like memory usage.
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 an Args list. It is front-loaded and contains no superfluous text.
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 simplicity of the tool and lack of output schema, the description covers the basics. However, it omits error cases, auto-naming details, and return value, which could be helpful for an AI agent.
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 meaning beyond schema titles with 'Source material name' and 'Name for the copy (auto if empty)'. Since schema description coverage is 0%, this compensation is adequate but not exceptional.
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 existing material.' This is a specific verb+resource combo that immediately distinguishes it from sibling tools like material_assign or material_create_pbr.
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 (when you need a copy of a material) but provides no explicit guidance on when not to use or alternatives. For a straightforward duplicate operation, this is adequate but lacks depth.
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?
The description lacks behavioral details beyond the basic operation. It does not disclose whether the tool modifies anything, what it returns (e.g., boolean or report), or any required state of objects (e.g., selection). Since no annotations are provided, the description carries the full burden and falls short.
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 lines for purpose and two lines for parameter descriptions, containing no redundant text. It is front-loaded and efficiently communicates the core 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?
The description covers the basic purpose and parameter meanings, but lacks information about the return value (e.g., boolean true/false or detailed report) and any prerequisites. Given the tool's simplicity and absence of output schema, it is minimally adequate but could be improved.
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 input schema: it clarifies that 'objects' are names and restricts 'axis' to X, Y, or Z values, which the schema does not specify. With 0% schema 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 the tool's purpose with a specific verb 'Check' and resource 'alignment of multiple objects along an axis', distinguishing it from sibling measurement tools like measure_distance or measure_overlap.
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 is provided. The description does not mention prerequisites, limitations, or compare with similar tools such as measure_symmetry or measure_dimensions.
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 partially discloses behavior by stating the tool returns overlap status, volume, and dimensions. However, it omits details about side effects (e.g., selection changes), required object properties (e.g., must be mesh objects), and the exact calculation method.
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 stating purpose and a second listing returns. Every word earns its place, with the key action front-loaded. No unnecessary fluff.
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 (2 string params, no output schema), the description covers the main purpose and outputs fairly well. However, it lacks clarity on parameter input format and does not explain what 'overlap' entails (e.g., partial vs full), which would improve completeness.
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 input schema has 0% description coverage, and the tool description adds no extra meaning beyond the parameter titles ('Object A', 'Object B'). It does not clarify whether these are object names, IDs, or how to refer to them, leaving ambiguity for the 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?
The description clearly states the tool checks bounding box overlap between two objects and lists the return values. It specifies a specific verb ('Check') and resource ('objects' bounding boxes'), distinguishing it from sibling measurement tools like measure_distance or measure_dimensions.
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 such as measure_distance or measure_alignment. It does not specify prerequisites, expected object types, or any context like whether objects must be selected or what input format is accepted.
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 a key behavioral trait: automatic .001 suffix when the name already exists. Since no annotations are provided, this is valuable transparency. However, it does not mention other behaviors like error cases or scope (e.g., scene-level rename).
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 extremely concise with two sentences, front-loading the purpose. Every sentence adds value, but the lack of parameter details slightly reduces effectiveness. It earns a high score for brevity without waste.
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 and no output schema, the description is adequate but incomplete. It covers the basic rename operation and one behavioral nuance, but lacks guidance on prerequisites, error handling, and parameter specifics. There are clear gaps.
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 input schema has 0% description coverage, yet the description adds no parameter-level semantics. It does not explain what 'name' and 'new_name' refer to, leaving ambiguity for the agent. This is a significant gap.
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') and the resource ('object'), making the tool's purpose immediately understandable. It distinguishes from siblings as no other rename object tool exists in the list.
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 usage guidelines are provided. The description does not indicate when to use this tool over alternatives, nor does it include any before/after conditions or prerequisites for 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 are provided, so the description must fully disclose behavioral traits. It fails to mention side effects, error handling, or what happens if the object does not exist. The description only states the basic function without deeper context.
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 purpose. Every sentence serves a purpose, and the docstring format is well-structured.
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 lack of annotations and output schema, the description is minimal but adequate for a simple tool. It covers the main function and parameter meanings, but fails to provide error handling, performance notes, or interaction with other scene state.
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 description adds some value by explaining each parameter (e.g., 'Show in viewport'). However, it mostly paraphrases the parameter titles and lacks additional detail like allowed values 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 tool's function: 'Set object visibility in viewport and render.' It specifies the resource (object) and the action (set visibility), and distinguishes from sibling tools like set_collection_visibility and set_visibility which operate at different levels.
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. It lacks prerequisites or exclusions, but the parameter list implies usage for controlling visibility and selectability.
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 discloses expected outputs but does not mention behavioral traits like being read-only, performance impact, or authorization needs. Since no annotations exist, the description only partially fills the transparency 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 two sentences, front-loaded with purpose, and efficiently lists key returns without redundancy. Every sentence contributes 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?
For a parameter-less tool with no output schema, the description covers the primary outputs comprehensively. However, it could specify the structure of returned data (e.g., JSON format) and confirm no side effects.
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 zero parameters, so the schema coverage is effectively 100%. The description adds no parameter info, but with no parameters, baseline 4 is appropriate.
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 collects comprehensive scene statistics and enumerates what is returned (object counts, vertices, etc.). While specific, it does not differentiate from sibling tools like 'analyze_scene' or 'get_scene_info', which may overlap.
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 such as 'analyze_scene' or 'get_hierarchy'. The description merely lists outputs without contextual advice.
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 states it returns analysis but does not mention whether it modifies the mesh, performance impact, or prerequisites (e.g., object mode). This is insufficient for a tool that may be read-only or destructive.
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: a one-line purpose followed by a bulleted list of analysis types. Every sentence is informative 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?
With an output schema present, return values are covered. However, the description lacks behavioral context (e.g., mesh must exist, no mode requirement) and does not address what happens if the mesh name is invalid. It is adequate but has gaps.
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 description must compensate. It lists the analysis_type options with brief explanations, adding value beyond the schema. However, it does not explain mesh_name beyond its type, leaving some ambiguity.
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 'Analyze mesh surface for sculpting decisions' with a specific verb and resource. It lists distinct analysis types, distinguishing it from sibling sculpt tools like sculpt_brush_stroke or sculpt_remesh.
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 pre-sculpting analysis but lacks explicit when-to-use, when-not-to-use, or comparisons to alternatives like mesh_quality_check. It provides context via analysis types but no 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?
Discloses that DYNTOPO is 'sculpt-mode only,' which is a behavioral constraint. However, does not mention if operation is destructive, whether original mesh is modified, or if there are prerequisites like being in a specific mode.
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: one opening sentence and a bullet-like parameter list. No filler 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?
Provides sufficient detail for a single-purpose tool with four parameters: covers all parameters and method semantics. Lacks some contextual info like return behavior or computational cost, but is largely complete for the agent to invoke correctly.
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 meaning by explaining each parameter: mesh_name as 'Name of the mesh object,' method choices with context, and size parameters with effect notes (e.g., 'smaller = more detail'). This goes beyond the schema's bare 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?
States 'Remesh a sculpt for uniform topology,' clearly indicating the verb and resource. However, there is a sibling tool named 'remesh' without explicit differentiation, so purpose is clear but doesn't distinguish from sibling.
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 'remesh', 'decimate', or 'retopology'. Only describes the two methods (VOXEL/DYNTOPO) but doesn't provide context for selection.
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 bears the full burden of disclosure. It correctly states the primary behavior (setting viewport and render visibility) and scope (collection and objects). However, it does not disclose any side effects, reversibility, or permission requirements, leading to a moderate transparency score.
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, 13-word sentence that conveys the essential function without any unnecessary words. It is front-loaded and 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?
For a simple parameter setter, the description is nearly complete. It covers the tool's purpose, the two visibility flags, and the scope. The only gap is the lack of clarification when to use this over set_visibility, but the explicit mention of 'collection and all its objects' partially addresses this.
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%, yet the description adds only a high-level mapping between 'viewport and render visibility' and the two boolean parameters. It does not explicitly link 'visible' to viewport visibility nor explain the parameters individually. The default values are in the schema but not discussed.
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 specifies the action (Set), the resource (collection and all its objects), and the two visibility types (viewport and render). This clearly distinguishes it from sibling tools like set_visibility (which likely operates on individual objects) and scene_set_visibility (scene-level).
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 does not mention prerequisites, when not to use, or provide comparisons to similar tools such as set_visibility or scene_set_visibility. Usage is implied but not directed.
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 that it undoes the last operation, but does not mention side effects, requirement of a saved state, or behavior when there is nothing to undo.
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 that is concise and front-loaded with the action and context. It contains 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 the simplicity of the tool and no output schema, the description is minimally complete. However, it could be improved by mentioning the behavior when there is no operation to undo or any repercussions.
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, so the schema coverage is 100%. The description adds meaning by specifying what operation is undone ('the last operation'), which is sufficient for a parameterless tool.
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 as undoing the last operation in Blender. It uses a specific verb ('Undo') and resource ('the last operation'), and it distinguishes itself from the sibling tool 'redo'.
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 'redo' or other operations. It does not mention prerequisites, limitations, or context 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?
No annotations are provided, so the description carries full burden. It lists operations but does not disclose irreversible changes, destructive nature, or side effects like loss of shape keys or modifiers. This is insufficient for a fix 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 concise: two short sentences plus a parameter list. It front-loads the purpose and actions, with 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 complexity (6 parameters, no annotations, many siblings), the description covers basic operations but omits usage guidance, output details, and safety information. It leaves gaps for an AI agent.
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 0% schema description coverage, the description adds basic parameter explanations and defaults. However, it lacks deeper semantics (e.g., what 'apply_transforms' does to objects or vertices). Adequate but not thorough.
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: 'One-click model fix for VRChat (similar to CATS "Fix Model")' and lists specific actions. This distinguishes it from sibling tools like vrc_validate or vrc_decimate.
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 before export but does not explicitly state when to use vs alternatives. No exclusions or prerequisites are mentioned, leaving the agent to infer 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, and the description only mentions output format (JSON), lacking details on side effects, permissions, or other runtime behaviors.
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 clear and front-loaded with purpose, then lists parameters with examples, though there is slight redundancy between the first two sentences.
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 an output schema (not shown), the description does not explain the structure of the returned JSON, which is critical for a tool generating complex blueprints.
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 compensates with detailed examples showing the expected JSON structure for each parameter, adding meaning beyond the type/empty default in 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?
Clearly states it generates a VRChat FX Animator Controller blueprint as JSON, distinguishing it from sibling tools like unity_create_animator which likely create actual Unity animator assets.
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 usage by mentioning the output can be imported into Unity or used as a reference, but does not explicitly state when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only states that blend shapes are created and bones optionally created, but omits important details like whether existing blend shapes are overwritten, required mesh structure, or any side effects (e.g., modifying the armature). The agent lacks insight into the tool's operational 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 very concise: two short sentences for the purpose and two bullet points for parameters. It front-loads the core function and efficiently explains parameters 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 basic functionality but lacks mention of prerequisites (e.g., required mesh type, selection state), expected output (though an output schema exists), and error handling. For a setup tool, more contextual guidance 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?
The description adds meaning beyond the input schema by explaining that mesh_name auto-detects when empty and that create_bones creates missing bones by default. This clarifies usage intent, though it could detail the auto-detection logic or what constitutes 'missing' bones.
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: 'Set up VRChat eye tracking: creates eye tracking blend shapes and optionally eye bones.' It specifies the verb (set up, creates) and resource (eye tracking blend shapes, eye bones), distinguishing it from sibling tools like ft_setup_eye_tracking_full which may have a broader scope.
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 such as ft_setup_eye_tracking_full or other eye-related setup tools. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It states the tool reports metrics and rank but does not explicitly confirm it is a read-only operation with no side effects. Behavioral details like whether it modifies data or requires specific permissions are omitted.
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 (64 words) and well-structured: a clear opening sentence followed by a bullet-like list of reported metrics and a separate parameter section. No redundant 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?
Given the tool has an output schema (not shown), the description does not need to detail return values. It covers the main purpose, metrics, and parameter usage. Slightly missing context about the rating scale or application to VRChat models, but still adequate.
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 coverage at 0%, the description compensates by explaining the purpose of both parameters: 'target' with allowed values 'pc' or 'quest' and default, and 'object_name' with behavior when empty. This adds meaningful context 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 validates a model against VRChat performance rank limits and lists the specific metrics reported (polygon count, bone count, material count, mesh count, rank). This distinguishes it from sibling tools like vrc_check_export_ready which may have different scopes.
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 is provided on when to use this tool versus alternatives (e.g., vrc_check_export_ready, vrc_fix_model). The description does not specify prerequisites, limitations, or typical use cases, leaving the agent to infer.
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 bears full burden. It lists return values (statistics and issues) but does not disclose potential side effects, performance implications for large scenes, or scope limitations (e.g., hidden objects). The read-only nature is inferred but not stated.
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 (two sentences) and front-loads the purpose. However, the list of returned items could be more structured (e.g., bullet points) but is still clear and 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 no output schema, the description adequately lists return values. However, it lacks details on scope (e.g., whether it considers hidden objects, modifiers, or only active collections) and does not mention performance considerations for complex scenes.
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 input parameters exist, so the description cannot add parameter semantics. Baseline 4 applies as no additional param info is needed.
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 ('Analyze') and resource ('the entire scene') and lists specific returned statistics (vertex counts, object types, issues). It clearly distinguishes from sibling tools like 'scene_stats' or 'mesh_quality_check' by offering comprehensive analysis.
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 (e.g., 'scene_stats', 'get_scene_info', 'mesh_quality_check'). The description implies comprehensive analysis but does not state when simpler tools are sufficient or when this is preferred.
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, and description does not disclose whether the operation is read-only, what happens on missing animation data, or potential 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?
Concise at two sentences plus parameter info, front-loaded with purpose, but parameter explanation could be more structured.
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 low complexity and no output schema, description covers purpose and parameter but lacks return value information and error handling details.
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 description adds meaning beyond the schema by explaining that empty object_name yields a scene-wide summary, which is not in 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 retrieves animation info (keyframe counts, frame range, actions) and distinguishes itself from siblings which are mostly modification 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?
No explicit guidance on when to use this tool versus alternatives, but the purpose is clear enough for a read-only info tool among many anim-modifying siblings.
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. It states the transform reset action but does not disclose potential side effects (e.g., whether it is destructive or reversible), required permissions, or behavior on locked/protected objects. The description is 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 extremely concise: two sentences with no fluff. The first sentence defines the action, the second provides context. Every word adds value, making it easy to parse quickly.
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 (4 params, only 1 required), the description covers the purpose and usage context. However, it falls short by not addressing parameter meanings or behavioral edge cases (e.g., what if the object has constraints?). Completeness is adequate but not thorough.
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%, so the description must compensate by explaining parameters. It mentions nothing about the 'name' parameter or the boolean flags (scale, location, rotation). The agent is left to infer from parameter names and defaults, which is insufficient for correct invocation.
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: 'Apply (freeze) the object's transforms, resetting them to identity.' It distinguishes from sibling tools like 'apply_modifier' by specifying it operates on transforms, not modifiers. The context of when it's essential (before export, after non-uniform scaling) further clarifies its unique role.
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 use cases: 'Essential before export or after non-uniform scaling.' This guides the agent on appropriate contexts. However, it does not specify when not to use the tool or mention alternative tools, which would be helpful for differentiation.
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 full burden. It discloses rotation units (degrees) and provides an example, but does not indicate whether poses are added or overwritten, if armature must be in pose mode, or any side effects. This leaves significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using one sentence and a brief args section. It is front-loaded with the verb. However, the args section uses a docstring format that could be slightly streamlined, but overall 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?
Given no output schema and no annotations, the description covers the main purpose and parameter format, but lacks return value description, error handling, and prerequisites (e.g., armature must exist). It is adequate but not fully 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 coverage is 0%, but the description adds substantial meaning: it documents the structure of bone_poses as a list of dicts with 'bone', 'rotation', 'location', and includes an example. It compensates well for the schema's lack of parameter 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 tool sets bone poses (rotation/location) on an armature, using specific verbs and resources. It distinguishes well from siblings like armature_add_bone or armature_list_bones.
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 posing bones, but lacks explicit guidance on when to use this tool versus alternatives (e.g., when to use armature_add_bone vs this). No when-not-to-use or prerequisite information 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 are provided, so the description must disclose behavioral traits. It does not mention whether the tool is destructive, requires UVs, or side effects like overwriting files. The term 'simplified' is vague without concrete behavior 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 extremely concise with two sentences plus a parameter list, all front-loaded with the main purpose. Every sentence adds value with no waste.
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 conciseness, the description lacks essential context: prerequisites (e.g., UV unwrapping), output details (file format, location), and whether the tool is safe to re-run. For a baking tool, this information is crucial for correct 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 description coverage is 0%, but the description provides brief explanations for all 4 parameters, adding meaning beyond defaults and types. For example, 'samples: Render samples (higher = cleaner)' clarifies the parameter's effect, and output_path behavior is noted.
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 bakes an ambient occlusion map for a mesh, using specific verb and resource. It distinguishes from sibling tools like bake_normal_map or bake_textures by specifying 'ambient occlusion' and 'simplified single-map bake.'
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 like bake_normal_map. The phrase 'simplified single-map bake' implies a simpler workflow but lacks clear guidance on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It does not disclose whether the tool creates a new object or modifies existing geometry, nor any required modes or selection. The behavioral details are minimal beyond the name.
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 first sentence stating the core purpose, a brief importance note, and a structured parameter breakdown. Every sentence adds value and is well-organized for agent comprehension.
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 purpose, importance, and parameter details well. However, it lacks information about prerequisites (e.g., whether an object must be selected or if edit mode is required) and does not explain what the tool returns (though an output schema exists). For a creation tool, some behavioral context is missing.
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 and all parameters are strings with defaults. The tool description provides detailed meaning for each parameter: 'feature' lists three options with descriptions, 'params' gives explicit JSON structures for eye and mouth, and 'location' indicates it's a JSON center position. This adds essential context missing 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 clearly states the verb ('create') and resource ('facial topology with concentric edge loops'). It also explains why it's important ('critical for blend shape deformation'), which adds context. This distinguishes it from sibling tools like 'topology_edge_loops' that might create generic edge loops.
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 explicitly state when to use this tool versus alternatives. It hints at use for blend shape deformation, but there is no guidance on when not to use it or comparison with other face topology tools like 'ft_setup_face_vertex_groups' or 'topology_edge_loops'.
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 side effects, creation behavior (e.g., whether it modifies existing objects or only creates new ones), or any required permissions. It only describes parameters.
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 main purpose and then lists parameters in a clear, structured Args format. Each parameter is briefly described without unnecessary words, though the block format could be more concise.
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 complexity (8 parameters, no required, no output schema, no annotations), the description covers parameters adequately but fails to explain return values, side effects, or selection state after creation. This leaves gaps for an AI agent to fully understand tool 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?
The description adds significant meaning beyond the schema: it explains the structure of 'points' with a detailed format and default S-curve behavior, and lists enum options for fill_mode. This compensates for the 0% schema description coverage indicated in 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 explicitly states 'Create a Bezier curve with custom control points', clearly identifying the verb (create) and resource (Bezier curve). It distinguishes from sibling tools like curve_create_circle and curve_create_nurbs by specifying the curve type.
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 custom Bezier curves but does not explicitly state when to use this tool versus alternatives like NURBS or path curves. No exclusions or prerequisites 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 are provided, so the description must carry the burden. It states the core behavior (flip all face normals) but omits details such as whether it is destructive, requires a specific mode, or works on multiple objects. The description is minimally adequate.
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 a single sentence, very concise and to the point. While it could be improved by including parameter details, it efficiently conveys the core purpose and use case without extraneous text.
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 single required parameter and no output schema, the description lacks completeness. It does not specify what the 'name' parameter expects, nor does it cover error conditions, applicability to selections, or other behavioral nuances needed for a fully self-contained description.
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?
With only one parameter ('name') and 0% schema description coverage, the description does not explain what 'name' refers to. It says 'Flip all face normals of a mesh,' but does not clarify if 'name' is the object name, mesh name, or something else. This omission hinders proper parameter 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 the action ('Flip all face normals') and the resource ('a mesh'), along with a specific use case ('when faces appear inside-out'). It distinguishes itself from other mesh-related siblings by its unique operation.
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 a clear usage context ('useful when faces appear inside-out'), implying when to use it. However, it does not explicitly mention when not to use or provide alternatives, which would be beneficial.
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 describe behavior. It only covers input constraints (local vs remote, optional bbox_condition) but omits crucial traits: whether the operation is synchronous, what it returns (job ID, model object?), required permissions, or side effects. This leaves significant behavioral uncertainty for the agent.
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 three sentences, each adding essential info: purpose, input rule, optional parameter. No fluff. Front-loaded with the core action.
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 absence of an output schema and annotations, the description should explain the return value or result handling. It doesn't. For a generation tool with three parameters, it omits important context about the generated model's lifecycle (e.g., where it's stored, how to access it). The description is incomplete.
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 description must add meaning. It does explain that input_image_paths are for local files, input_image_urls for remote URLs, and bbox_condition is an optional [L,W,H] ratio. This clarifies the form but lacks details like file format constraints or size limits, so only modest 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 description clearly states 'Generate 3D model from images using Hyper3D Rodin', specifying the verb (generate), resource (3D model), and method (from images). It distinguishes from sibling tools like generate_hyper3d_model_via_text and generate_hunyuan3d_model by focusing on image 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?
The description explicitly instructs to provide either input_image_paths or input_image_urls, not both, giving clear input selection guidance. However, it does not explicitly mention when to avoid this tool or contrast with alternatives like generate_hunyuan3d_model, so it lacks full when-not 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?
The description explains behavioral aspects: it returns a file path, uses OpenGL for speed, and is for visual verification. With no annotations provided, it carries the full burden but does not mention potential limitations (e.g., viewport must be active) or read-only nature explicitly. It is sufficient 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 three concise sentences, front-loaded with the main action. Each sentence adds distinct value: action, output, and use case. 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?
The description covers the core purpose, output, and a use case, but misses explaining the only parameter (max_size). Given no output schema, it partially fills gaps but lacks completeness for a tool with one undocumented parameter.
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?
The input schema has one parameter (max_size) with 0% description coverage. The description does not explain its meaning or effect, leaving the agent to guess that it controls the maximum dimension or file size. This is a critical gap for a simple tool.
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 of the 3D viewport'), the output ('Returns the file path'), and the method ('Uses OpenGL render for speed'). It distinguishes the tool from siblings, as no other sibling tool explicitly captures viewport screenshots.
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 context by stating 'Useful for visual verification of scene state,' which implies a use case. However, it does not explicitly differentiate from similar tools like render_still or render_image, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It only lists parameters without explaining side effects, permissions, or whether the export is destructive. The description is minimal and does not disclose 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one for purpose and one block listing parameters. No wasted words, front-loaded with purpose, and 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?
For a simple export tool with no output schema, the description covers the basics: output format, file path, and toggles for selection, materials, and animation. It could mention that it exports the current scene by default or any output behavior details, but it is mostly 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%, meaning the parameters have no descriptions in the schema. The description adds one-line explanations for each parameter (e.g., 'filepath: Output .usd/.usdc path', 'selected_only: Export only selected'), which adds meaning beyond the schema's empty property 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 tool exports to USD/USDC format (Pixar Universal Scene Description). This is a specific verb and resource, and it distinguishes from sibling export tools like io_export_fbx, io_export_gltf, etc.
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. No mention of prerequisites, scene state requirements, or scenarios where this export is preferred.
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 implies read-only behavior ('List'), but does not explicitly state it has no side effects or describe the format of the output. The description is sufficient for a simple query but lacks explicit safety assurance.
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?
A single, front-loaded sentence that is concise and contains no filler. Every word serves a 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 parameters, no output schema, and a simple list operation, the description is nearly complete. It could mention that the output includes light names and property details, but the current wording is adequate.
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?
No parameters exist, and schema description coverage is 100% (empty). The description does not add parameter details, which is acceptable per the baseline rule for high 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 uses a specific verb 'List' and resource 'all lights in the scene with their properties', clearly distinguishing from sibling tools like light_add or light_modify which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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., light_add, light_modify). No context on prerequisites or post-conditions.
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 the action and parameters, omitting side effects, undo behavior, or whether modifications are immediate. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one sentence plus bullet list. Purpose is front-loaded. The bullet list is informal but effective for listing parameters.
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; description does not mention return value or prerequisites like light existence. Covers parameter meanings but lacks behavioral and result 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?
Schema coverage is 0%, but the description adds brief explanations for each parameter (e.g., 'New power value', 'New [r, g, b] color'), significantly improving understanding despite not being exhaustive.
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 'Modify' and the resource 'existing light's properties', distinguishing it from siblings like 'light_add' (adds lights) and 'light_list' (lists lights).
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?
Usage is implied (modify existing lights) but no explicit guidance on when to use this tool vs. alternatives, nor prerequisites like requiring a valid light name.
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 full burden. It only states that vertices are merged based on distance, but does not disclose whether the operation is destructive, how it affects UVs/normals, or that it modifies the mesh in-place. The description lacks sufficient detail for an agent to understand 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two front-loaded sentences. 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.
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 is somewhat adequate but missing key context like the requirement that the target must be a mesh object and the exact meaning of threshold (e.g., world units). It provides a use case but not complete operational context.
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 compensate. It only mentions 'threshold distance' without explaining that 'name' likely refers to the mesh object or clarifying the threshold's unit/range. The parameter 'name' is not described at all.
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 'Merge vertices that are closer than the threshold distance', specifying the verb (merge), resource (vertices), and condition (closer than threshold). It also distinguishes from siblings like boolean_operation by noting it is useful for cleanup after boolean operations.
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 when to use the tool: 'for cleaning up duplicate vertices after boolean operations'. This provides context, though it does not explicitly state when not to use or list alternative tools.
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 transparency burden. It discloses the three actions (subdivision, smooth shading, weighted normal) but does not mention side effects, object type restrictions, or whether modifiers are added or applied. 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?
Two sentences, front-loaded with purpose, no superfluous words. Highly concise and structured.
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 low complexity and no output schema, the description covers the main function but lacks parameter explanation and usage context. Complete enough for basic understanding but not fully comprehensive.
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 has 0% description coverage, and the description fails to explain the 'subdiv_levels' parameter or clarify 'object_name' usage. The description adds no meaning beyond the schema field 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 it applies a smooth shading preset combining subdivision surface, smooth shading, and weighted normals. It distinguishes from siblings like 'shade_smooth' (only smooth shading) and 'modifier_add' (individual modifiers).
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 use for 'one-click polish for any mesh' but does not specify when not to use this preset versus applying modifiers individually. Lacks explicit exclusions or alternatives among 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 provided. The description lacks behavioral context such as whether rendering is synchronous, file overwrite behavior, or error handling. It adds minimal insight beyond the parameter list.
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 5 lines. The docstring format for parameters is efficient. No extraneous content.
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 no output schema or annotations, the description covers essential param semantics but omits output details, side effects, and error cases. Adequate for a straightforward tool 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?
Schema coverage is 0% but description explains each parameter: filepath uses # for frame numbers, frame_start/end defaults are scene defaults, file_format overrides. 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 'Render an animation sequence' clearly identifies the action and resource. It distinguishes from sibling tools like render_image and render_still, which handle single frames.
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 animations but does not explicitly specify when to use this tool versus alternatives like render_still, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as side effects (e.g., modifications are irreversible), required permissions, or mode prerequisites. For a tool that modifies armatures, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear list of operations and their parameters. While it is somewhat lengthy, every part adds necessary information; however, the initial sentence could be more 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?
Given the tool's complexity and the presence of an output schema, the description covers each operation's required parameters, though it omits any mention of return values or error conditions. It is complete enough for an agent to invoke with correct sub-params.
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 by detailing each operation value and its required sub-parameters (e.g., 'add_ik' needs bone, target_bone, chain_length, pole_bone). Schema coverage is 0%, so the description fully compensates, enabling correct parameter construction.
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 'Advanced rigging operations for animation-ready armatures' and enumerates specific operations (add_ik, add_fk_ik_switch, etc.), making the tool's purpose unambiguous and distinct from sibling tools like rigify_* or armature_*.
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 sibling tools (e.g., rigify_configure_ik, armature_add_constraint). The description lacks explicit context for appropriate usage or when to avoid 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 are provided, so the description carries the full burden. It lists actions but does not disclose side effects, requirements (e.g., specific mode), or behavior of each action in detail. The invert parameter is noted but lacking context on interaction with other actions.
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 front-loaded sentence. The Args section is structured but could be more succinct as plain text. Overall, every part 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?
Given no annotations and no output schema, the description adequately covers parameters but lacks information on mode requirements, return values, error handling, or interaction with other mask tools. It is adequate but leaves gaps for an agent without additional 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?
Schema coverage is 0%, so the description adds significant value by explaining each parameter: mesh_name, action with enumerated list, vertex_group condition, and invert. However, not all actions are fully explained (e.g., difference between smooth and sharpen).
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 'Manage sculpt masks on a mesh', which is a specific verb-resource pair. It distinguishes from sibling tools like 'sculpt_mask_advanced' by focusing on basic mask actions such as clear, invert, smooth, etc.
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 available actions but does not provide guidance on when to use this tool versus alternatives like 'sculpt_mask_advanced' or other sculpt tools. There is no mention of prerequisites (e.g., sculpt mode) 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 full burden of behavioral disclosure. It lists actions and their parameters but does not describe side effects, performance implications, or whether operations are destructive.
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 with a clear list of actions and a mapping to parameters. It is somewhat lengthy but front-loaded with the purpose, and the structure aids readability.
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 complexity of the tool, the description covers actions and their parameters but lacks information on output, error handling, prerequisites (e.g., existence of mask data), and the order of operations. An output schema exists but is not referenced.
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 significant meaning beyond the input schema by explaining each action and providing example JSON structures for the 'params' parameter. The schema only defines types with no descriptions, so the description compensates effectively.
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 is for 'Advanced sculpt masking operations' and enumerates specific actions like 'by_cavity', 'by_convex', etc., distinguishing it from simpler tools like 'sculpt_mask'.
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 actions but does not provide guidance on when to use this tool versus alternatives like 'sculpt_mask' or other sculpt tools. Usage context is implied by the action list but not explicitly stated.
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 convey behavioral traits. It describes actions but does not disclose side effects, destructiveness, required permissions, or scene modifications. For a tool that adds image planes, this omission significantly hinders 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with action items and parameter explanations, front-loading the purpose. It is concise but could be slightly more compact by grouping related info. Overall 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 the tool has 5 parameters and an output schema, the description covers actions and parameter basics. However, it lacks prerequisites (e.g., need an active mesh? sculpt mode?) and does not clarify which parameters apply to which actions. The output schema exists but is not referenced, so completeness is moderate.
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 (action, view, image_path, size, opacity) with acceptable detail, including value constraints for view and opacity. This adds meaning beyond the bare schema 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 'Manage reference images for sculpting' and enumerates four specific actions (create_turnaround, add_image_plane, setup_camera_ref, list). This clearly distinguishes it from sibling tools, as no other tool focuses on reference 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 lists actions but provides no explicit guidance on when to use each or alternatives. The context of sculpting implies use for reference setup, but without clear decision criteria or exclusions, it's merely adequate.
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 outlines each action's purpose but does not disclose important behavioral traits such as whether actions are destructive, prerequisites (e.g., sculpt mode required), or side effects (e.g., enable_mirror toggles mirror mode). With no annotations, this information is missing.
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, using a bullet-like structure to list actions and parameters without extraneous text. Every sentence adds value, and the format aids quick scanning.
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 has 5 parameters and no annotations, the description explains most parameters and actions but omits the required 'mesh_name' parameter description and contextual cues like mode requirements. The presence of an output schema reduces the need to explain return values, but completeness is still moderate.
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 provides clear explanations for 'action', 'axis', 'direction', and 'merge_threshold', adding value beyond the bare schema. However, 'mesh_name' is required but not described, leaving a gap.
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 'Symmetry operations for sculpting' and enumerates four distinct actions, making the purpose specific and well-defined. However, it does not differentiate from the sibling tool 'measure_symmetry', which could also perform symmetry analysis.
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 action names imply when to use each (e.g., 'symmetrize' for mirroring, 'check' for analysis), but there is no explicit guidance on when to prefer this tool over alternatives like 'measure_symmetry' 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.
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 parameter ranges (e.g., 0-1 for colors, 0=dielectric, 1=metal for metallic) but does not disclose side effects like whether it replaces the entire material or just modifies properties, or if it creates a new material when none exists.
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 two sentences: a clear purpose statement followed by a parameter list. It is front-loaded and concise, though the parameter list is a bit run-on and could benefit from bullet points or clearer separation.
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 14 parameters and no annotations or output schema, the description explains the most critical parameters but omits details on ior, specular, clearcoat, subsurface, alpha, sheen, and the required 'name' parameter. It covers enough for basic use but is 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 description adds significant meaning to key parameters: base_color (RGB[A] 0-1), metallic (0/1), roughness (0-1 mirror/diffuse), transmission (0 opaque/1 glass), and emission_color/strength. However, parameters like ior, specular, clearcoat, subsurface, alpha, and sheen are not explained.
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 PBR material properties on an object using Principled BSDF.' It specifies the verb 'Set' and the resource 'PBR material properties on an object', and distinguishes it from siblings like 'set_principled_bsdf' or 'material_create_pbr' by focusing on setting multiple material parameters in one call.
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 such as 'set_principled_bsdf', 'material_create_pbr', or 'material_assign'. It does not specify prerequisites (e.g., object must have a material already) or scenarios where this tool is preferred.
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 discloses the key behavioral trait of removing existing lights before creating a new setup, which is valuable. However, it does not mention other behaviors like whether it modifies existing lights, the number of lights created per style, or any side effects on other scene elements.
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 (two sentences plus a bullet-like list of styles) and front-loaded with the primary action. Every sentence provides distinct information, though a slight structural improvement could group style descriptions more clearly.
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 covers the main purpose and parameter semantics. However, it lacks information about return value, success messages, or any prerequisites, which are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the single parameter 'style', but the main description lists all styles with brief explanations, adding significant meaning beyond the schema. This compensates for the lack of schema-level documentation.
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 up studio lighting, specifies that it removes existing lights, and lists distinct styles (THREE_POINT, REMBRANDT, SOFT_BOX, SUN), differentiating it from sibling tools like light_setup_three_point which is more specific.
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 like light_setup_three_point or light_setup_studio. Without explicit usage context, an AI agent may struggle to select the appropriate tool among similar siblings.
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?
Annotations are absent, so the description carries the full burden. It discloses that bones are created in Blender and PhysBone components are configured in Unity, which is useful. However, it does not clarify whether existing bones are overwritten, prerequisite conditions, or what the return value represents, even though an output schema exists.
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 starts with the primary purpose. The parameter list follows in a clear bullet-like format. While efficient, it could be slightly more structured by separating the core description from parameter details.
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 6 parameters, 0% schema coverage, and no annotations, the description provides adequate parameter semantics but lacks details on output behavior (despite output schema) and error conditions. It covers the main use case but misses completeness for a moderately complex 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?
Input schema has 0% description coverage, but the description compensates by briefly explaining each parameter's purpose, including examples for direction and recommended range for bone_count. This adds significant meaning beyond the 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 clearly states the tool creates a bone chain for VRChat PhysBones, specifying examples like hair, tail, ears. It distinguishes itself from sibling tools like armature_add_bones_chain by focusing on VRChat PhysBones and mentioning that PhysBone components are configured separately in Unity.
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 vrc_physbone_config or armature_add_bones_chain. The parameter hints at usage for specific body parts but does not provide clear when-to-use or when-not-to-use 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 are provided, so the description must fully disclose behavior. It notes the requirement for at least 2 joints to form 1 bone, but does not explain side effects (e.g., where bones are added relative to existing bones), permissions, or error handling. The description lacks depth on mutability and safety.
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 single introductory line and a clear Args list. No unnecessary words. Each sentence is informative and earns its place.
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 4 parameters and no output schema, the description covers parameter usage but lacks details on prerequisites (e.g., armature must exist), return behavior, or error cases. It is 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?
Schema description coverage is 0%, so the description must add meaning. It explains each parameter: armature_name (target), chain_name (base name with .001 suffix), joints (list of positions, minimum 2 points), parent_bone (parent for first bone). This adds significant context beyond the raw 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 adds a chain of connected bones, with examples like spine, arm, finger. It distinguishes from siblings such as armature_add_bone (single bone) and armature_create (create armature). The verb 'add' and noun 'chain of connected bones' are specific.
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 examples of when to use (spine, arm, finger) but does not explicitly state when not to use or name alternatives (e.g., armature_add_bone for single bones). Usage is implied but no exclusions or comparative guidance.
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 states the core action but fails to mention side effects (e.g., whether existing vertex groups are cleared), prerequisites (e.g., armature must have bones), or failure conditions. The agent is left uncertain about the tool's operational context.
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 exceptionally concise: two succinct sentences plus a parameter list. Every word earns its place, with the key action front-loaded. No filler or 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, no annotations, and two simple params, the description covers the basic purpose but lacks essential behavioral details like error handling, state changes, or prerequisites. It is minimally viable but leaves gaps for a tool with this complexity.
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 (no parameter descriptions in the schema itself), so the description must compensate. It adds relational context: 'Armature to parent to' and 'Mesh to skin' clarify the direction of parenting beyond the schema titles 'Armature Name' and 'Mesh Name'. This reduces ambiguity for the 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?
The description clearly states the action ('Parent mesh to armature with automatic weights') and identifies it as the standard skinning method. This distinguishes it from sibling tools like armature_add_bone or vrc_auto_weight by specifying the automatic weighting approach.
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 says 'This is the standard way to skin a mesh to a skeleton,' which implies use for automatic weight skinning. However, it does not mention when to avoid this tool or suggest alternatives (e.g., manual weight painting, other armature parenting methods). Guidance is implicit but not explicit.
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 each parameter and hints at output_path auto-generation, but does not disclose side effects (e.g., file creation, overwriting) or requirements like UV maps.
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 description with bullet-style parameter list. Front-loaded purpose, no wasted words, 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 all parameters with usage hints, but lacks information about output (format, location), error cases, or prerequisites (UV maps, mesh topology). For a tool with 6 parameters and no output schema, more details are needed for 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 has 0% description coverage, so description compensates by explaining each parameter: high_poly, low_poly, resolution (with recommendation), cage_extrusion (with gap hint), samples, output_path. Adds meaningful context beyond names/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?
Description clearly states 'Bake a normal map from high-poly to low-poly mesh', specifying verb, resource, and process, distinguishing it from sibling bake tools like bake_ao or bake_textures.
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 other bake tools (e.g., bake_ao, bake_textures). The purpose is implied, but with multiple sibling bake tools, more explicit context is needed.
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 fully disclose behavioral traits. It explains the tool creates materials with node connections and lists presets, but does not mention potential side effects (e.g., overwriting existing materials) or prerequisites (e.g., active object).
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 (approx. 80 words) and well-structured with labeled parameter sections. Every sentence is informative; no fluff. Slightly verbose in the presets list but acceptable.
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 an output schema (not shown), the description need not explain return values. It adequately covers all parameters and provides practical context (e.g., preset types, texture keys). Missing details like default behavior for missing textures are minor.
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 significant meaning beyond the input schema, which has no parameter descriptions. It explains material_name, presets with concrete examples, textures as a JSON map with expected keys, and notes custom_nodes as advanced. This compensates for the schema's 0% 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 that the tool builds complex shader node trees programmatically, creating materials with proper node connections. It distinguishes itself from simple color assignment tools (e.g., set_material_color) by emphasizing its advanced capabilities.
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 explicit guidance on when to use this tool vs. alternatives like material_create_pbr or material_create_preset. It implies it's for complex setups but lacks formal when/when-not criteria or direct references 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 provided, so the description must cover behavioral traits. It explains input formats but does not disclose side effects (e.g., whether objects appear at origin by default, selection behavior, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the verb and resource, and lists types and parameter formats without 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 annotations and no output schema, the description covers basic input info but is not fully complete. It omits default behavior (e.g., location defaults to origin) and prerequisites like an active scene.
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%, and the description adds meaning by specifying that rotation is in degrees, location is [x,y,z], and scale is [x,y,z]. It also enumerates the type options. However, it does not mention default values for 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 the tool creates a 3D primitive object, lists all supported types, and explains the parameter formats. It distinguishes from sibling tools like create_curve or create_text by specifying primitives.
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. It implies usage for primitives but does not mention when not to use it or suggest alternative tools for other object types.
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 convey behavioral traits. It only states the creation action and gives parameter names, but lacks details about side effects (e.g., whether it overrides existing objects, adds to active collection, or requires specific modes). This is insufficient for full transparency.
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-style parameter list. No redundant information, and the key purpose is front-loaded. Every word earns its place.
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 no output schema and no annotations, the description should provide more context about the creation process, return value, and behavior (e.g., object added to scene). It covers the purpose and parameters adequately but lacks details like coordinate system or result feedback. For a basic creation tool in a complex environment, it is moderately complete.
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 provides brief labels for each parameter (name, length, points, location), adding basic context beyond schema defaults. However, it omits units for length, coordinate format for location, and does not explain how points affect the path shape. The additional value is modest.
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 creates a NURBS path and explicitly mentions two common use cases (follow-path animations and hair guides), effectively distinguishing it from sibling tools like curve_create_bezier or curve_create_circle.
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 context on when to use this tool (for follow-path animations and hair guides), which implies suitable scenarios. However, it does not explicitly state when not to use it or mention alternative tools among the many curve-related siblings.
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 behavior. It explains the two distribution modes but does not mention side effects like object movement, ordering, or whether it operates on existing transforms. 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?
Two sentences, front-loaded with purpose, no unnecessary words. Structure is efficient and clear.
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 simple parameters, description covers the core logic but omits details like possible axis values, ordering of objects, and expected behavior on input constraints.
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?
Parameter descriptions are missing from schema (0% coverage). Description explains 'spacing' behavior but does not describe 'axis' or 'names' beyond their names. Adds some value but not comprehensive.
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 evenly distributes objects along an axis, with two modes based on spacing. This distinguishes it from siblings like align_objects or center_objects which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use when even distribution is needed, but does not explicitly state when to use this tool over alternatives or provide context for when spacing vs no-spacing is appropriate.
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 the full burden. It explains the linked parameter behavior but omits details on return value, side effects, or handling of children/ materials. 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?
Two sentences, front-loaded with key behavior, no waste. Efficient and clear.
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 3-param tool with no output schema or annotations, the description covers core behavior but lacks detail on parameter semantics and behavioral context beyond duplication mode.
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 description must compensate. It explains linked well but does not clarify the 'name' parameter (what object? must exist?) or 'new_name' (renaming). Adds partial 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 tool duplicates an object, distinguishing between linked (instance) and unlinked (independent copy) modes. It is a specific verb+resource with clear differentiation from siblings like create_object or separate_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 duplication but offers no explicit guidance on when to use linked vs unlinked or alternatives. 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?
Discloses it runs in a fresh Blender instance via subprocess and captures variable 'result'. No annotations provided, so description carries full burden. However, it lacks details on side effects, permissions, or error handling.
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 front-loaded with purpose, uses bullet points for clarity, and is relatively concise. Slightly repetitive in places but overall 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?
Covers main purpose, execution model, and return value. With no output schema, explaining 'result' capture is good. Lacks error handling details and explicit contrast with similar tools.
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%, requiring description to explain parameters. 'code' is described only as 'Execute Python code directly', and 'timeout' has no description beyond a default of 300. No unit or behavior specified.
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 executes Python code in Blender headless mode, specifying 'no TCP' and providing use cases. It distinguishes from siblings like execute_code by emphasizing heavy operations and avoiding socket timeouts.
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 'Use this for heavy operations that timeout over the socket connection' and lists examples. It does not name alternative tools but the context implies when to use this vs 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the generative action and parameter options, omitting details on whether existing data is overwritten, permissions required, or side effects. The description is minimal and does not compensate for missing 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 concise: two sentences for purpose, two bullet-like lines for args. No redundant information, each sentence adds value. It is front-loaded with the main action.
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), the description covers the main function and parameters. However, it lacks information about the result (e.g., what is generated, where it is stored) and does not address potential side effects. For a generation tool in a large sibling set, more context about output 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?
Schema coverage is 0%, so the description must explain parameters. It does: 'mesh_name: Name of the face mesh' and 'source: ''arkit'' to map from existing ARKit shapes, or ''template'' for empty keys.' It adds context about default values and behavior beyond the schema's type/optionality.
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 specific action: 'Generate VRCFT Unified Expressions' from either 'existing ARKit shapes or from scratch'. It distinguishes from siblings like ft_create_arkit_shapes by specifying the target output (Unified Expressions) and the two source modes.
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 indicates two use cases via the 'source' argument (arkit vs template) but does not explicitly state when to use this tool over alternatives like ft_create_arkit_shapes or ft_combine_shape_keys. No exclusions or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral transparency. It lists the returned properties (location, rotation, scale, etc.), which is helpful. However, it does not disclose error behavior, whether the tool is read-only, performance implications, or requirements like the object must exist. More context 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 concise: one sentence stating the purpose followed by a bullet-point list of returned properties. It is front-loaded and efficient, with no wasted words. Every part 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 one parameter and no output schema, the description provides a good list of returned properties. However, it lacks information about prerequisites (e.g., object must exist), error handling, or side effects (none expected but not stated). Given the context of no annotations and no output schema, the description is moderately complete but has gaps.
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?
There is only one parameter, 'name', and the schema has no description for it. The description adds meaning by stating 'by name', clarifying the parameter identifies the object. However, it lacks specifics like whether the name is case-sensitive or if partial matches are allowed. For a single parameter with 0% schema coverage, the description adds value but could be more precise.
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 retrieves detailed information about a specific object. The verb 'Get' and resource 'detailed information about a specific object by name' are specific. It distinguishes itself from sibling tools like get_scene_info or get_hierarchy by focusing on object-level properties.
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 when you need detailed object properties, but it does not explicitly provide when to use or when not to use this tool versus alternatives like get_hierarchy or list_* tools. No exclusion criteria or alternative suggestions are given.
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 'Import,' implying a mutation, but does not disclose side effects, permission requirements, or error behavior. The description lacks details on what changes occur in 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: two sentences that front-load the purpose and add necessary parameter guidance. 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?
Given the tool's complexity (importing an asset) and lack of output schema, the description is adequate for a straightforward import but omits details like post-import behavior, object location, or prerequisites beyond generation completion.
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 0% schema description coverage, the description adds value by explaining 'name' as the object name in scene and that task_uuid or request_id are alternative identifiers. However, it does not fully clarify the sources (MAIN_SITE vs FAL_AI) or any constraints.
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 ('Import') and the resource ('Hyper3D Rodin generated asset'), and distinguishes it from sibling tools like import_generated_asset_hunyuan. It also specifies the timing ('after generation completes'), providing a precise scope.
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 clear context on when to use ('after generation completes') and how to identify the asset using task_uuid or request_id. However, it does not explicitly state when not to use or list alternatives, though the sibling tools imply differentiation.
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 lacks details on side effects, required permissions, or impact on scene. Does not disclose whether import overwrites existing objects or creates new ones, nor any irreversible actions.
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?
Two sentences: one for purpose, one for parameters. Efficient but could be better structured (e.g., separate lines). No unnecessary 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?
No output schema and no annotations. Description does not specify return value, prerequisites beyond generation, or what happens to existing assets. Incomplete for a mutation tool with no annotations.
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 adds meaning: 'name: object name' and 'zip_file_url: from the poll step when status is DONE'. This clarifies parameter sources beyond the schema's minimal 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?
Tool name and description clearly indicate importing a Hunyuan3D generated asset after generation. Specific verb 'import' and resource 'generated asset' with context of completion. Distinguishes from sibling tools like 'generate_hunyuan3d_model' and '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?
Description states 'after generation completes' and references 'poll step when status is DONE', providing clear usage context. Does not explicitly list alternatives or when not to use, but the context is sufficient given sibling tools.
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 the burden. It describes the tool as listing data, implying it is read-only, but does not explicitly state that it has no side effects or destructive potential. This is adequate but could 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 a single, clear sentence with no extraneous words. It efficiently conveys 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?
Given the tool's simplicity (no parameters, no output schema), the description covers the basics. However, it does not specify the format of the returned list (e.g., array of strings or objects). It is minimally adequate but not fully explicit.
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?
There are no parameters, so schema coverage is 100% trivially. The description adds value by specifying what information is returned (base color and user count), which goes beyond the empty 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 ('list'), the resource ('all materials in the scene'), and the specific returned fields ('base color and user count'). This distinguishes it from similar tools like material_list which may only list names.
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 material_list or material_create_pbr. An agent would have no context to differentiate it from sibling tools.
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 explains what the tool returns but does not disclose side effects, permissions, or limitations. It implies a read-only operation but does not state it explicitly.
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 the action and resource. The second sentence lists returns efficiently. No redundant 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?
Given one parameter and no output schema, the description adequately explains the measurement output (dimensions, volume, corners). It could mention that the object must be named, but overall it is sufficient.
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 has 0% description coverage for the only parameter 'object_name'. The description does not elaborate on the parameter beyond the tool's general purpose, leaving the agent to infer its meaning.
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 measures bounding box dimensions in world space and lists returned values (width, depth, height, volume, corners). This clearly distinguishes it from sibling tools like measure_distance or measure_alignment.
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 vs alternatives. It implies use for obtaining bounding box dimensions, but does not mention siblings or provide 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?
Without annotations, the description carries the full responsibility for behavioral disclosure. It informs that parameters are validated and invalid ones are caught before sending to Blender, which is useful. However, it omits side effects (e.g., does it modify the object directly?), undo behavior, or requirements like object selection, leaving gaps in transparency.
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: a clear purpose statement, a brief overview of capabilities, and a detailed Args section. It is front-loaded with the most important information. Minor redundancy (e.g., 'validated parameters' appears twice) but overall efficient and not overly long.
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 annotations or output schema, the description adequately covers the tool's function, supported modifier types, validation behavior, and parameter details. It references a related tool (modifier_list_types) for further options, which helps context. It lacks information on return values or post-conditions, but is generally complete for a modification 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?
With 0% schema description coverage, the description adds significant meaning to all four parameters. It explains object_name, modifier_type (with a list of valid types), modifier_name (auto-generated if empty), and params (dictionary of overrides, referencing modifier_list_types). This goes beyond the bare schema, though the params property could have more specific structure details.
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: 'Add a modifier to an object with validated parameters.' It specifies the action (add), resource (modifier), and includes unique details like type checking and range validation, which distinguishes it from generic sibling tools like add_modifier. The listing of 15 specific modifier types adds further clarity.
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 explicit guidance on when to use this tool versus alternatives (e.g., add_modifier, modifier_batch_add). It mentions validation and parameter options, but lacks context on prerequisites, suitability, or exclusions. Users are left to infer usage from the name and description alone.
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 carries full burden. It fails to disclose whether removal is destructive, reversible, or has side effects on the object.
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 succinct and front-loaded with purpose, but could be better formatted (e.g., bullet points) for readability.
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 annotations, no output schema, and simple parameters, description lacks prerequisites, side effects, and success indication, making it 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?
Schema has 0% description coverage, but description lists both parameters with meanings and possible values for physics_type, adding value 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?
The description clearly states 'Remove physics from an object' with specific parameters, distinguishing it from sibling tools like physics_add_cloth that add physics.
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 usage for removing physics from an object, and the sibling list contrasts with add tools, but no explicit when-not or alternative guidance is given.
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 describes the pipeline steps and parameters but does not disclose behavioral traits such as whether existing data is overwritten, permission requirements, side effects, or error handling. This is insufficient for a complex pipeline.
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 brief and front-loaded with the pipeline purpose and chain. Parameter descriptions are inline and clear. It could be slightly more organized but is 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?
The description covers what the pipeline does and the parameters, but lacks prerequisites (e.g., mesh topology requirements), error conditions, and handling of intermediate step failures. With an output schema present, return values are not required, but overall context is adequate but incomplete.
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. It explains each parameter clearly: mesh_name behavior when empty, method options with meanings, and boolean flags for pipeline components. This adds substantial value over the plain 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 is a complete face tracking pipeline that chains multiple tools, naming each step (vertex groups, ARKit 52, Unified, validate) and the specific tools involved. This distinguishes it from sibling tools like individual ft_* tools and other pipelines.
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 as a complete setup by listing the chain, but does not explicitly state when to use this pipeline versus running the individual tools separately, nor does it mention 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 provided, so description carries full burden. It discloses the effect of camera_name and create_if_missing, but lacks details on side effects (e.g., affecting viewport, scene changes) or behavior when camera already exists. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with a one-line summary and a clean argument list. No wasted words, but could benefit from better structure or additional context.
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 2 parameters and no output schema, the description covers core function and parameters. However, lacks return value description, error conditions, and comparison to similar tools. Adequate but leaves gaps.
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 explain parameters. It fully describes both parameters: camera_name's behavior when empty and create_if_missing's effect. Adds significant meaning beyond the schema's default values.
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 'Set the active render camera' which is a specific verb-resource pair. It distinguishes from sibling tool 'set_camera' by specifying 'render camera'. The parameter explanations further clarify the tool's behavior.
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 like 'set_camera'. The description does not mention prerequisites, limitations, or when to prefer this tool over similar ones.
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 discloses that the tool modifies the mesh by applying anatomically-informed smoothing/displacement. However, with no annotations, it fails to inform about destructiveness (permanent changes), potential side effects, or limitations (e.g., works on any mesh type?). Some behavioral details are missing.
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 purpose. The parameter list is clear but could be better formatted. Every sentence adds value without repetition.
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 existence of an output schema (though not shown) and parameter explanations, the description is fairly complete. It covers what the tool does, its inputs, and the effect on the mesh. Missing details about prerequisites or return values are minor.
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 explanations to all parameters beyond the schema's types and defaults. It defines the pass_type (primary, secondary, tertiary), body_region options, style choices, and intensity range. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: applying an anatomy-aware sculpting pass using built-in knowledge. It lists the parameters that define the pass type, body region, style, and intensity, making it distinct from other sculpt tools like sculpt_brush_full or sculpt_mask.
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 any guidance on when to use this tool versus alternatives, nor does it mention prerequisites (e.g., mesh must be in sculpt mode) or conditions under which it is inappropriate. It simply describes the tool's function and parameters without usage 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?
Description explains parameters and method-specific behaviors but does not disclose side effects (e.g., whether original mesh is modified, if scene structure changes, or required mode). Since no annotations exist, description carries full burden but is only partially complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with a clear purpose sentence followed by bullet lists for method options and parameter descriptions. Front-loaded and concise without redundancy, though 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's complexity (6 parameters, nested param structures) and presence of an output schema, the description is fairly complete. Explains all methods and their specific param requirements, but could mention the return value (new object name) or scene impact.
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, description compensates by explaining each parameter (method, thickness, offset, smooth_iterations) and providing usage examples for params field (by_face_set and by_position). Adds significant value beyond the raw 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?
Description clearly states it extracts part of a sculpted mesh as a new object and lists four extraction methods. It distinguishes itself from potentially overlapping sibling tools like sculpt_extract_face_set by covering broader extraction methods.
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., sculpt_extract_face_set). Does not provide context for choosing between methods or 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?
With no annotations, the description carries the full burden. It discloses the auto-cleanup behavior and explains the structure of each trim type. However, it does not indicate whether the operation is destructive, if the original mesh is modified or replaced, or if undo is supported. Some behavioral details are missing.
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 an introductory line, bullet-like list of trim types with their params, and a cleanup note. Every sentence provides useful information 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 details, but lacks context on prerequisites (e.g., being in sculpt mode), expected outputs (though output schema exists), and side effects. Given the complexity, some additional context would be beneficial.
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 significant meaning by explaining each trim_type and providing detailed JSON format examples for plane, box, sphere, and custom. This goes well beyond the schema's basic types and defaults, making the parameter usage clear.
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 performs 'Boolean trim/cut operations for sculpting' and lists specific trim types (plane, box, sphere, custom). This distinguishes it from the general boolean_operation tool and other sculpt tools by specifying the sculpting context and the trim/cut focus.
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 boolean_operation or other sculpt tools. The description does not mention prerequisites, when to choose one trim type over another, or when this tool is preferable.
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 all behavioral traits. It fails to mention side effects like whether the original object is deleted, whether transformations are applied, or any permission requirements. The modes are vague and lack operational 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 extremely concise with two sentences, no redundant information, and the purpose is front-loaded. Every word 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?
Given no output schema and low parameter count, the description covers the basic function and modes. However, it lacks completeness by not explaining the outcome on the original object or constraints on object types, leaving gaps in 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?
The description explains the 'mode' parameter with its three options, adding meaning beyond the schema. However, the required 'name' parameter is not described, leaving ambiguity about its purpose despite schema coverage being 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 tool's verb and resource ('separate an object') and specifies modes with brief explanations (LOOSE, MATERIAL, SELECTED), which distinguishes it from sibling tools like join_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?
The description lists three modes with brief descriptions, providing clear context for when to use each. However, it does not explicitly mention when not to use this tool or suggest alternative 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 carries full burden. It discloses the file path requirement but does not mention side effects, overwrite behavior, or permissions needed.
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, no redundant information, and front-loaded with the key action.
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?
Adequate for a simple setter tool with one parameter, but lacks information about return values, whether it replaces existing world, or if a world node must exist.
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 specifying the file format and indicating a full path is required, going beyond the generic string 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 the action ('Set an HDRI image') and the resource ('world environment'), specifies the file format ('.hdr or .exr'), and is distinct from sibling tools like set_world_color or set_sky_texture.
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 realistic lighting but does not explicitly state when to use this tool versus alternatives like set_world_color or set_sky_texture, nor does it provide 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 exist, so the description must fully disclose behavior. It states the main effect but omits details like side effects on object origin, undo behavior, or whether it's destructive.
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 short sentences, no wasted words, front-loaded with the core 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?
For a one-parameter tool with no output schema, the description covers the main action and context, but lacks parameter guidance, which is a minor gap.
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?
The only parameter 'name' has no schema description (0% coverage) and the tool description offers no explanation of what 'name' refers to (e.g., object name), leaving the agent to infer.
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 ('Snap') and resource ('object's lowest point to Z=0'), clearly distinguishing it from siblings like 'center_objects' and 'align_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?
Provides context ('useful for placing objects on a floor or surface') but does not include when not to use or mention alternatives among the many sibling alignment/transform 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?
Without annotations, the description should disclose behavioral traits. It explains the JSON format and output file but omits details like whether existing files are overwritten, required permissions, or error handling. The behavioral transparency 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 relatively concise with two introductory sentences and a JSON example. The example is helpful but takes space; could be slightly more streamlined without losing clarity.
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 no required parameters, 0% schema coverage, and no behavioral details from annotations, the description partially completes the context by explaining the JSON format for clip creation. However, it lacks explanation of return values, error states, or post-conditions.
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 must compensate. It describes all three parameters (project_path, clip_json, output_path) and provides an extensive JSON format example, adding significant meaning 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 generates a Unity AnimationClip .anim file from a JSON blueprint, specifically for blend shape animations (face tracking, expressions, toggles). This verb+resource combination is distinct from sibling tools like unity_create_animator or anim_insert_keyframe.
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 it is used for blend shape animations, implying when to use it, but does not explicitly state when not to use it or recommend alternatives. It lacks explicit usage boundaries.
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 only states that PhysBone components are added, but does not mention whether it overwrites existing data, required permissions, or error handling for invalid JSON. The JSON format example is helpful but insufficient.
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 purpose, and well-structured with bullet points and a JSON example. Every sentence provides necessary information 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?
Given the moderate complexity (3 parameters, JSON input) and the presence of an output schema, the description covers the main usage. However, it omits details like whether existing physbones are replaced and input validation, leaving some gaps.
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 provides explanations for all three parameters: project_path, avatar_object, and a detailed format example for physbones_json. This adds significant value beyond the empty 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 'Add', the resource 'VRCPhysBone components', and the context 'to an avatar from a JSON blueprint'. This distinguishes it from siblings like 'vrc_setup_physbone_chain' which sets up a single chain, and 'vrc_physbone_config' which configures existing physbones.
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 batch setup via JSON but does not explicitly state when to use this tool versus alternatives such as 'vrc_setup_physbone_chain' or 'vrc_physbone_config'. No exclusions or prerequisites 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 are provided, so the description carries the full burden. It explains what info is retrieved but does not disclose whether the tool modifies the object, dependencies (e.g., object must have UV layers), or error handling for missing layers.
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, well-structured sentence that immediately conveys the purpose. No wasted words; essential 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?
Given the tool's simplicity (one param, no output schema), the description is largely complete. It could mention what happens if the object has no UV layers or the return format, but the core value is clear.
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?
With 0% schema description coverage, the description should elaborate on the single parameter 'object_name'. However, it simply repeats the name without adding meaning or constraints (e.g., format, valid targets).
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 'Get' and the resource 'UV layer info for an object', specifying exactly what info is returned (layer names, island count estimate). It effectively distinguishes from sibling tools like uv_add_layer or uv_unwrap.
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 or when not to use this tool. It implies use for reading UV info, but does not mention alternatives or exclusion criteria, such as suggesting uv_smart_uv_project if UV unwrapping is needed instead.
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 states 'Calculate' and 'Checks' but does not explicitly confirm whether the tool is read-only, destructive, or has side effects. Lack of permission or safety context 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 concise, front-loaded with the purpose, and includes structured parameter examples without unnecessary text. 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 has an output schema (not shown) which likely documents return values, so the description is adequate. It covers the key function and parameter formats, but could mention that it is non-destructive or provide context on when to use it in a pipeline with other 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?
The input schema defines all parameters as strings but the description provides detailed JSON format examples (arrays with specific fields). This adds essential structure beyond the schema, especially with 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 calculates VRChat Avatar Dynamics budget usage, checking PhysBones, Contacts, and Constraints against performance rank limits. This is specific and distinct from sibling tools like vrc_validate, which has a broader scope.
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 does not specify prerequisites, when to avoid, or contrast with similar tools like vrc_physbone_config or vrc_validate.
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 a report and can auto-merge identical settings, but does not specify if materials are modified or deleted, nor the content of the report.
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: three sentences plus a parameter list. Information is front-loaded and no words are wasted.
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 existence of an output schema (not shown) and only two simple parameters, the description covers the tool's purpose and key behavior adequately. Lacks some detail on merging effects, but overall sufficient.
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 by explaining defaults for mesh_name (uses 'Body' or first mesh if empty) and target_count (default 1). Schema has no descriptions, so this compensation is valuable.
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 analyzes and prepares materials for merging to reduce material slot count, and can auto-merge identical materials. This specifies a verb ('analyze and prepare') and resource ('materials for merging'), distinguishing it from sibling tools like material_list or material_assign.
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 description implies it is for atlas preparation and merging, but does not mention exclusions or alternatives among siblings.
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 notes that if armature_name is empty, it uses the first armature found, but it does not mention whether the operation is destructive, if it modifies the original mesh, or any prerequisites or side effects beyond vertex group updates.
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 explaining the main action and one line for parameter details. No redundant information, and the key behavior 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 covers the main functionality but lacks completeness for a data-modifying tool. It does not mention prerequisites, error conditions, or what the output schema returns (though an output schema exists). Gaps exist for an agent to fully understand when and how to use it safely.
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 no descriptions (0% coverage), so the description must add meaning. It explains the armature_name parameter's purpose and default behavior (uses first armature if empty), which provides useful context 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?
The description clearly states it renames bones from common schemes (Mixamo, MMD, VRM, Blender) to VRChat-compatible standard names and updates vertex groups. This verb-resource-action is specific and distinguishes it from sibling tools like vrc_fix_model.
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. It only describes what it does and parameter behavior, leaving usage context implied rather than explicit.
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 that with keep_transform=True the object stays in place, which is useful. However, with no annotations, it does not disclose prerequisites (e.g., object must have a parent) or side effects (e.g., world transform preservation 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 a single concise sentence that includes the core action and a key parameter behavior. No extraneous 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 the tool's simplicity (2 params, no output schema), the description covers the main behavior. It lacks prerequisites and return value details, but for a straightforward operation it is reasonably complete.
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 is the sole source of parameter meaning. It clarifies the 'keep_transform' parameter's effect but does not explain the 'name' parameter beyond its name. This adds some value but not comprehensive.
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: 'Remove parent from an object.' It also distinguishes from sibling tools like 'set_parent' by specifying the removal operation. The mention of the keep_transform parameter adds precision.
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 remove parent) but lacks explicit guidance on alternatives or when not to use. It does not reference sibling tools like 'set_parent' or 'remove_constraint'.
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 bones are created in edit mode and switched back to object mode, which is a useful behavioral detail not evident from annotations or schema. No annotations exist, so the description adds value.
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 three sentences: purpose, bone format, and mode behavior. 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 the tool's complexity, it explains the bone format and mode, but lacks details on default behavior when name or bones are null, error handling, or return values. Acceptable but not comprehensive.
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, so the description completely carries the burden. It explains the expected structure for the 'bones' parameter (list of dicts with name, head, tail, parent) and notes that parent is optional, adding crucial meaning.
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 creates an armature with bones for rigging. However, it does not distinguish itself from the sibling tool 'armature_create', which likely has a similar purpose.
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 the many related armature tools (e.g., armature_add_bone, armature_create). The description only gives the bone dict format but no context for tool selection.
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 that bevel properties are set and defines parameters, but does not mention side effects, requirements (e.g., object must be a curve), or error conditions. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: one-line purpose followed by parameter list. No fluff, front-loaded with the key effect. 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 and lack of output schema, the description covers all parameters and the overall effect. However, it would benefit from mentioning return behavior or confirmation, but it is largely complete for a parameter-setting 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 description coverage is 0%, but the description includes docstring-like explanations for each parameter: bevel_depth (0=wireframe, >0=tube), bevel_resolution (smoothness), bevel_object (custom profile curve). This adds significant meaning beyond the schema alone.
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 sets bevel properties on curves to create a tube/pipe effect. It distinguishes from siblings like curve_to_mesh (which converts curve to mesh) and curve_create_* (which create curves).
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 adding a bevel modifier or using other curve-related tools. Does not mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It lists many parameters giving insight into behavior, but does not disclose potential side effects (e.g., file overwriting, required permissions, size limits). Neutral 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?
Extremely concise: a single-sentence purpose followed by a list of parameters with brief, clear explanations. No redundant information; every sentence earns its place.
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 file export tool with 7 parameters and no output schema, the description covers the parameters well. It lacks mention of return values or error handling, but these are less critical given the straightforward nature of the 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?
With 0% schema description coverage, the description adds significant value by explaining each parameter's meaning (e.g., export_format options as 'GLB' or 'GLTF_SEPARATE', selected_only as 'Export only selected objects'). This compensates well 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 clearly states the action ('Export') and the resource ('glTF/GLB format'), with contextual note ('standard for web and universal 3D'). This distinguishes it from sibling export tools like io_export_fbx, io_export_obj, etc.
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. While the format description hints at web usage, there is no mention of trade-offs, when-not-to-use, or comparisons with other export tools.
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 the full burden. It discloses auto-detection and supported formats but omits behavioral details like whether the import replaces existing objects, handles animations/textures, or error behavior for unsupported formats.
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, with a single paragraph plus a list of supported formats and Args. It front-loads the purpose. However, the format list could be integrated more efficiently or placed in schema enums.
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 two parameters and lack of output schema or annotations, the description covers basic purpose and parameters. However, it lacks details on return values, scene impact (e.g., selection behavior), and error handling, making it barely adequate for a file import 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?
Schema coverage is 0%, so the description must compensate. The Args section adds meaning by clarifying file_format as 'Override format detection,' which is not in the schema. However, it does not specify whether filepath must be absolute/relative or the format of the string.
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 'Import a 3D file into the current scene,' specifies auto-detection from extension, and lists all supported formats. This provides a specific verb-resource pairing and distinguishes from sibling export 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 implies when to use (when importing a file) but does not explicitly compare to alternatives like import_generated_asset or mention when not to use the tool. No prerequisites or exclusions are given.
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 should disclose behavioral traits. It only lists parameters and their ranges, but does not mention what happens when created (e.g., storage, side effects, if it modifies existing materials).
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 docstring with a clear Args list. Every sentence adds value, and it is well-structured with 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?
The tool has 10 parameters and no output schema. The description covers parameters well but lacks information about return values, prerequisites, or side effects, leaving some gaps for an agent.
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 coverage, the description adds crucial meaning for all 10 parameters, including ranges, examples, and clarifications (e.g., metallic 0-1, roughness 0-1, ior values). This goes well beyond the schema's minimal info.
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 creates a custom PBR material with full control, using a specific verb and resource. It distinguishes itself from siblings like material_create_preset.
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 hints at full control but does not explicitly state when to use this tool over alternatives like material_create_preset or set_material. No exclusions or context provided.
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; description discloses mutation but omits details like idempotency, effect on existing physics, or failure conditions. Only basic behavior is 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?
Very concise: one sentence for purpose, then bullet list for args. Front-loaded and efficient with no superfluous content.
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?
Adequate for a simple tool: explains purpose and parameters. Minor gaps: no units for thickness_outer, no value constraints. No output schema 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 0%, so description compensates partially: lists parameters with brief explanations (e.g., 'thickness_outer: Collision surface thickness'), but lacks units, range, or impact details.
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 collision physics to an object (makes it a collider for cloth/particles)', specifying the verb, resource, and differentiating from siblings like physics_add_cloth or physics_add_rigid_body.
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 use for making objects colliders for cloth/particles, but lacks explicit when-not or alternative tool names. No guidance on 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?
The description explains parameters (e.g., 'ACTIVE only' for mass) but does not disclose side effects, prerequisites, or whether it is destructive. With no annotations, the description could better cover behavioral traits like overwriting existing physics.
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 docstring format is well-structured with a clear purpose sentence followed by Args section. It is efficient but could be slightly more concise by integrating default values from the schema.
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 straightforward physics tool, the description covers all parameters and some constraints. However, it lacks return value info and side effects, which is acceptable given no output schema. Overall, it provides enough context for correct 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?
The description adds detailed meaning to each parameter beyond the schema: units (kg), valid ranges (0-1), enums explained (ACTIVE vs PASSIVE), and collision shape types. 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 action ('Add rigid body physics') and the target ('object'), using a specific verb and resource. It distinguishes from sibling tools like 'physics_add_cloth' or 'physics_add_soft_body' by focusing on rigid body physics.
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 over alternatives (e.g., cloth, soft body). It lists parameters but no context for selection, and there is a confusingly similar sibling 'add_rigid_body' without differentiation.
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 carries full burden. It explains preset effects but does not disclose that applying a preset modifies scene settings, whether it overwrites existing settings, or any potential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentence introduction plus a structured list of presets. No extraneous content. Information is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is mostly complete: it tells what it does and the available options. Missing return value/status and error handling details, but adequate for its 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?
Schema has only preset_name with no description (0% coverage). The description lists preset names and their meanings, adding significant value beyond the schema. However, does not specify case sensitivity or format requirements.
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 applies a render preset to the current scene, with specific verb+resource. Distinguishes from siblings like render_still or render_image by focusing on preset 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?
Lists available presets with details, but does not explicitly advise when to use this tool vs. alternatives like render_still or render_image. Lacks '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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists actions but lacks behavioral details such as destructiveness (e.g., 'delete_higher' removes subdivisions irreversibly), required mesh state, or error conditions. Since no annotations are provided, the description carries the full burden and fails to disclose important operational 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?
The description is concise and well-structured: a single-sentence summary followed by a bulleted list of actions with brief explanations. Each sentence adds value, and the format allows quick scanning. There is no redundancy or 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 the complexity of a multi-action workflow tool, the description covers all actions and key parameters. An output schema exists, so return values are not needed. However, it lacks mention of the required mesh_name parameter and error handling, leaving some gaps for a fully autonomous 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?
The description adds meaning to parameters beyond the input schema, which has only titles and defaults. For example, it explains the action values, sculpt_level as target for 'set_level', and levels as subdivision count for 'setup'. However, mesh_name is not described, and schema coverage is 0%, so the description compensates well but not 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 purpose as 'Full multi-resolution sculpting workflow control' and lists specific actions (setup, set_level, apply_base, etc.), which precisely defines what the tool does. It distinguishes itself from sibling sculpt tools by focusing on multires workflow management.
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 the listed actions (e.g., use 'setup' to add the modifier, 'set_level' to change subdivision level), but it does not explicitly state when to use this tool versus alternatives like sculpt_brush_full or sculpt_remesh. There is no guidance on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of each action and parameters like iterations and preserve_volume, but does not cover side effects or performance implications.
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 clear bullet points for actions and parameter list. It is relatively concise with minimal 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 5 parameters and an output schema, the description covers actions adequately but lacks prerequisites, mesh compatibility details, or error scenarios.
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 semantically explains the 'action' parameter with detailed sub-options, but other parameters like mesh_name, iterations, factor, and preserve_volume are only listed without additional meaning beyond schema 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 it's for 'targeted smoothing operations for sculpted meshes' and lists specific actions like smooth_by_mask and smooth_boundary, which distinguishes it from other sculpt 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 explains what each action does but does not explicitly state when to use this tool versus alternatives like sculpt_brush_stroke or other smoothing tools. Context is implied but not directly guided.
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 burden of behavioral disclosure. It indicates the operation is applied to all faces and defines parameters, but does not mention whether the operation is destructive, modifies the mesh in-place, or requires any specific object state (e.g., edit mode).
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 concise sentences with front-loaded action and parameter explanations. 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?
For a simple mesh operation with no output schema, the description covers the core functionality and parameters. Minor gaps: does not specify whether the operation is applied to the active object or the named object, or the return value.
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. It explains 'cuts' and 'smooth' parameters, but does not explain the required 'name' parameter (likely the mesh object) or constraints (e.g., cuts >= 0). Partial value added.
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 defines key parameters ('Cuts = number of subdivision levels', 'Smooth > 0 applies smoothing'). It distinguishes itself from siblings like 'decimate' or 'remesh' which perform different mesh operations.
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 increasing mesh resolution but does not explicitly state when to use this tool versus alternatives (e.g., modifiers like 'subdivision_surface'). No when-not-to-use or prerequisite information 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?
With no annotations, the description carries the burden of behavioral disclosure. It mentions that blueprint_json uses intelligent defaults if empty, but does not describe side effects, permissions required, or what happens to existing assets. For a pipeline that likely modifies the scene significantly, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-sentence summary, then a list of parameters with brief explanations. Every sentence adds value, and the structure is front-loaded with the essential 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?
The description covers the tool's high-level purpose and all parameters. However, it does not mention the return value or output schema, which exists. Given the complexity of the pipeline, a brief note on what the tool returns would enhance 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?
Although the input schema has 0% description coverage, the description adds meaningful explanations for all four parameters, including the optional blueprint_json override behavior. 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.
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 performs a one-click full Unity avatar setup pipeline, enumerating specific steps (import FBX, configure humanoid rig, set up avatar descriptor, create expression menu/params, configure materials). This distinguishes it from sibling tools that handle individual steps.
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 it is a comprehensive pipeline for avatar setup, but does not explicitly state when to use it versus using individual sibling tools (e.g., unity_import_fbx, unity_setup_avatar_descriptor). No when-not-to-use 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.
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 mentions configuration and verification but does not clarify whether the tool is read-only or modifies files, what happens on failure (e.g., missing SDK), or any side effects like setting environment variables. This lack of transparency leaves the agent uncertain about the tool's safety and outcomes.
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, well-structured with clear sections for purpose and parameter details. Every sentence adds value, and the parameter list is formatted cleanly. There is 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?
The tool has two parameters and an output schema (not shown). The description lacks details about return values or side effects, which are important for a setup tool. However, given the simplicity and the presence of an output schema, the description is minimally adequate but could be enhanced with more context on outcomes.
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 must compensate. It fully explains both parameters: project_path (path or env var fallback) and verify_sdk (boolean with default). This adds significant meaning beyond the schema structure, enabling 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 the tool configures Unity project path and verifies VRChat SDK installation, detailing specific checks (VRCSDK3-AVATAR, assemblies, structure). This is a specific verb+resource combination that distinguishes it from sibling tools like unity_build_avatar or unity_import_fbx.
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 initial project setup or verification before other VRChat operations, but does not explicitly state when to use or exclude, or mention alternative tools. Usage context is clear but lacks guidelines on prerequisites or scenarios where this tool 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?
No annotations are provided, so the description carries the full burden. It discloses basic parameters but does not explain whether the change affects the 3D viewport or the camera, if the operation is reversible, or if there are any side effects. Minimal transparency beyond the obvious.
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 extraneous words. The first sentence immediately communicates the purpose, followed by a clear list of arguments. Every word earns its place, and the structure is easy to parse quickly.
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 two-parameter tool with no output schema, the description covers all necessary aspects: what it does, what each parameter means. However, it could mention that it applies to the 3D viewport (not camera) and what happens if an invalid view is provided. Still, it 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.
Parameters4/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 must compensate. It does so by explicitly listing the allowed values for 'view' and clarifying the boolean 'perspective' argument. This adds significant meaning beyond the default titles and values, though it could be more precise about the perspective parameter (e.g., 'True for perspective view, False for orthographic').
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 resource 'viewport', and specifies the action 'to a standard view angle'. It lists the allowed view values (FRONT, BACK, etc.), which distinguishes it from siblings like 'viewport_focus_object' that focus on an object rather than setting a standard 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 implies when to use (when a standard view angle is needed), but lacks explicit guidance on when not to use or alternatives. For example, it does not mention that other tools like 'set_camera' or manual rotation exist for custom views. The context of siblings is not leveraged to clarify boundaries.
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 description carries full burden. It mentions creation of armature but lacks details on side effects (e.g., overwriting existing armatures), required permissions, or reversibility.
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: two sentences plus a parameter list. Front-loaded with the core purpose, 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 the tool's simplicity (creating a standard armature) and presence of an output schema, the description adequately covers intent. Could mention that it returns a reference to the new armature object, but not strictly necessary.
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?
Input schema has 0% description coverage, but the description lists all 4 parameters with defaults and brief explanations, adding significant meaning beyond the schema. Could be slightly more detailed (e.g., what 'include_fingers' entails).
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 it creates a VRChat-compatible humanoid armature from scratch with a T-pose skeleton. This specific verb+resource combination distinguishes it from siblings like 'armature_create' and 'vrc_rename_bones'.
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 usage when a new armature is needed, but no explicit guidance on when not to use or alternatives. Among many armature-related siblings, no comparison or exclusion criteria provided.
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 transparency burden. It discloses that the tool calculates a ratio and applies a Decimate modifier, and explains the preserve_shape_keys technique ('CATS blend_from_shape... gold standard'). However, it does not mention whether the operation is destructive, modifies in place, or creates a new object, leaving some behaviors ambiguous.
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: a single introductory sentence followed by a clear bullet list of parameters. Every sentence adds value, but the list could be slightly more compact. Overall, it is well-structured and front-loaded with 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?
Given the tool's complexity (4 parameters, output schema present), the description covers the general workflow and parameter meanings. However, it lacks details on prerequisites (e.g., mesh type) or limitations (e.g., what 'smart' means algorithmically). The output schema presumably covers return values, so that gap is acceptable. Overall, it is 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?
The input schema has 0% description coverage, so the description must add meaning for all 4 parameters. It provides explicit values for target_rank ('excellent', 'good', 'medium', 'poor'), platform ('pc' or 'quest'), mesh_name behavior, and a detailed explanation of preserve_shape_keys. This significantly adds value beyond the schema, though it could include even more detail (e.g., enum lists not fully given).
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 it performs 'Smart decimation to reach a target VRChat performance rank', which is a specific verb+resource combination. It distinguishes itself from the generic 'decimate' sibling by focusing on VRChat rank targets, making its purpose clear and differentiated.
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 implicit usage context by mentioning VRChat performance ranks and including parameter defaults (target_rank, platform), but does not explicitly state when to use this tool versus alternatives like 'decimate'. No 'when not to use' or exclusion criteria are given, so guidance is adequate but not explicit.
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. It discloses creation of shape keys and Animator Controller, lists standard gestures, and explains behavior for empty mapping and mesh_name. However, it does not mention potential side effects (e.g., overwriting existing data) or system requirements, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line purpose, a bullet list of gestures, and parameter details. It is concise but not overly terse, earning its space. A minor improvement could be removing the gesture list if it's standard knowledge.
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 specific use case (VRChat avatar gestures) and 2 parameters, the description covers core functionality. However, it does not mention prerequisites (e.g., existing armature, mesh) or what the output schema contains (though an output schema exists but is not provided). This leaves some contextual gaps.
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 2 parameters with zero description coverage. The description adds significant value: it explains mesh_name is the face mesh with auto-detection, and mapping is a JSON object with a concrete example and default behavior (creates template if empty). This provides clear semantics 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 sets up gesture-driven blendshapes, creates shape keys for each hand gesture, and generates Animator Controller configuration. It distinguishes from siblings like vrc_setup_visemes and vrc_generate_animator by specifying the focus on hand gestures and explicit setup steps.
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 up gesture blendshapes in VRChat avatars but does not explicitly state when to use or when to avoid, nor does it mention alternatives. It lacks explicit usage context or exclusion 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 must fully convey behavior. It explains parameters but omits side effects (e.g., whether it replaces existing particle systems), return values, or required object context.
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, consisting of two sentences that front-load the purpose and then list key parameter meanings without unnecessary 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?
Given the complexity of particle systems and the lack of output schema or annotations, the description covers core functionality but omits details about object selection (implied by required 'name' parameter), scope, and potential constraints.
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 parameters: explains type options (EMITTER, HAIR), count, lifetime, and velocity. However, it does not cover the 'size' parameter, leaving a gap.
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 (add) and resource (particle system to an object), distinguishes from siblings like add_cloth or add_light by specifying particle-specific parameters and types.
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 context on parameter meanings but does not explicitly guide when to use this tool versus alternatives, such as the sibling 'physics_add_particle_system'. No exclusions or prerequisites 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 the description carries the transparency burden. It discloses that using color creates a new material, but does not explain side effects like overwriting existing materials or what happens if material_name is invalid. The information is moderately 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?
Two sentences, no filler, front-loaded with the primary action. Every word 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?
The description is adequate for a simple batch operation but lacks context on error handling, return values, and differentiation from sibling tools like material_assign. Given the presence of many sibling tools, more contextual guidance would be beneficial.
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 description must compensate. It explains the meaning of 'color' (new material with RGB) and 'material_name' (use existing), but does not describe the 'names' parameter (the objects). This leaves some ambiguity.
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 'Assign', the resource 'material', and the scope 'to multiple objects at once'. It also distinguishes two modes (color for new, material_name for existing), which is specific and actionable.
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 color versus material_name, which is helpful. However, it lacks explicit guidance on when not to use this tool (e.g., for single object or per-object material assignment) and does not name alternative tools like material_assign.
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 disclose behavior. It explains the vector format for translate, rotate, scale and the relative flag. However, it does not specify whether transforms are applied absolutely or additively (beyond the relative flag), whether the operation is destructive, or what result to expect (e.g., modifies objects in place).
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 three sentences, front-loaded with the primary purpose. Every sentence provides necessary information without redundancy or fluff.
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 complexity of a batch transform operation with multiple parameters and no output schema, the description covers the essential functionality but lacks details on error handling, return values, prerequisites, or behavior when parameters are omitted.
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. It describes the format of transform vectors and the relative flag, which adds some value. However, it does not explain the 'names' parameter (required) or provide further details on defaults or constraints.
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 specifies 'Apply the same transform to multiple objects at once,' which clearly indicates the verb (apply), resource (transform), and scope (multiple objects). This distinguishes it from single-object transform tools like rotate_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests use when applying identical transforms to multiple objects, but does not explicitly state when not to use it (e.g., for different transforms) or mention alternatives. Sibling tools include single-object transforms, so the context 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?
With no annotations, the description discloses the key behavioral trait: it replaces the current scene. Also specifies 'in the running Blender instance', adding context beyond the 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?
Two sentences, front-loaded with action and key warning. 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?
Adequate for a simple tool with one parameter and no output schema. Covers the core behavior and side effect. Could mention that the Blender instance must already be running, but that is implied by 'in the running Blender instance'.
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 coverage is 0% (no description in schema), yet the description adds no meaning to the file_path parameter. Does not specify expected format, path type, or 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?
Clearly states the tool opens a .blend file. Distinguishes from siblings like blender_new_file and io_import_file by noting it replaces the current scene.
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 explicit guidance: 'save first if needed' because it replaces the scene. Does not mention when to use alternatives, but context is clear enough.
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?
Since no annotations are provided, the description carries the full burden. It discloses that the tool generates a bpy script, executes it in headless Blender, and lists supported JSON fields. This gives good behavioral insight, though it does not cover error handling or potential 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 well-structured with bullet points and a concrete example, making it easy to parse. It is slightly long due to the example, but every section adds value; no redundant content.
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 the tool's core operation (execution method, JSON structure). It lacks details on output parameters ('blend_output', 'render_output') and the scene handling (append vs clear), but is otherwise 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 elaborates extensively on 'scene_json' with a detailed example and field breakdown, compensating for the 0% schema coverage. However, 'blend_output' and 'render_output' are not explained, leaving ambiguity about their purpose and format.
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 'Build a complete Blender scene from a JSON description', with a specific verb and resource. It distinguishes from siblings like 'generate_scene_script' by describing direct scene building rather than script generation.
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?
Usage is implied ('Build a complete Blender scene from a JSON description') but no explicit when-to-use vs alternatives like 'generate_scene_script' or 'io_import_file'. The mention of 'CLI-Anything' origins provides context but not comparative 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 must disclose behavioral traits. It mentions running a simulation and saving a shape key, implying a non-destructive addition. However, it lacks details on whether it modifies the mesh, requires an existing cloth modifier, or overwrites shape keys, and does not describe the return value or potential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences in the main body followed by a clear list of arguments. No unnecessary words, and the purpose is front-loaded, making it easy for an AI agent to quickly understand the tool's function.
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 (cloth simulation plus shape key creation) and the lack of output schema, the description provides high-level purpose and param descriptions but omits crucial details like prerequisites, error conditions, and return values. It is adequate but not fully complete for an agent to use without external knowledge.
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, so the description's Args section adds value by providing short explanations for all 5 parameters (e.g., 'Name of the mesh object', 'Simulation frames'). While terse, these descriptions clarify the purpose beyond the schema titles, compensating 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 tool runs a cloth simulation and saves the result as a shape key, with a specific use case for creating natural rest poses for clothing hanging from a pin point. It distinguishes from sibling tools like 'add_cloth' or 'sculpt_to_shape_key' by its unique combination of simulation and shape key conversion.
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 clothing that should hang naturally from a pin point, providing context for when to use it. However, it does not explicitly state when not to use it or name alternative tools, such as 'add_cloth' or 'physics_add_cloth', leaving some ambiguity for an AI agent.
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 adds some behavioral context (e.g., order_u range 2-6, w weight default 1.0) but does not discuss side effects, permissions, or creation behavior (e.g., where the curve appears).
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 and well-structured as a docstring with Args. Every sentence adds value; no redundancy or fluff.
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 creation tool with no output schema, the description covers key parameters but omits behavior like return value or how the curve integrates into the scene (e.g., added to active collection). Lacks full context for an agent.
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% (no descriptions in schema), so the description carries full burden. It explains each parameter, including details ('w = weight, default 1.0' for points, 'order_u (2-6)'), adding significant meaning beyond schema 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 'Create a NURBS curve.', specifying the verb and resource. It distinguishes from siblings like curve_create_bezier by explicitly naming the curve type (NURBS).
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., curve_create_bezier, curve_create_circle). An agent cannot determine context for preferring NURBS over other curve types.
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 clearly states the modifications (removing orphans, merging vertices) and the return value (log). It could be more transparent about destructiveness or undo capability, but the actions are specific.
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 actions and return value. No extra words, highly 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?
The description covers main actions and return value. Given no output schema, the log return is useful. It could mention scope (entire scene) is clear, but side effects or persistence could be added. Overall adequate for a cleanup tool.
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 description should compensate. The description mentions 'merge duplicate vertices' but does not explain what merge_threshold means (e.g., distance threshold). The parameter name is suggestive but not fully 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?
The description states specific actions: remove orphan meshes/materials/images and merge duplicate vertices on all meshes. It clearly identifies the resource (entire scene) and verb (optimize), and distinguishes from sibling tools like merge_by_distance which only merge vertices, while this tool does a comprehensive cleanup.
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 comprehensive scene optimization but does not provide explicit guidance on when to use this tool versus alternatives like merge_by_distance or scene_cleanup. No exclusions or prerequisites 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?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Add or configure', implying non-destructive modification, but omits details on prerequisites (e.g., must be in edit mode), whether changes are reversible, or response 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 extremely concise: two sentences plus parameter list. The primary function and use case are front-loaded, with 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?
The description covers the basic purpose and parameters, and an output schema exists so return values are not needed. However, behavioral details like mode requirements or side effects are missing, which reduces completeness for a tool that modifies an armature.
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 significant meaning: metarig_name is explained as name of the meta-rig armature, and detail_level enumerates values: 'full', 'basic', 'eyes_only' with clarifications. This compensates well 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 tool adds or configures face rig bones on a Rigify meta-rig. It uses a specific verb ('Add or configure') and resource ('face rig bones on a Rigify meta-rig'), and distinguishes it from siblings like rigify_create_metarig which creates the entire meta-rig.
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 clear context: 'Useful when the meta-rig was created without face bones, or to adjust face rig detail.' It indicates when to use but does not explicitly mention when not to use or name alternatives among siblings.
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 tool creates a camera orbiting the target but does not disclose side effects (e.g., impact on existing cameras, reversibility, or whether it sets up keyframes). Some behavioral context is given with 'smooth rotation' but insufficient 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 a clear front-loaded purpose and a structured Args list. Every sentence adds value, 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 the tool has 5 parameters, no output schema, and no annotations, the description covers the basic functionality and parameters. However, it omits what the tool returns (e.g., success message, camera object reference) and does not address edge cases like invalid target_name or default behavior for missing parameters.
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 Arg descriptions add meaning beyond the schema, e.g., 'Object to orbit around (empty = scene center)' for target_name, and defaults are mentioned. With 0% schema coverage, this adds significant value, though units for radius/height/focal_length could be specified.
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 creates a 360° turntable camera animation around a target object, specifying the purpose ('showcasing models and avatars') and distinguishing it from siblings like 'anim_orbit' which likely handles continuous orbit rather than setup.
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 suggests usage for showcasing, but lacks explicit guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. It implies usage context but does not provide clear direction.
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 discloses the internal method (bmesh vertex displacement) and emphasizes precision and reproducibility, which adds value beyond the lack of annotations. However, it does not mention side effects on mesh attributes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, followed by a brief method note and a clean Google-style argument list. Every sentence serves a purpose 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 8 parameters and no output schema or annotations, the description covers all parameters and the core mechanism. Missing details like undoability or impact on mesh properties, but sufficient for a sculpting tool.
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 coverage, the description fully compensates by explaining each parameter's type, format (e.g., JSON array for stroke_points), range (strength, radius), and enum values for brush_type, adding critical meaning the schema lacks.
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 executes a programmatic sculpt brush stroke on a mesh using bmesh vertex displacement, distinguishing it from other sculpt tools that may depend on screen coordinates or have different methods.
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 other sculpt siblings like sculpt_brush_full or sculpt_layer_workflow. The description implies programmatic usage but fails to compare or provide selection criteria.
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 carry full burden. It does not disclose side effects such as permanent mesh modification, undoability, or potential performance impacts. Only states the basic operation.
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 short paragraphs with a clear first sentence. The args list is structured. Every sentence adds value, no filler. Front-loaded with 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?
Given 2 parameters and no output schema, description covers basic requirements but lacks details on effect on existing geometry, return value, or undo behavior. Could be more 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?
Schema coverage is 0%, so description adds meaning. It explains mesh_name as 'Name of the mesh object (must be in sculpt mode with dyntopo)' and detail_size as 'Target detail size (smaller = finer).' This goes beyond schema which only defines 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 'Flood-fill detail for uniform resolution in dynamic topology sculpting.' It specifies the action (flood-fill detail) and resource (mesh in sculpt mode with dyntopo), and distinguishes from sibling like sculpt_detail_adaptive.
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 notes prerequisites: 'must be in sculpt mode with dyntopo.' It implies use for uniform resolution but does not explicitly state when not to use or mention alternatives like sculpt_detail_adaptive.
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 carry the burden. It discloses that selection deselects others by default and that add=True allows additive selection. However, it does not cover error handling, behavior for invalid names, or return values.
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, front-loading the core purpose. No unnecessary information; every part earns its place.
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, no output schema, and low schema coverage, the description covers the basic selection behavior but lacks details on error handling, preconditions, or return values. It is adequate for a simple tool but not fully complete.
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%. The description explains the effect of the add parameter (deselects others first) and implies name is the object to select. While it adds some meaning, it lacks details on valid values or formats.
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 an object and makes it active, with a specific verb and resource. It distinguishes from siblings by being the basic selection tool, and adds context about the add parameter.
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 clear context for when to use the tool (to select an object) and explains the behavior of the add parameter. However, it does not mention when not to use it or alternative 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 fully disclose behavior. It mentions validation and build but omits side effects, permission requirements, whether it modifies files, or the build output. This leaves significant gaps for an SDK build 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 concise: two sentences and a parameter list. The main action and scope are front-loaded. Every sentence serves a purpose 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 basic task but lacks details on potential errors, runtime expectations, and prerequisites. Since an output schema exists (not shown), return values may be documented, but the description could still provide more context for a robust 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 schema has 0% description coverage and empty defaults. The description adds brief but meaningful parameter descriptions ('Unity project path', 'Root avatar GameObject name'), which compensates for the lack of schema docs. Could be more specific but suffices.
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 triggers a VRC SDK avatar build for local testing, validating the avatar and building the AssetBundle. It distinguishes from publishing tools like unity_publish_avatar.
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 specifies 'local test build, not publish', giving clear context for when to use this tool. However, it does not explicitly mention prerequisites or when not to use it, though the distinction from sibling tools is implied.
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 lists actions (copy, set rig, extract materials/textures) and parameters, but lacks details on what happens on file conflicts, folder creation, error handling, or whether it overwrites existing settings. Since no annotations are provided, the description carries the full burden and does not fully disclose 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 concise with a summary line and parameter list. Every sentence adds value. Could be slightly more structured with separate sections, but overall 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 complexity of FBX import with multiple settings, the description covers main actions and all parameters with defaults. The output schema exists, so return values are not needed. Missing details on error conditions and prerequisites, but adequate for basic 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?
With 0% schema description coverage, the description adds meaning by listing each parameter with a brief explanation (e.g., 'If empty, uses UNITY_PROJECT_PATH'). This compensates well, though some parameters like destination could benefit from format details.
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 'Import an FBX file into a Unity project and configure import settings' with specific actions (copies FBX, sets humanoid rig, extracts materials/textures). This clearly distinguishes it from generic import tools like io_import_file or other Unity-specific 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 implies usage for FBX import with specific settings but does not explicitly state when to use this tool versus alternatives like io_import_file or other Unity tools. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: auto-marking based on sharp angle, clearing existing seams, and using specific edge indices. However, it does not specify what happens when both edge_indices and sharp_angle are provided, nor does it mention prerequisites or mode requirements.
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 wasted words. The purpose is stated in one line, followed by a clean bullet-style listing of arguments. It is front-loaded and every sentence provides 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?
The description covers the main purpose and parameters, but lacks context about prerequisites (e.g., object must be a mesh with UVs), return values, mode requirements (edit vs object mode), and how it interacts with other UV tools. Some gaps remain for a fully self-contained description.
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 necessary semantics for each parameter: 'edge_indices' as specific edges, 'sharp_angle' with auto-mark behavior and default=disabled, 'clear_existing' as clearing all seams first. This adds meaning beyond the basic schema 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 tool's action ('Mark UV seams on a mesh') with a specific verb and resource. It distinguishes itself from sibling UV tools like uv_unwrap, uv_smart_unwrap, uv_pack_islands, etc., by focusing on seam marking.
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 over alternatives (e.g., when to use edge_indices vs sharp_angle, or how it interacts with other UV operations). The description lacks context for appropriate usage scenarios.
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 disclose behavioral traits. It mentions axis conversion, disabling leaf bones, and applying correct scale, but does not cover file overwrite behavior, error handling, or other 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 front-loaded purpose and bullet-style parameter list. It uses minimal words, but the structure is clean and easy to parse.
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 and presence of an output schema, the description covers essential aspects: purpose, key operations, and parameter meanings. It lacks details on failure modes or file handling, but is mostly complete for a straightforward export 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?
Parameter schema coverage is 0%, but the description lists each parameter with a brief explanation (e.g., filepath as full output path, apply_modifiers as apply before export). This adds meaning beyond the schema, which only provides 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 clearly states it exports a model as FBX with VRChat-optimized settings, specifying axis conversion, leaf bones, and scale. This is a specific verb+resource that distinguishes it from generic export tools like io_export_fbx.
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 VRChat-optimized exports, but does not explicitly state when to use it over alternatives like io_export_fbx. No exclusions or context on when not to use it 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, so the description must fully disclose behavior. It mentions 'precision' and 'without operator overhead' but omits important details: whether the tool modifies the mesh in-place, error conditions (e.g., if mesh_name doesn't exist), permission/context requirements, or side effects. The operation descriptions partially cover behavior (e.g., remove_doubles merges vertices) but are 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear introduction, then a bulleted list of operations. The listing is necessary due to the many variants, but it is somewhat long. It front-loads the main purpose. Minor redundancy: 'quads_to_tris — same as triangulate' could be omitted or merged. Overall efficient for the complexity.
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 complexity (16+ operations) and the presence of an output schema (reducing need to describe returns), the description covers most required aspects: parameters, operations, and their effects. It lacks prerequisites (e.g., mesh must exist, object selection) and error handling, but overall is sufficiently complete for an experienced user.
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, making the description the sole source of parameter meaning. The description provides detailed explanations for the 'operation' parameter (list of enums with effects and optional params) and specifies the format for 'params' (JSON). mesh_name is self-explanatory. This adds substantial 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?
Purpose is clearly stated: 'Execute precision BMesh operations on a mesh'. It specifies the verb (execute), resource (mesh), and context (BMesh direct manipulation without operator overhead). The distinct nature of low-level mesh editing is implicit, distinguishing it from sibling tools like boolean_operation or bevel_edges which are higher-level.
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 a comprehensive list of specific operations with brief explanations, which guides usage. However, it lacks explicit when-to-use vs alternatives (e.g., merge_by_distance vs remove_doubles). The context is clear but could improve by directly comparing with similar tools in the sibling list.
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 must disclose behavior. It details the cleanup pipeline (EXACT solver, dissolve degenerate, etc.) but does not reveal whether the tool is destructive, modifies in place, or any side effects on the mesh.
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: a single line for purpose, then bulleted parameter list. No filler. Informative yet 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?
With an output schema present, return values are covered. The description fully documents all four parameters and their behavior. Could mention side effects like whether it modifies the mesh in-place, but overall complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It does so by clearly explaining each parameter: mesh_name as target, cutter_name with special empty behavior, operation with enums and default, auto_cleanup with function. 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 describes a boolean operation with an automatic cleanup pipeline, distinguishing it from the simpler sibling tool 'boolean_operation'. The verb 'operation' combined with 'cleanup' makes the purpose specific.
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 usage for boolean operations needing cleanup, but does not explicitly state when to prefer this over sister tools or alternative approaches. No exclusions or context provided.
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 the description must carry the behavioral burden. It indicates the tool reports issues (read-like behavior) but does not explicitly state whether it modifies anything or has side effects. The verb 'validate' suggests non-destructive analysis, but more clarity would improve transparency.
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 and well-structured: a one-line purpose, a bullet list of reported issues, and clear parameter descriptions. 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 has only 2 parameters, no output schema, and a focused purpose, the description covers essential context. It explains what it validates and what it checks. Could mention if results are returned or printed, but not critical for 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% (signal), but the description adds detailed parameter descriptions: mesh_name as 'Name of the face mesh' and standard with allowed values and shape counts ('arkit' 52, 'unified' 70+). This meaningfully supplements the schema, which only provides 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 clearly states the tool validates blend shapes against ARKit or Unified Expressions standards. It lists specific issues reported (present/missing, empty, excessive displacement, symmetry). Distinguishes from sibling tools like ft_create_arkit_shapes or vrc_validate by focusing on validation of existing shapes.
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 checking blend shape conformity but does not provide explicit guidance on when to use this tool versus alternatives like ft_export_shape_key_report or vrc_validate. No when-to-use or when-not-to-use statements.
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 the full burden. It correctly indicates a read operation ('List materials'), but provides no additional behavioral details such as side effects, permissions, or performance. It meets the minimum but adds little beyond the name.
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 plus an arg line. No unnecessary words. Every part serves a 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?
For a simple list operation with one optional parameter and no output schema, the description is nearly complete. It explains what the tool does and how the parameter works. It could mention the return format (e.g., list of material names), but the omission is minor 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 schema has no parameter descriptions (0% coverage), but the description adds meaningful semantics: 'object_name: Object name (empty = list all scene materials)'. This clarifies the default behavior and parameter usage, compensating well for the schema gap.
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 'List' and the resource 'materials', with specific scope 'on a specific object or all materials in the scene'. This distinguishes it from other material tools like material_assign or material_create_pbr. 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?
The description implies usage when you need to view materials, either globally or per object. However, it does not explicitly state when not to use it, nor does it mention alternatives like list_materials (a sibling). Guidance is adequate but not thorough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 correctly describes the tool as a read-only list operation, but does not explicitly state lack of side effects or confirm it does not modify data. It 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 followed by a compact list of preset names. It is front-loaded and every sentence is necessary. 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?
For a simple list tool with no output schema, this description is complete enough. It lists all available presets and explains the purpose. One could argue it lacks context about the preset library source, but that is not essential for 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?
The input schema has zero parameters, so schema description coverage is effectively 100%. The description does not need to add parameter info. For a parameter-less tool, the baseline is 4, and the description meets that.
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 ('List') and identifies the resource ('material presets with descriptions'). It clearly states what the tool does, and while sibling tools like 'material_list' exist, they are distinct (listing scene materials vs. presets). This provides clear differentiation.
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 (e.g., 'material_list' or 'material_create_preset'). It relies on the name and context, but lacks explicit 'when to use' or 'when not to use' instructions.
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 effectively communicates that the tool performs analysis to detect mesh issues. It lists specific defect types, implying a non-destructive read operation. It could explicitly state that it does not modify the mesh, but the list of issues suggests analysis only.
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, front-loading the main action and then providing use cases. Every sentence adds value with 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, the description omits what the tool returns after analysis. It also fails to explain the single parameter. While the analysis scope is clear, the lack of output and parameter details leaves it incomplete for execution.
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% and the description does not mention the 'object_name' parameter or explain how to use it. The description adds no meaning to the parameter, leaving the agent without guidance on what to provide.
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 analyzes mesh quality and lists specific issues (non-manifold edges, loose vertices, degenerate faces, duplicate vertices). This distinguishes it from sibling tools like analyze_scene or validate tools by focusing on geometry defects.
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 usage context by stating it's essential for 3D printing, game assets, and VRChat avatars. However, it does not mention when not to use it or suggest alternative tools, missing explicit exclusion 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?
No annotations are provided, so the description must disclose behavioral traits. It states the tool generates a report (non-destructive), but it does not explicitly confirm it is read-only, mention prerequisites (e.g., active scene with armature), or describe error states. The output schema exists but is not referenced.
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 single sentence summarizing purpose, a bullet list of checks, and two parameter descriptions. No redundant information, and key facts are 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?
Given the presence of an output schema (which likely documents return values), the description covers the main purpose, checks, and parameters. However, it does not explain how this fits into the pipeline (e.g., prerequisites or post-validation steps), leaving minor gaps about its integration with siblings like pipeline_avatar_from_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?
With 0% schema description coverage, the description adds essential meaning: it explains each parameter's role (mesh_name to select a mesh or all, target for PC/Quest default). This compensates for the schema's lack of descriptions, though it does not address potential edge cases or format constraints.
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 produces a comprehensive go/no-go validation report for VRChat uploads, listing specific checks (mesh, armature, shape keys, etc.). This distinguishes it from siblings like mesh_quality_check or vrc_validate, which likely have narrower scopes.
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 this tool is used before uploading to VRChat, but it does not explicitly state when to use it over alternatives (e.g., vrc_validate). No when-not-to-use or alternative guidance is provided, requiring the agent to infer usage from the purpose.
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 does not explicitly declare this as a read-only operation, though it is strongly implied; additional behavioral context would improve clarity.
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 short, front-loaded sentences with no extraneous information; every word earns its place.
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 zero-parameter listing tool, the description is complete: it states purpose and enumerates presets. No output schema is 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?
Tool has no parameters; the description adds value by listing available presets, exceeding the baseline expectation.
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 lists all available render presets with descriptions, and the list distinguishes it from other render-related sibling 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 implies when to use (to get preset list) but lacks explicit guidance on 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool sets up IK pole targets, chain lengths, and floor constraints, and lists tracking modes. However, it omits behavioral traits like whether it modifies the rig in-place, requires the rig to be selected, or resets existing IK settings. This leaves 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise: two sentences plus a parameter list. The first sentence clearly states the action, and the parameter list is front-loaded. There is minor redundancy between 'Sets up IK pole targets, chain lengths, and optional floor constraints' and the parameter list, but overall it is well-structured and 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?
The tool has 3 parameters, no nested objects, and an output schema exists (but not provided). The description covers purpose and parameters adequately. However, it lacks prerequisites (e.g., a Rigify-generated rig must exist), error conditions, or post-conditions. Given the tool's complexity, this leaves some contextual gaps.
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, so the description must compensate. It explains rig_name (default), tracking_mode (with options listed), and floor_constraint (boolean, default True). It adds meaning beyond the schema by describing what each parameter does, though it could be more specific about the effect of floor_constraint (e.g., prevents floor penetration).
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 'configure' and the resource 'IK settings on a Rigify rig' with VRChat full-body tracking context. It distinguishes from sibling tools like rigify_generate_rig, which creates the rig, and rigify_to_vrc, which handles export. 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after rig generation (configure IK on a generated rig), providing clear context for when to use this tool. However, it does not explicitly exclude alternative tools or specify when not to use it, such as when the rig is not yet generated or when using different tracking systems.
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. Description explains that applying a profile changes resolution, engine, samples, etc., but doesn't mention side effects like overwriting existing settings or requiring a loaded 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?
Description is concise: two sentences plus a clear list. No fluff, front-loaded with 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?
Tool is simple with 1 param and no output schema. Description covers essential information (profile options and effects). Could mention what happens after applying, but adequate for 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?
Schema has 0% coverage for the single parameter 'profile_name'. Description compensates by listing all available profiles with details, adding meaning 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?
Description clearly states 'Apply a scene profile' and lists profile types with details, distinguishing it from sibling tools like scene_list_profiles.
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 vs alternatives. The list of profiles implies context but lacks when-not-to-use or comparison to similar tools.
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 should disclose behavioral traits. It implies a read-only listing operation, which is safe, but does not explicitly state side effects, permissions, or that no modifications occur. The safety profile is inferred but not confirmed.
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. The first sentence clearly states the action and output. The second sentence provides a helpful list of examples. 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 adequately indicates the return includes profiles and descriptions. It is sufficient for a simple listing tool with no parameters, but could be more specific about the exact format of the 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?
There are no parameters, so schema coverage is 100%. The description adds value by listing example profiles but does not need to add parameter semantics. Baseline 4 is appropriate.
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 'List' and resource 'available scene profiles', with a clear statement that it returns descriptions. It also lists example profiles, distinguishing it from sibling tools like 'scene_apply_profile'.
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 discovering profiles before applying them, but does not explicitly state when to use or not use this tool versus alternatives. No exclusions or alternative references are provided.
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 the tool creates an image if none exists, but does not detail other potential effects (e.g., overwriting existing texture) or return behavior. 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: three short sentences plus an Args list with no extraneous information. 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 no annotations or output schema, the description covers purpose, parameters, and creation behavior. It could benefit from prerequisites (e.g., UV mapping or material) and return value, but is largely adequate for a straightforward fill 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?
Schema coverage is 0%, so description adds critical details: color as RGBA JSON array, resolution as integer, image_name with auto-generation. This significantly compensates for the schema gap, though mesh_name is only named without further clarification.
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 fills a texture with a solid color and creates an image if needed. It specifies the action on a specific resource (texture) and frames it as the foundation for texture painting, distinguishing it from other 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 implies usage for initializing a texture base but lacks explicit guidance on when not to use it or alternatives. It mentions being a foundation for workflow but does not compare with sibling tools like set_texture or material_set_texture.
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 the description must carry the burden. It states the parameters but does not disclose side effects, prerequisites (e.g., object must be a mesh), or whether the operation is destructive. Acceptable but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single-line purpose statement followed by a clean list of arguments. 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?
Covers the essential information for a simple tool: purpose and parameters. Lacks details on return value or error cases, but given the tool's simplicity, it is largely 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 compensates by providing brief but clear explanations for each parameter (object_name, name, set_active). Adds meaning beyond schema defaults and 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 ('Add a new UV layer') and the target resource ('to an object'). It distinguishes from sibling tools like uv_remove_layer by specifying the additive nature.
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 vs. alternatives. However, the action is straightforward and the context (adding a layer) is implied, so it's minimally adequate.
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 cover behavioral traits. It lists parameters with brief explanations (e.g., 'use of for debugging'). However, it does not disclose whether changes affect all viewports, require a specific mode, or have side effects. Behavior is straightforward but lacks scope context.
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: a one-line intent followed by an argument list. Each parameter on its own line with a short explanation. No superfluous 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 simplicity (all booleans, no output schema), the description adequately covers the tool's function and parameters. Missing is the scope of effect (e.g., active viewport only, all viewports) and whether it toggles or sets absolutely, but overall sufficient for a configuration 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 enumerates all 7 parameters with explanations that add meaning beyond schema titles, such as 'Master overlay toggle' for show_overlays and 'useful for debugging' for show_face_orientation. This provides clear context for each boolean.
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 'Configure viewport overlays' clearly states the verb (Configure) and resource (viewport overlays). It distinguishes from sibling viewport tools like viewport_set_shading or viewport_set_view by focusing on overlays specifically.
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 controlling overlay visibility but does not provide explicit guidance on when to use this tool versus alternatives, nor when not to use it. No mention of 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?
No annotations provided, so description bears full burden. It discloses that the tool creates a circle curve and that 'fill' creates a disk, but does not mention side effects, prerequisites, or other behavioral nuances.
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 front-loaded with purpose and use case, followed by a clean parameter list. 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?
Lacks mention of return value or output, which would be helpful since no output schema is provided. Also could elaborate on how 'fill' creates a disk (e.g., fills with faces). Otherwise adequate.
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 description must compensate. It briefly explains each parameter (name, radius, location, fill), adding meaning beyond the names. Could be more detailed (e.g., location expects a 3-element array).
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 'Create a circle curve' with a specific use case 'useful as bevel object for tubes/pipes', distinguishing it from other curve creation tools like curve_create_bezier or curve_create_nurbs.
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 a specific usage context (bevel object), which helps decide when to use. However, it does not explicitly state when not to use or contrast with alternatives.
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 mentions defaults and a critical parameter but does not disclose side effects (e.g., whether scene is modified, safety, or reversibility), leaving 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 well-structured: purpose sentence, defaults line, critical note, then parameter list. It is concise with no redundant information, front-loading key details.
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 most parameters with usage tips, but lacks mention of export process limitations or return behavior. Acceptable given no output schema.
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?
All 8 parameters are explained with context (e.g., 'add_leaf_bones: Add leaf bones (FALSE for VRChat!)', 'axis_forward: Forward axis (-Z for Unity)'), compensating 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 'Export to FBX format (standard for Unity/VRChat/game engines)' specifying the verb 'export' and the resource 'FBX format', distinguishing it from siblings like io_export_gltf and io_export_obj.
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 specific usage context: 'Default settings are optimized for VRChat/Unity workflow' and a critical note 'add_leaf_bones=False is critical for VRChat', but does not explicitly compare to alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes pipeline steps and parameter defaults but lacks explicit disclosure of side effects (e.g., scene modification, object creation, whether it can be undone). No annotations to compensate.
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 introductory sentences followed by a concise parameter list. No wasted words, front-loaded with pipeline summary.
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 pipeline steps and parameters adequately. Output schema exists, so return value explanation is not needed. Could be improved by noting prerequisites or error handling.
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?
Each parameter is described with defaults and options (e.g., arkit_method enum, export_path default), adding meaning beyond the schema which has no property 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?
Clearly states the full avatar pipeline from mesh to FBX with specific steps (validate, armature, weight paint, visemes, ARKit, export). Distinguishes from sibling pipelines that focus on specific tasks.
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 comprehensive use but no explicit when-to-use or alternatives compared to other pipeline tools. Agent must infer from name and 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?
With no annotations, the description carries full burden. It details shape-specific parameters but does not disclose behavioral traits such as whether it overwrites existing objects, requires an active selection, or handles errors. The BMesh mention provides some insight but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the purpose, and uses bullet points for shape options. Every sentence adds value without unnecessary elaboration.
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 complexity with multiple shape types and parameters, the description covers the essential information. It includes all shape options and their parameters. The absence of return value explanation is mitigated by the presence of an output schema.
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 thoroughly explains all three parameters: shape with enumerated options and their required sub-parameters, name as object name, and params as JSON. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('generate') and resource ('procedural geometry using BMesh'), and explicitly distinguishes from basic primitives by noting it creates more complex shapes. This differentiates it from sibling tools like create_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 provides some context by stating it creates more complex shapes than basic primitives, implying use for advanced geometry. However, it lacks explicit when-not-to-use guidance or references to alternative tools like bmesh_operation.
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 burden. It lists parameters and defaults but does not disclose side effects, persistence, or dependencies (e.g., requires a scene, does not trigger rendering). Moderate transparency.
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?
Structured as a docstring with Args list, front-loads the main purpose in one sentence. Every line adds value and is properly scoped.
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 all parameters with meanings and defaults. Could mention that this sets scene output properties and is a prerequisite for rendering, but overall complete given tool complexity and lack of output schema.
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 input schema: explains filepath syntax (// for relative), enumerates allowed file_format values, color_mode, color_depth, compression range 0-100, quality 0-100. 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 'Configure render output path and format' clearly states the verb (configure) and the resource (render output path/format), distinguishing it from sibling tools like configure_render, render_set_camera, or render_set_world that handle other render settings.
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., configure_render). The purpose is clear but does not specify when-not or provide direct comparisons.
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. Description discloses three methods (quadriflow, voxel, shrinkwrap) with their outputs and use cases, plus target face count and extra params. Does not mention side effects or permissions, but is fairly 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?
Description is concise with a clear header and structured parameter list. Every sentence adds 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?
Output schema exists, so return values documented elsewhere. Description covers purpose, all parameters, and methods. Lacks error conditions or prerequisites, but is sufficient for typical use. Complexity is moderate.
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 explains all 4 parameters: mesh_name, method (with examples), target_faces (default), and params (with per-method examples). Adds significant value 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?
The description clearly states 'Retopologize a mesh for clean animation-ready topology' with a specific verb and resource, and parameter details differentiate it from siblings like 'remesh' and 'decimate'.
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 vs alternatives like 'remesh' or 'decimate'. The purpose is implied but not contrasted with related tools.
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 provides some behavioral insight (analyzes bounding box, key landmarks, two methods) but lacks details on side effects, required permissions, or whether it modifies the mesh. It does not contradict annotations since none 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 and well-structured: a single sentence for purpose, then a clear bullet list for parameters. 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 presence of an output schema (not shown) and the clear parameter descriptions, the description is fairly complete. However, it could mention limitations or prerequisites (e.g., metarig must be correctly structured) to fully guide the agent.
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: each parameter listed with default values and explanations, including the 'method' parameter with explicit options ('proportional' vs 'snap'), adding 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 'Auto-fit a Rigify meta-rig to match a target mesh's proportions' with specific verbs and resources, and it distinguishes from sibling tools like 'rigify_create_metarig' and 'rigify_generate_rig'.
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 'rigify_configure_ik' or manual adjustment. The context is implied but not stated, leaving the agent to infer 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 mentions adding a component and configuring defaults but does not disclose side effects like overwriting existing descriptors, required GameObject hierarchy, or error conditions. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear structure: a brief purpose statement followed by a parameter list. Each sentence is informative and avoids 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 5 parameters and no output schema shown (though context indicates it exists), the description covers the essential setup details. However, it lacks information about return values or success/failure indications. Still, it is mostly complete for a setup tool.
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 provides detailed explanations for all 5 parameters, including defaults and acceptable values (e.g., view_position defaults to '0,1.6,0.3', lip_sync_style options). This significantly adds value beyond the schema alone.
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 adds VRC_AvatarDescriptor to a GameObject and configures viewpoint, lip sync, and eye tracking defaults. It distinguishes from sibling tools like unity_setup_contacts or unity_setup_expression_menu by specifying the exact component.
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 implies usage for initial avatar setup but does not explicitly state when to use this tool versus alternatives. Given siblings like vrc_setup_visemes and unity_setup_physbones, the description could provide more guidance on when to choose this tool.
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 implies a non-destructive check by using words like 'finds,' but it does not explicitly confirm read-only behavior or potential side effects. With no annotations provided, the burden is on the description, and it falls short of full transparency.
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 bullet list of findings. Every sentence adds value, and the most important information (purpose) 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 checking tool with one parameter and an output schema (though not detailed), the description covers the essential aspects. It could mention whether the tool modifies anything or provide more details on output format, but it is largely complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides type and default for mesh_name. The description adds critical meaning: 'Target mesh. If empty, checks all meshes.' This explains the parameter's effect beyond the schema, fully compensating for the 0% schema 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 checks vertex weights for VRChat compatibility, with specific examples of what it finds (unweighted vertices, excessive bone influences, missing vertex groups). This is a specific verb+resource that distinguishes it from sibling tools like vrc_validate or mesh_quality_check.
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 context (VRChat compatibility) but does not explicitly state when to use this tool versus alternatives such as vrc_validate or vrc_fix_model. It lacks exclusionary guidance or comparison to siblings.
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 that it only places bones and generates JSON, not adding Unity components, which sets accurate expectations. No annotations exist, so description carries full burden; it lacks disclosure of side effects like modifying existing bones.
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, front-loaded purpose, followed by clear parameter list. No wasted sentences; every part is informative.
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, parameters, behavior, and output schema. Minor gap: doesn't specify coordinate space for bone placement (local vs world). Otherwise complete for a tool with good annotations and output schema.
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 coverage, the description provides thorough parameter explanations including examples and valid values for preset and custom_contacts, compensating fully 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 clearly states the tool sets up VRChat Contact Senders and Receivers by creating marker bones and generating Unity configuration JSON, distinguishing it from sibling tools like vrc_setup_gestures or vrc_setup_physbone_chain.
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, such as unity_setup_contacts, nor prerequisites like requiring an armature. The description only details parameters 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.
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 shape keys are created, renamed, mapped, or blended depending on mode, but does not disclose potential side effects like overwriting existing shape keys or prerequisites (e.g., mesh must have certain base shapes). The behavior is partially transparent but could be more explicit about risks.
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 with a clear opening sentence followed by parameter explanations in a bullet-like format using dashes. It is informative but not overly verbose. Minor improvements could include grouping mode descriptions more compactly.
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 presence of an output schema (context indicates it exists), the description does not need to explain return values. The tool has 3 parameters (0 required) and the description covers their semantics and defaults. It feels complete for the use case, though error handling or validation notes are absent.
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%, yet the description effectively explains all three parameters: mesh_name (defaults, target mesh), mode (four values with specific behaviors), and source_mapping (JSON mapping, usage depends on mode). This adds significant value beyond the minimal schema, though examples for source_mapping could be clearer.
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: setting up VRChat viseme shape keys for lip sync on a mesh. It clearly distinguishes from sibling tools (e.g., vrc_setup_eye_tracking, vrc_setup_gestures) which have different functions.
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 details four modes (template, rename, from_mmd, from_base_shapes) with concise explanations of each. While it doesn't explicitly state when to use each or mention alternatives, the mode descriptions imply the appropriate use cases. Some guidance on when not to use certain modes would improve clarity.
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 provided, the description carries the full burden. It discloses that the addon is automatically installed, enabled, and the TCP server started, with connection verified before returning. This provides good 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: main purpose in the first line, then parameter details, then additional setup steps. 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?
The description covers launch behavior, parameter roles, and verification step. While no output schema is provided in the input, the description hints at return behavior. For a launch tool with many siblings, it is sufficiently 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 input schema has 0% description coverage, meaning the schema provides no parameter descriptions. The tool description compensates by explaining each parameter: file_path (.blend file), port (default 9876), blender_path (override). 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 launches Blender with Copilot addon auto-started, using specific verbs and resources. It distinguishes itself from sibling tools like blender_new_file or blender_open_file by focusing on launching the application itself.
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 launching Blender but does not explicitly state when to use this tool versus alternatives like blender_new_file or blender_quit. There is no guidance on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses error when file never saved and no path. However, does not mention overwriting behavior on success, nor confirmation or side effects. No annotations to supplement.
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 succinct sentences that convey essential information without redundancy or unnecessary detail.
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 key scenarios: save and save-as. Lacks detail on return value or explicit behavior for normal save (overwrite). But adequate for a simple 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?
Adds meaning to the single parameter file_path by explaining its effect (Save As vs normal save). Compensates 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 the action: 'Save the current Blender file'. Distinguishes between save and save-as modes, and mentions error case. Distinct from siblings like blender_open_file.
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?
Explains two usage scenarios (with file_path for Save As, without for normal save) and error case. Implicitly guides when to use, but no explicit 'when not to use' or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It describes the effect (moving objects to center) but does not disclose whether the operation is destructive or reversible, nor does it mention any side effects like changes to object scale or rotation.
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 fluff. The first sentence communicates the primary action, and the second covers the parameter's default behavior. Perfectly 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 tool with one optional parameter and no output schema, the description is sufficiently complete. It explains the core functionality and parameter usage. Minor gap: no mention of return value, but contextually unnecessary.
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 explains the 'names' parameter's effect: if omitted, all objects are centered. This adds meaningful context beyond the bare schema type definition.
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 ('Move objects') and clearly states the result ('collective center at world origin'). It distinguishes from siblings like 'align_objects' and 'origin_set' by focusing on group center rather than individual transforms.
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 when to use (centering objects) and the behavior when no names are given (centers all objects in the scene). However, it does not explicitly mention when not to use or suggest alternative tools like 'origin_set' for individual objects.
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 critical behavior: no rendering occurs, denoise is Cycles-specific, resolution format is [width, height], and transparent_bg and color_management details. This adds meaningful context beyond parameter names, though it omits effects of samples and use_gpu.
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 front-loaded with the primary action. Each sentence adds necessary detail without redundancy. No filler or vague language.
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 7 parameters with 0% schema coverage, the description covers most critical parameters (5 of 7) and explains their impact. It lacks detail on samples and use_gpu, and does not mention return value or side effects, but for a configuration tool, the completeness is adequate.
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 resolution format (array of two ints), denoise (enables AI denoising in Cycles), transparent_bg (boolean), and color_management (object with view_transform, look, exposure, gamma). This adds significant value, but it does not describe samples or use_gpu, leaving gaps.
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: 'Configure render settings without rendering.' It specifies the supported engines (CYCLES, BLENDER_EEVEE_NEXT) and key settings, making the action unambiguous. It effectively distinguishes from sibling tools that actually perform rendering.
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 context by stating 'without rendering,' suggesting this tool is for setup, not execution. However, it does not explicitly provide when-to-use guidance, list alternatives, or mention prerequisites. The guidance is implied but not robust.
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 that the tool auto-detects landmarks and creates vertex groups by analyzing topology, and mentions the optional armature hint. However, it does not disclose side effects (e.g., whether existing vertex groups are overwritten), error handling, or performance implications 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 concise: two sentences for purpose and one sentence for each parameter. It front-loads the action and uses clear, direct language with 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 the tool's complexity (auto-detection of facial landmarks) and lack of output schema, the description covers the key regions created and their purpose for ARKit. It could be improved by specifying vertex group naming conventions or that the mesh is modified in place, but it is largely sufficient.
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 provides useful details for both parameters: mesh_name is the face/head mesh, armature_name is optional for bone hints. This adds beyond the bare schema, though the armature hint mechanism is not fully explained.
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 vertex groups' and the specific resource 'face regions', listing eye loops, mouth loops, brow ridges, cheeks, nose, jaw. It distinguishes from sibling tools like ft_create_arkit_shapes and ft_setup_eye_tracking_full by specifying it sets up prerequisite vertex groups.
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 that these vertex groups are required for ARKit blend shape generation, implying use before ft_create_arkit_shapes. However, it does not explicitly state when not to use it or provide alternatives for already-existing vertex groups.
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 exist, so the description fully carries the burden. It states the tool returns detailed info including parameter names, types, defaults, and valid ranges. This is a clear behavioral disclosure for a read-only query.
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 short sentences, front-loaded with the main purpose. No wasted words. The second sentence adds necessary detail about the return content.
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 sufficiently describes the return data (modifier types with descriptions and parameters). It is complete for a simple listing tool without complex outputs.
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 zero parameters. With no schema description coverage issue, the baseline is 4, and the description adds no parameter info (none needed).
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 'list all supported modifier types with descriptions and parameters', which is a clear and specific verb-resource combination. It distinguishes from sibling tools like modifier_list which list modifiers on objects.
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 other listing tools (e.g., modifier_list, material_list). Usage is implied as informational, but 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the tool polls status and when task is done, but lacks details on idempotency, poll intervals, rate limits, or what the response contains when not yet done. This leaves ambiguity for repetitive polling.
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 concise sentences covering purpose, completion condition, and parameter guidance. No superfluous words, front-loaded with action. Every sentence earns its place.
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 polling tool with no output schema and no annotations, the description covers the essential points but could be enhanced by describing the return format or typical polling behavior. It is sufficient 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?
The parameter schema has 0% description coverage, but the description adds meaningful context: clarifies that subscription_key is for MAIN_SITE and request_id for FAL_AI, and implies they are alternatives. This compensates well 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 the tool polls Hyper3D Rodin generation status, specifies completion condition ('all statuses are Done'), and identifies parameters from the generate step. This distinguishes it from siblings like 'get_hyper3d_status' and '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 indicates when to use the tool (after generate step) by referencing subscription_key or request_id from that step. However, it does not explicitly explain when not to use it or compare with alternative polling tools.
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, but the description clearly indicates a safe read operation without side effects. It does not elaborate on return format or potential empty states, but the basic transparency is high for a getter.
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 redundant words. Every part 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?
For a simple getter with no parameters, the description is mostly complete. However, it lacks information about the output format or whether it returns all settings, which would be helpful given no output schema.
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 zero parameters, so the schema covers everything. The description adds value by listing which settings are retrieved, giving context beyond the empty 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 retrieves current render settings and lists specific fields (engine, resolution, samples, output, camera), making it distinct from other render tools that modify or apply settings.
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 use for reading settings but does not explicitly state when to use this tool versus alternatives like render_image or render_set_camera. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the tool generates a control rig with IK/FK and custom shapes, and mentions auto-parenting. But it does not indicate whether the meta-rig is modified or destroyed, whether it works on selected objects, or any side effects. More details on post-rigging actions would improve transparency.
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 efficiently structured with two concise sentences followed by a clear parameter list. It is front-loaded with the primary purpose and avoids any redundant or irrelevant 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?
Given that an output schema exists (thus return value description is not needed), the description covers the main action and parameter usage. However, for a complex rig generation tool, it would benefit from mentioning prerequisites (e.g., an existing meta-rig armature) and any assumptions about the scene state. Overall, it is mostly complete for the agent to understand the tool's role.
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%, meaning the JSON schema has no property descriptions. The description's 'Parameters' section provides meaningful explanations for both parameters: metarig_name (name and default) and parent_to_mesh (purpose and behavior). 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 'Generate the final production rig from a Rigify meta-rig' and explains it creates a full control rig with IK/FK switches and custom shapes. This specific verb-resource pairing distinguishes it from siblings like rigify_create_metarig and rigify_fit_metarig.
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 usage as the final step after creating and fitting a meta-rig, and the parent_to_mesh parameter hints at a specific use case. However, it lacks explicit guidance on prerequisites (e.g., the meta-rig must exist in the scene) or when not to use it. No 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?
With no annotations, the description effectively discloses key behaviors: duplication of DEF-bones, creation of a clean hierarchy with Unity Humanoid naming, exclusion of non-deform bones, and readiness for FBX export. It does not, however, detail prerequisites (e.g., valid Rigify rig), error conditions, or the exact output format (e.g., whether a new object is created). The presence of an output schema mitigates some omissions.
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 paragraphs. The first paragraph states the purpose and high-level behavior, and the second lists parameters with defaults. No redundant or irrelevant sentences. Front-loaded with the core function.
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?
Despite low complexity, the description covers the tool's primary function and both parameters. It assumes familiarity with Rigify and Unity Humanoid naming. It does not clarify whether the original rig is modified or a new armature is created, nor does it mention error handling. Given the output schema exists, the description is reasonably complete for a specialized conversion 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%, but the description includes explicit parameter documentation: rig_name (default 'rig') and export_name (if empty, defaults to '{rig_name}_vrc'). This adds meaning beyond the schema's type-only definitions. However, it could further explain constraints or use cases for each parameter.
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: 'Convert a Rigify-generated rig to VRC-compatible bone naming.' It specifies the action (conversion), resource (Rigify rig), and target (VRC bone naming). It further explains the method: duplicating DEF-bones with Unity Humanoid naming for FBX export, which distinguishes it from related tools like rigify_generate_rig or vrc_rename_bones.
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 after generating a Rigify rig by referencing 'Rigify-generated rig' and the duplication/renaming process. However, it does not explicitly state when to use this tool vs. alternatives such as vrc_create_humanoid_armature, vrc_rename_bones, or other rigify tools. 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.
Behavior3/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 explains density and color effects but does not clarify whether fog replaces existing fog, default behavior, or value ranges.
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 concise sentences: first specifies the action, second details parameters. No wasted words, front-loaded with 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?
For a simple add-fog tool with no output schema, the description is largely complete. It could mention where fog is added (world settings) but is sufficient for its complexity.
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 'Density controls thickness' and 'Color is [R,G,B] for emission tint', adding meaning beyond the schema's 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 'Add volumetric fog to the world', identifying the specific action and resource. It distinguishes from siblings as there is no other fog-related tool.
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 specifies a prerequisite: 'Requires Cycles or EEVEE for volume rendering.' Although no alternatives exist, it provides clear context for when the tool is applicable.
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 discloses the supported shaders and the properties_json format, which is helpful. However, it does not describe whether the tool modifies the material in place, creates a new material, requires any prerequisites, or what side effects may occur (e.g., updating existing properties).
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: one sentence for purpose, followed by a bulleted list of parameters with clear labeling and examples. No redundant or unnecessary text.
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?
An output schema exists but is not visible; assuming it covers return values, the description lacks information on prerequisites (e.g., whether the material must exist, whether the Unity project is open) and whether the tool can create a new material or only modify existing ones. This leaves some gaps for an agent to infer.
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 fully compensates. It provides detailed explanations for all four parameters: project_path, material_name, shader_name (with options and default), and properties_json (with format and per-shader examples). 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 it configures shader properties on a Unity material and lists supported shaders (Poiyomi, lilToon, UTS2, Standard). This distinguishes it from sibling tools like material_assign or material_create_pbr, which handle different material aspects.
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 usage for setting shader properties on a material and explains the parameter format, including examples. However, it does not explicitly state when not to use this tool or mention alternatives, such as setting textures via material_set_texture or color via set_material_color.
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 of behavioral disclosure. It describes the detection and normalization process and mentions scale_mode options. However, it does not explicitly state whether the fix is destructive or reversible, or what happens on failure. Adequate but not highly 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 and front-loaded: the first sentence states the high-level purpose, followed by a crucial usage hint ('Run this BEFORE...'), then a parameter list. Every sentence contributes 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 that the tool has 4 parameters (none required) and no annotations, the description covers the main use case, parameter explanations, and ordering. It does not address error conditions, edge cases (e.g., missing bone), or prerequisites beyond the sibling. However, the output schema exists to document return values. Mostly complete but missing some edge-case detail.
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%, meaning the JSON schema has no parameter descriptions. The description compensates by explaining each parameter in plain language with examples (e.g., target_bone: "e.g., 'Left foot'"; scale_mode: "'auto' (detect and fix), 'match_armature', 'none'"). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Auto-detect and fix misaligned accessories (shoes, hats, etc.) by comparing their bounding box to the target bone position and normalizing scale/rotation.' It specifies the verb (auto-detect and fix), resource (accessories), and method, and distinguishes from sibling vrc_attach_accessory by giving ordering instruction.
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 guidance on when to use this tool: 'Run this BEFORE vrc_attach_accessory.' It gives clear context but does not state exclusions or alternatives beyond the sibling. No other when-not-to-use info.
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, so description carries full burden. Lists specific checks performed, implying it is a read-only validation. Could explicitly state it does not modify the model.
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; lists checks concisely and parameter info separately. No wasted words.
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?
Output schema exists but not described; agent doesn't know what the tool returns (pass/fail, list of issues). Missing important context for 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 coverage is 0% but description provides clear explanations: armature_name targets armature (defaults to first), target specifies 'pc' or 'quest' with default. Adds value 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 it runs a comprehensive pre-export checklist for VRChat avatar, listing specific checks like transforms, bone naming, visemes, etc. Distinct from siblings like vrc_validate or vrc_check_weights.
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?
Implicitly indicates it is a pre-export tool by name and description. However, no explicit guidance on when to use vs siblings or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 output (menu structure + parameter list with memory usage) and that the result is imported into Unity. It does not contradict any annotations (none provided). However, it could mention whether the tool is read-only or if it requires a specific project state.
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 purpose and then parameter details. The examples are necessary but make it slightly lengthy. Overall, every part earns its place, and it is well-organized 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 complexity (2 parameters, one complex JSON) and the presence of an output schema, the description covers purpose, parameter format, and output. It lacks mention of prerequisites (e.g., need a VRChat project) or error handling, but 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?
The input schema has 0% description coverage, but the description provides extensive detail: JSON array format for items with examples of each type, default for menu_name, and valid types. This fully 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 tool generates a VRChat Expression Menu configuration (JSON blueprint), specifying a specific verb and resource. It is distinct from sibling tools like unity_setup_expression_menu which handle importing into Unity, or vrc_generate_animator which targets animators.
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 used for generating expression menu blueprints, but does not explicitly state when to use it versus alternatives (e.g., unity_setup_expression_menu). No guidance on prerequisites or exclusions is 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.
Behavior3/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 axis conversion, transform application, and model stats reporting, but does not mention side effects like adding objects to the scene, error handling, or permissions. Some behavioral context is provided but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence and a bullet list covering four parameters. No unnecessary words, each 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 moderate complexity and the presence of an output schema, the description covers the core functionality well. It doesn't detail error scenarios or what happens to existing scene content, but the essential behavior is clear.
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 lists all four parameters with meaningful explanations, including the enum-like values for fbx_preset and defaults for boolean parameters. This adds significant value beyond the schema 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 'import' and the resource 'model file', lists supported formats (FBX/VRM/OBJ), and mentions the optional auto-fix for VRChat. This distinguishes it from sibling tools like vrc_fix_model and io_import_file.
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 when to use (initial import for VRChat) by specifying supported formats and the auto-fix option, but does not explicitly state when not to use or provide alternatives. It offers clear context for its intended use.
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 provided, the description carries the full burden. It discloses a critical behavioral trait: 'Discards unsaved changes'. This informs the agent of destructive behavior. Could be enhanced by explaining if the current file is auto-saved or closed, but sufficient for a simple 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?
Two short sentences, directly stating purpose and critical side effect. No fluff. Front-loaded with the action.
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 tool with no parameters and no output schema, the description covers the essential purpose and behavioral consequence. It is complete for the agent to understand what it does.
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%. The description adds no parameter info, which is appropriate. Baseline for zero parameters is 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 uses a specific verb ('Create') and resource ('new blank Blender file'). It clearly distinguishes from siblings like blender_open_file (which opens existing files) and blender_save (which saves current file).
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 when starting fresh, but does not explicitly contrast with alternatives like blender_open_file or blender_save. It mentions discarding unsaved changes, which is a caution, but no explicit 'when to use' vs. '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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully bears the burden of behavioral disclosure. It explains that vertices are displaced in a face region, shape keys are created if missing, and parameters like direction and intensity affect the outcome. It does not mention required mode (e.g., sculpt mode) or potential side effects, but overall provides good transparency.
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 (3 sentences + bulleted Args) and front-loaded with the primary purpose. Every sentence adds value, and the structured Args list is easy to parse.
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?
With no output schema, the description omits what the tool returns (e.g., success indicator). It covers input semantics well but lacks info on error conditions or return value. For a 6-parameter tool, it is mostly complete but missing return behavior.
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 no descriptions for its 6 parameters, so the description's Args section adds full value. Each parameter (mesh_name, shape_key_name, region, direction, intensity, falloff) is explained with values and constraints, enabling correct invocation.
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 performs 'AI-guided shape key sculpting via vertex displacement' to 'create or refine a blend shape'. It uses a specific verb-resource pair and distinguishes from sibling tools like ft_combine_shape_keys and ft_mirror_shape_key.
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 notes the tool 'can be called multiple times to build up complex expressions', implying iterative use. However, it does not explicitly state when not to use it or provide alternative tools for different scenarios, leaving the agent to infer usage boundaries from 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?
No annotations provided, so description carries full burden. It discloses behavior conditional on the name parameter but does not state if the tool is read-only, potential performance implications, or what 'tree' means structurally. Lacks full 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences, front-loaded with purpose, no filler. 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?
For a simple tool with one optional parameter and no output schema, the description covers essential behavior. It could mention the return format (e.g., tree structure or list) but is otherwise adequate.
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% (only 'name' defined). The description perfectly compensates by explaining the effect of the name parameter: if given, returns subtree; otherwise returns all root objects and children. Adds full 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?
Description clearly states 'Get the parent-child hierarchy tree.' and distinguishes two use cases based on the optional name parameter: subtree vs. root objects. This specific verb+resource combination differentiates it from sibling tools.
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?
Implied usage is clear: use when needing hierarchy information. It provides two explicit scenarios (with/without name) but does not explicitly state when not to use or mention alternatives. Siblings don't directly compete, so no strong downside.
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 bears full responsibility. It states the action but lacks details on return format, error handling, or side effects. However, the tool is simple and read-only, so a score of 3 is adequate.
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, each adding value. The first states the purpose, the second provides useful context. No wasted words.
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 zero parameters and no output schema, the description is complete. It explains what the tool checks and why it matters, covering all necessary 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?
There are no parameters, so the description does not need to elaborate. Baseline score 4 applies as schema coverage is 100% and no param info is required.
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 name and description clearly indicate checking if PolyHaven integration is enabled. The additional context about what PolyHaven provides helps distinguish it from related tools like download_polyhaven_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking integration status, but does not explicitly mention when to use or alternatives. Still, the context is clear enough for a straightforward 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 are provided, so the description carries the full burden. It discloses that the background becomes a solid color with a given RGB and strength, but does not mention side effects (e.g., clearing other world settings) or whether the change is reversible. For a simple mutation, this is 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 two sentences long, front-loaded with the primary action, and every sentence adds value. There is no waste, and the structure is optimal for quick understanding.
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, the description covers the essential information: what it does, parameter usage, and a use case. It lacks details about default values (e.g., default color if null) but that is partly in the schema. No output schema exists, so return format is not needed. It is complete enough for safe 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?
The description adds clear meaning to both parameters: 'Color is [R,G,B] (0-1 range)' explains the array structure and value space, and 'Strength controls brightness' clarifies the purpose of the strength parameter. This fully compensates for the 0% schema coverage indicated.
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: 'Set the world background to a solid color.' It specifies the resource (world background) and the result (solid color). The added note 'Good for studio-style renders' provides context that differentiates it from sibling tools like set_world_hdri or set_sky_texture.
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 a usage hint: 'Good for studio-style renders,' indicating when this tool is appropriate. However, it does not explicitly state when not to use it or name alternative tools, but the context is sufficient for a simple 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 reveals key behavior: it can either add to current position (relative) or set absolute position, and units are Blender units (meters). It does not disclose error handling or side effects, but the core behavior is 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, zero waste. The main purpose is front-loaded, and conditions are stated clearly. Every sentence adds value without repetition.
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 and no output schema, the description covers the main points. However, it omits prerequisites (e.g., object must exist) and error behavior. For a tool with 5 parameters and no annotations, more context on return effect and limitations 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?
Schema description coverage is 0%, so the description must compensate. It explains the 'relative' parameter, the units for x/y/z, and the default behavior. While 'name' is not described, the description adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Move an object,' which specifies the action (verb) and resource (object). It distinguishes relative vs absolute positioning, and the name alone 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use relative vs absolute positioning via the 'relative' parameter. However, it does not explicitly guide when to choose this tool over alternatives like batch_transform or align_objects, though the name implies translation.
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 that the tool bakes materials, re-maps UVs, and reduces material count. However, it does not mention potential side effects (e.g., overwriting UVs, creation of new image textures) or require permissions. This 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, with the purpose front-loaded in the first sentence, followed by parameter details. Every sentence adds value, no redundancy or fluff.
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 use case. It does not mention return values, but an output schema exists. For a modestly complex tool (3 parameters, no enums), it is reasonably 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 adds clear parameter explanations: mesh_name (target mesh, default fallback), atlas_size (resolution, with Quest recommendation), output_path (save location). This adds significant meaning beyond the schema defaults 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 bakes multiple materials into a single texture atlas and re-maps UVs to reduce material count for VRChat performance. It uses a specific verb ('bake') and resource ('texture atlas'), and the purpose is distinct from sibling bake tools like bake_ao or bake_normal_map.
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 combining materials for VRChat performance but does not explicitly state when to use this tool over alternatives (e.g., other bake tools or merge_materials). No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes the main action but omits details like whether existing shape keys are overwritten, if the operation is reversible, or what the mesh state is after creation. Moderate transparency.
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 line for the purpose followed by a clear bulleted list for parameters. No fluff, every sentence adds value. Well-structured and concise.
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 could be more complete. It doesn't state that the tool adds 52 shape keys to the specified mesh, nor how it handles pre-existing shape keys. Lacks clarity on the exact outcome for the mesh.
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 must add meaning. It does so thoroughly: explains mesh_name as requiring vertex groups for procedural mode, and describes all three method options with their behaviors and use cases. 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 states 'Create all 52 ARKit blend shapes on a face mesh.' This is a specific verb (create) and resource (ARKit blend shapes on face mesh). It clearly distinguishes from sibling tools like ft_combine_shape_keys or ft_create_unified_expressions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains three methods (procedural, template, from_existing) with guidance on when to use each: procedural requires vertex groups, template always works for production, from_existing maps existing keys. It also mentions prerequisites for procedural mode.
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 handle behavioral disclosure. It describes the mirroring action and auto-generation of target shape, but does not explicitly state that it creates a new shape key or whether it modifies existing data. The safety profile is partially conveyed but lacks explicit mutation 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 very concise—6 lines with a clear purpose statement, a usage example, and parameter details. Every sentence adds value, and the structure is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 params, no output schema, no annotations), the description is complete: it explains purpose, usage, parameter semantics, and provides an example. It is self-contained and leaves no obvious gaps for an agent to misuse.
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 to all four parameters beyond the schema titles: mesh_name is explained, source_shape and target_shape are clearly described with auto-generation behavior, and axis gets an explanation of default and options. Schema coverage is 0%, so 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 the tool mirrors a shape key from one side to another with an explicit example (Left→Right). It uses a specific verb and resource, and the purpose is distinct from siblings like ft_sculpt_shape_key or ft_combine_shape_keys.
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 a concrete usage scenario ('Sculpt mouthSmileLeft, then mirror to mouthSmileRight automatically'), making it clear when to use. However, it does not explicitly state when not to use or mention alternative tools by name.
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 accurately indicates a read operation (getting a thumbnail) with no side effects. It does not describe potential limitations or return format, but for a simple tool this is adequate.
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 concise sentences with no redundant information. Every word contributes to the purpose and usage guidance.
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 essential purpose and usage context. It does not detail the output (e.g., image URL), but that is acceptable 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?
With schema coverage at 0%, the description adds meaning by stating the tool operates 'by UID', clarifying that the sole parameter 'uid' is the model's identifier. This compensates for the lack of 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 it retrieves a preview thumbnail by UID, with the verb 'Get' and resource 'preview thumbnail of a Sketchfab model'. It distinguishes from sibling tools like 'download_sketchfab_model' and 'search_sketchfab_models' by specifying a different action and usage 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?
Explicitly advises to 'Use before downloading to visually confirm the model', providing a clear workflow context. However, it does not mention when not to use or list alternatives, so some guidance is missing.
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 lists operations (e.g., 'gradient_along_chain', 'transfer_weights') and their parameters, implying modification of vertex weights. However, it does not disclose side effects, permission requirements, or the fact that it permanently alters mesh data. The behavioral impact is understandable but 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 brief yet comprehensive: an initial purpose sentence followed by a well-organized list of operations with nested parameters. Every line adds value, no redundancy. The structure is easy to scan and interpret.
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 complexity (multiple operations with varied parameters) and the schema's 0% coverage, the description provides complete guidance for all operations. An output schema exists (per context) so return values need not be explained. The description leaves no ambiguity about how to invoke each operation.
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% coverage with only names and types for 'mesh_name', 'operation', and 'params' (string). The description adds exhaustive semantic meaning by enumerating all operations and their specific sub-parameters (e.g., 'chain_root', 'falloff', 'threshold', 'group', 'factor'). This completely compensates 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'Precision vertex weight operations' with 'far more control than auto-weights.' It distinguishes itself from sibling tools like 'armature_auto_weight' and 'vrc_auto_weight' by emphasizing manual precision. The verb 'paint' and resource 'vertex weights' are specific.
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 usage when advanced control is needed beyond auto-weights ('Far more control than auto-weights'). However, it does not explicitly state when not to use or list alternatives beyond the one comparison. It provides clear context for use but lacks 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 carries the full burden. It discloses the attempt-fallback strategy (CLI vs GUI) and prerequisites. However, it does not mention side effects (e.g., project state changes, file creation) or authentication details beyond 'logged-in session'.
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 two clear sections: tool behavior and parameter list. It avoids fluff. Some minor redundancy (e.g., 'Publish avatar to VRChat' could be merged with the following sentence), but otherwise 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 tool's complexity and the presence of an output schema (not shown), the description covers key aspects: purpose, prerequisites, fallback behavior, and all parameters. It is sufficient for an agent to invoke the tool, though more detail on side effects would enhance 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 description adds substantial meaning beyond the bare schema (0% coverage) by listing each parameter with its purpose, default values, and possible values (e.g., release_status: private/public). 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 tool publishes an avatar to VRChat, using a specific verb and resource. It distinguishes itself from sibling tools like unity_build_avatar or vrc_export_fbx by focusing on the final publish step. Prerequisites and fallback behavior further clarify its unique role.
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 specifies prerequisites (VRC SDK and logged-in session) and outlines the publish flow (CLI first, fallback to GUI instructions). While it does not explicitly exclude alternatives, the context is clear enough for an agent to infer when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses the key behavioral trait: quitting with optional save. It explains that setting save=True saves before quitting, implying that save=False quits without saving. It does not elaborate on graceful behavior, but the description is sufficient for this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: one sentence that immediately states the action and the key parameter usage. Every word earns its place, and there is zero waste. It is front-loaded with the primary 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 the tool's simplicity (one parameter, no required fields, no nested objects), the description covers the essential information: what it does and how to use the parameter. It does not mention return values, but since an output schema exists, that is acceptable. It is slightly lacking in mentioning prerequisites or consequences of unclean shutdown, but for a quit tool, the description is adequate.
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 a single boolean parameter 'save' with default false and no description (0% coverage). The description adds critical meaning: 'Set save=True to save before quitting.' This clearly explains the parameter's effect, adding value beyond the raw 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 purpose: 'Quit Blender gracefully.' It uses a specific verb ('Quit') and resource ('Blender'), which distinguishes it from sibling tools like blender_launch, blender_save, and blender_new_file.
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 a usage guideline: 'Set save=True to save before quitting.' This tells the agent when to use the parameter. However, it does not explicitly state when to use this tool versus alternatives (e.g., using system commands) or when not to use it. Since the tool is simple, the implicit usage context is clear enough.
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 environment (bpy, mathutils, math, os), blocked imports, and the expected return method. It omits potential risks like crashes or security, but still provides substantial transparency.
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?
Four concise sentences front-loaded with purpose, then environment, restrictions, and usage. Every sentence adds unique 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?
For an arbitrary code execution tool with no output schema, the description covers what it does, what's available, what's blocked, and how to return results. It could mention error handling or execution limits but is largely sufficient.
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 single 'code' parameter has 0% schema description coverage. The description adds significant context: available modules, blocked imports, and instructions to store results in 'result' variable. This fully compensates for the schema gap.
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 inside Blender' and specifies the environment and blocked imports. It distinguishes itself from sibling tools by saying 'Use this for advanced operations not covered by other tools.'
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 using this tool when other tools don't cover the operation. It implies when not to use it (when other tools suffice), but it could be more explicit about avoiding simple tasks.
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 behavior of Multires (adds modifier), Dyntopo (enables dynamic topology), and their mutual exclusivity. No annotations provided, so description carries full burden. Could mention mode change explicitly.
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 sentence for purpose, then bullet-like parameter explanations. 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?
Covers purpose and all parameters with behavioral context. Missing explicit mention that entering sculpt mode changes Blender's mode, but this is implicit. No output schema needed.
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 meaning beyond schema: explains multires_levels effect, dyntopo toggle, detail_size's relation to dyntopo, and default value. Schema had 0% coverage, 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?
Clearly states the action 'Enter sculpt mode' and the target 'mesh object'. Distinct from sibling tools like sculpt_brush_full which are operations within sculpt mode.
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?
Implies usage as a prerequisite for sculpting, and notes mutual exclusivity of Multires and Dyntopo. Does not explicitly state when not to use or list alternatives, but context is clear.
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-copilot MCP server](https://glama.ai/mcp/servers/dwgx/blender-copilot/badges/card.svg)](https://glama.ai/mcp/servers/dwgx/blender-copilot)

Score Badge

Copy to your README.md:

[![blender-copilot MCP server](https://glama.ai/mcp/servers/dwgx/blender-copilot/badges/score.svg)](https://glama.ai/mcp/servers/dwgx/blender-copilot)

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/dwgx/blender-copilot'

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