blender-mcp-ultra

by HitamLegit6777

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: v2.0.0
Disambiguation2/5
Many tools have overlapping purposes, e.g., solidify_mesh, add_wall_thickness, and add_modifier with SOLIDIFY; get_scene_info, get_scene_graph, and get_objects_summary all provide scene summaries. The distinction between create_object, model_from_scratch, and rig_from_scratch is also unclear, making it hard for an agent to pick the right operation.
Naming Consistency3/5
Most tools follow a verb_noun pattern (create_object, list_materials, set_render_engine), but there are notable deviations like 'ping', 'measure', 'find_objects', 'array_object', and 'run_batch'. The mix of generic verbs (get, set, create, add, remove) is consistent, but compound phrases like 'setup_three_point_lighting' and 'colorize_from_scratch' break the pattern.
Tool Count1/5
With 148 tools plus a registry of 228, the server is extremely over-scoped. This is far beyond the typical 3-15 tool range and even exceeds the 50+ threshold, making selection overwhelming and redundant. The count is clearly inappropriate for a coherent MCP server.
Completeness4/5
The tool surface covers a vast range of Blender operations: modeling, materials, lighting, animation, rigging, UV, geometry nodes, import/export, and scripting. The registry tools and run_batch provide a fallback for any missing operation. Minor gaps exist, such as no direct tool to delete a material or edit text content, but these are workaround-able via execute_blender_code or call_registry_tool.
Average 3/5 across 148 of 148 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, but the description adds no behavioral context such as irreversibility, effect on object origins, or scope across all mesh objects. It merely restates the scope in vague terms.
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 description is one short phrase but is under-specified; it lacks essential details, making it unhelpful. Brevity here is detrimental, not a structure benefit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature, the parameter, and sibling tooling, the description is completely inadequate. No mention of return behavior, side effects, or parameter usage.
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 a single 'types' parameter with no description and 0% schema coverage. The description does not explain what 'types' means (object types to affect) or how to use it. No additional semantics provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Bakar transform untuk semua objek mesh' roughly translates to 'Bake transform for all mesh objects.' The verb 'bakar' is ambiguous (burn/bake) and does not clearly convey 'apply' transforms. It restates the tool name without explaining the operation, and does not distinguish from the singular 'apply_transform' sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like 'apply_transform'. No context, prerequisites, or scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, but the description fails to disclose any behavioral traits such as what gets deselected, how the active selection changes, or any side effects. The description adds no value beyond what the annotations already state.
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?
While extremely short, this is under-specification rather than conciseness. The single phrase adds no useful information and would be equally unhelpful if slightly expanded. It lacks the structural detail needed for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool with a required parameter, sibling differentiation, and destructive annotations. It does not explain the selection behavior, interaction with other objects, or return value. Even with an output schema present, the description remains woefully incomplete.
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 clarify the 'name' parameter. It does not mention that the parameter likely names the object to select or how it should be formatted. The description provides no semantic meaning beyond the schema's basic string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Pilih satu objek' directly translates the tool name, making it a tautology. It states verb+resource but provides no additional context about what selecting means in the scene. It does not distinguish this tool from siblings like select_by_type or select_all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. Sibling tools like select_by_type, select_all, and find_objects exist, but the description offers no comparison or context for choosing this one.
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 annotations already declare destructiveHint: true and readOnlyHint: false, so the agent knows this is a mutating operation. However, the description adds no additional behavioral context, such as irreversibility, effects on the node graph, or error conditions, beyond what annotations provide.
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 description is extremely brief, but this brevity is under-specification rather than effective conciseness. It does not even specify the material context, which could be inferred from the parameter but is not stated. There is no structure or supplementary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and two required parameters, the description is insufficiently informative. The agent has no context about how to identify node_name, what happens to the material, or what the tool returns. The presence of an output schema (not shown) does not mitigate the lack of description-level guidance.
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 mentions no parameters. The schema includes material_name and node_name but provides no descriptions, and the description does not explain what these refer to. With 0% schema coverage, the description fails to compensate, leaving the agent without semantic guidance for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hapus node shader' is Indonesian for 'Remove shader node,' which directly restates the tool name without adding specificity about which shader node or material context. It does not distinguish from siblings like add_shader_node or list_shader_nodes, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention prerequisites, such as having a material selected or needing to list shader nodes first, nor does it indicate 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?
Annotations indicate readOnlyHint=false and destructiveHint=true, which are not contradicted by the description. However, the description adds no behavioral details beyond 'create', such as what state changes occur, potential side effects, or whether existing objects are affected.
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 description is extremely short, but this is under-specification rather than concise effectiveness. It fails to convey necessary information and essentially repeats the tool name in another language, providing minimal value per word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and a mutation/destructive intent, the description is completely inadequate. It does not explain return values, required prerequisites, or any operational context, making it nearly useless for correct invocation.
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 6 parameters with 0% description coverage, and the description provides zero parameter information. The agent must rely solely on names and defaults, which is insufficient for understanding rotation, lens, clip_start/end, or location semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Buat kamera' literally translates to 'Create camera', which is a direct restatement of the tool name. It provides a clear verb and resource but adds no distinguishing information beyond the name, and does not differentiate from sibling creation tools like create_object or create_light.
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 offers no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent without additional decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the annotations. Annotations indicate destructiveHint=true, but the description does not explain what gets overwritten or whether the operation is reversible. It adds no context about side effects or requirements.
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 sentence, making it concise, but it is under-specified. While brevity is good, the sentence does not earn its place because it does not add information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and a destructive annotation, the description is woefully incomplete. It lacks any explanation of the operation's effect, parameter semantics, or usage context, making it insufficient for an agent to use it correctly.
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% and the description does not elaborate on the parameters object_name and material_name. It neither defines what these names refer to nor provides examples, leaving the agent guessing about the expected values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology of the tool name, restating 'assign material' as 'assign material to object'. It provides no information beyond what the name already conveys, making it unclear how it differs from sibling tools like assign_image_texture or set_color.
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 does not mention any prerequisites, such as the material needing to exist, or any contexts where this tool should be preferred over 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?
The annotations already provide destructiveHint=true, and the description adds no additional behavioral context such as irreversibility, effect on the object, or failure conditions. It simply restates the removal action, contributing no value beyond the structured metadata.
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 description is extremely short, but this is under-specification rather than effective conciseness. It lacks any structured elaboration on usage, parameters, or outcomes, so while there is no fluff, the brevity is not appropriately sized for the tool's needs.
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 destructive two-parameter tool, the description is incomplete. It lacks usage context, parameter semantics, and any explanation of return behavior or output. The presence of output schema and annotations does not compensate for the absence of descriptive guidance.
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 explain the meaning or purpose of object_name or group_name. The tool name alone does not clarify how these parameters should be specified, so the agent receives no help in constructing valid arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hapus vertex group' is a direct translation of the tool name 'remove_vertex_group' and restates it without adding any new information. While it clearly names the action and resource, it is essentially a tautology and does not explain the object scope or otherwise go beyond the tool 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?
No guidance is provided on when to use this tool versus related siblings like add_vertex_group or assign_vertex_weights. There are no prerequisites, exclusions, or alternative recommendations, 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?
The readOnlyHint annotation already covers the read-only nature, but the description adds no additional behavioral context. It doesn't say what happens for objects without shape keys, invalid object names, or what the output contains.
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 description is extremely short but under-specified. It is a sentence fragment with awkward grammar, providing minimal information. It is not an example of good conciseness; it's simply too sparse to be useful.
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?
Even though the tool is simple with one parameter and an output schema, the description is incomplete. It doesn't clarify that it lists shape keys belonging to the mesh object specified by object_name, nor does it describe the return structure. The output schema exists but the description doesn't connect the tool's purpose to it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required object_name parameter with 0% description coverage. The tool description does not explain what object_name refers to or how it is used, leaving the agent to infer from the parameter name alone. The description fails to compensate for the missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Daftar shape key mesh' is a near-literal restatement of the tool name, using Indonesian words. It conveys a vague sense that the tool lists shape keys, but it's grammatically awkward and doesn't clearly state 'list shape keys of a specified mesh object'. It doesn't distinguish from related tools like add_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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It doesn't mention the required object_name parameter, prerequisites, or how it fits with other shape key or mesh 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?
The description adds no behavioral details beyond the name itself. While annotations already indicate destructive behavior, the description does not disclose whether existing connections are overwritten, whether type mismatches are handled, or any side effects. With annotations present, the bar is lower, but the description still provides minimal added value.
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 one sentence, which is concise and free of fluff. However, it is so brief that it under-specifies a tool with five required parameters. While conciseness is valued, substantial content is missing, so it earns a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters and no schema descriptions, the tool is under-documented. The description does not explain the function's purpose in context, such as what materials or nodes are eligible, nor does it mention any return values or error conditions. Despite having an output schema, the description remains incomplete.
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. However, it does not explain any parameter's meaning or relationships. The parameter names are somewhat self-evident, but the description adds no guidance on how to fill them, such as expected socket naming conventions or node identifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'connect' and identifies the resource as 'shader node sockets', which distinguishes it from sibling tools like adding or removing nodes. However, it does not explicitly state that it connects an output to an input, which could be ambiguous. Overall, it provides a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, no prerequisites, and no exclusions. The description is a single imperative sentence with no contextual direction. Sibling tools like add_shader_node or set_node_value are not 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?
The description doesn't add behavioral details beyond the annotations. While annotations indicate destructiveHint=true, the description merely says 'add modifier' without explaining the actual destructive effect on geometry or that it applies symmetry.
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 description is a single short sentence, which is concise but under-specified. It lacks essential details and reads more like an under-specification than an efficient summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 parameters, an output schema, and annotations, but the description provides almost none of the necessary context. It fails to clarify the object target, axes behavior, return value, or relationship to 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?
Schema description coverage is 0%, and the description does not explain the parameters 'obj_name' or 'axes'. It does not mention that axes defaults to ['X','Y'] or what values are valid.
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 that the tool adds a Mirror modifier for symmetry, which is a specific action on a resource. However, it does not distinguish itself from the sibling tool 'add_modifier' or mention the target 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 add_modifier or apply_modifiers. There is no context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal context beyond the annotations: it says 'all objects' but provides no detail on how the vector applies (absolute vs. relative), whether objects are moved or offset, or any side effects. The destructiveHint is present, but the description doesn't elaborate on what may be lost or changed.
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 description is a single incomplete sentence in German, under-specified for a destructive batch operation. It lacks structure and does not front-load useful semantics; it is not concise but rather insufficient.
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 (one optional parameter, output schema exists), the description is too sparse. It fails to convey that this is a destructive mutation tool acting on all objects, and it doesn't describe the expected behavior (e.g., does it replace all locations or add an offset?). The output schema could clarify returns, but the description still needs more 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?
The schema has 0% description coverage for the 'offset' parameter. The description only mentions 'met vektor' (with vector), which weakly hints that offset is a vector, but it doesn't explain the required format (e.g., array of three numbers), units, origin, or how it interacts with existing positions.
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 description 'Geser alle objekte met vektor' suggests moving all objects by a vector, which roughly matches the tool name 'batch_set_location'. However, it is vague about whether it sets absolute positions or applies an offset, and it doesn't distinguish from sibling tools like 'batch_set_scale' or 'transform_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 about when to use this tool versus alternatives such as 'apply_transforms_all' or 'transform_object'. There is no mention of prerequisites, selection requirements, 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?
Beyond the readOnlyHint annotation, the description adds no behavioral context. It does not explain what data is returned, whether it operates on the current file, or how the output is structured. The description carries minimal burden and fails to enrich the agent's understanding.
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 description is extremely short but under-specifies the tool's purpose. It is not concise in a useful way; it is cryptic and poorly structured, likely due to non-native English phrasing. A one-sentence description can be effective, but this one fails to convey meaning.
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 simplicity of the tool (no parameters, read-only), the description is still incomplete. It does not say what the tool returns or how it relates to other scene/summary tools. The agent is left without enough context to select or invoke it 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?
The tool has no parameters, so the schema is empty. Baseline for zero parameters is 4; there is nothing for the description to explain about parameter semantics. The description does not need to compensate for any coverage gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Inventaris datablocks file blend' is essentially a broken translation of the tool name, offering no additional clarity. It restates the name without specifying what 'summary datablocks' means or what the tool actually does. It does not distinguish itself from sibling getter 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 context, prerequisites, or alternative tools, making it impossible for an agent to know when this is the right choice.
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 already indicate this is a destructive, non-read-only operation. The description adds no further behavioral context, such as whether the node addition is reversible, how it affects the existing node tree, or any side effects. No extra transparency beyond the annotations is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but it is under-specified rather than concise. It omits critical information about parameters and context, making it insufficient for an agent to use effectively. Conciseness is not a virtue when it sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool has 3 parameters, no descriptions, and an output schema, the one-sentence description is far from complete. It does not explain how to specify the target node group, what node types are supported, or what the operation returns. The description is inadequate for correct invocation.
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 any of the three parameters (object_name, name, node_type). It fails to explain which parameters are required, what valid values exist, or how they relate to the action. The description provides no help in understanding parameter 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 states a specific action: adding a node to a GN node group object. This distinguishes it from related tools like add_geometry_nodes_modifier, which adds a modifier rather than a node. However, it lacks details on what types of nodes can be added and the exact nature of the 'GN node group 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?
There is no guidance on when to use this tool compared to alternatives. The description does not mention prerequisites, typical use cases, or situations where a different tool should be used instead. It simply states the action without contextual 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?
The annotations already signal destructive behavior, but the description adds no additional behavioral context. It doesn't mention that vertices are permanently merged, that topology changes, or that the operation is applied to a specific object. The description's statement about removing duplicates is more purpose than behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it is under-specified. While it earns credit for being concise, it omits critical information, making it insufficient rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive mesh operation with two parameters and an output schema, the description is severely incomplete. It provides no instruction on how to invoke it, what the object_name means, what distance does, or what to expect in the output. This is inadequate for an agent to use the tool correctly.
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 explain the parameters. The 'distance' parameter's meaning (threshold for merging vertices) is not described, and 'object_name' is not mentioned at all. The description provides no value beyond the raw schema field 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 tool removes duplicate vertices, which is a specific and recognizable operation. However, it does not explicitly differentiate from similar mesh cleanup tools like clean_mesh that might also remove duplicates, so it lacks full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not explain when to use this tool versus alternatives like clean_mesh or validate_geometry, nor does it mention prerequisites or scenarios where merging by distance is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive (destructiveHint=true), but the description adds no context about side effects, such as whether existing keyframes are overwritten, or how the animation is applied. Since annotations cover the basic safety profile, the description fails to provide additional behavioral insight.
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, efficient in length but lacking substance. It is not as terse as a tautology, but for a tool with six parameters and potential side effects, it under-specifies rather than being appropriately concise.
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 (six parameters, mutation, destructive hint) and the presence of many sibling animation tools, the description is too brief. It does not explain key aspects like keyframe insertion, interpolation behavior, or how it differs from generic keyframe tools. The output schema exists but is not shown; the description alone is insufficient.
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 compensate by explaining parameter meanings. Terms like 'A to B' and 'between two frames' vaguely map to start_loc/end_loc and start_frame/end_frame, but there is no clarification of formats, units, or the interpolation parameter. The description adds negligible value for parameter understanding.
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 animates an object from point A to point B across two frames, indicating it handles location animation. It is specific about the resource (object location) and the verb (animate), but it does not explicitly differentiate from sibling tools like animate_rotation or animate_scale, though those involve different properties.
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 animate_rotation, animate_scale, or keyframe_animation. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent to infer usage from the name and 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?
Annotations already declare readOnlyHint=false and destructiveHint=true. The description adds no context about what happens to existing weights, whether weights are added to or replace, or any side effects. The misleading 'optional' index note also obscures behavior rather than clarifying it.
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 one short sentence with no fluff, but it under-specifies essential details. It is concise but not effectively structured to convey necessary usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Five parameters, an output schema, and a destructive mutation are present, yet the description provides almost no contextual information. It fails to explain the return value, error conditions, or how the operation fits into a workflow, making it inadequate for an agent to use safely with only this description.
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 was expected to compensate, but it only touches on vertex_indices (and incorrectly calls it optional). No explanation is given for 'mode' or 'weight', leaving these parameters semantically 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?
The description clearly states the action 'assign weights' and the target resource 'vertex group', distinguishing it from sibling tools like add_vertex_group. However, the parenthetical '(indeks opsional = semua)' is misleading because vertex_indices is required in the schema, undermining 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?
No guidance is provided on when to use this tool versus alternatives such as auto_rig_weight or add_vertex_group. There is no mention of prerequisites (e.g., the vertex group must exist) or specific contexts where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds no behavioral context beyond this. It does not mention whether the tool creates a new object, modifies an existing one, or what side effects (e.g., overwriting) might occur. The description is purely functional and provides no additional transparency.
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 concise and front-loaded, but it is under-specified for a tool with six parameters. While it avoids fluff, its brevity comes at the cost of necessary detail, making it less 'appropriately sized' than it should be. The single sentence does not earn its place by providing clarity beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a complex profile array parameter and no parameter descriptions, the description offers no information about the input structure, default behavior, or expected output. The output schema exists but is not described. The tool is fundamentally incomplete from a contextual standpoint, leaving the agent unable to correctly select or invoke it.
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 any of the six parameters. The meaning of 'profile', 'steps', 'angle', 'axis', etc., is not explained. The description completely fails to compensate for the lack of parameter documentation, leaving the agent without guidance on how to construct valid arguments.
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 identifies a screw-profile creation operation around an axis, using the verb 'Lathe/screw' and resource 'kurva profil'. It distinguishes itself from generic curve or object creation tools in the sibling list, though the phrasing is slightly ambiguous (could be interpreted as a noun or verb).
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_curve or model_from_scratch. The description only states what it does, not the context or prerequisites. There are no explicit exclusions or alternative suggestions.
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 readOnlyHint annotation already declares this as a safe read operation, and the description simply repeats 'read' without adding behavioral context. It does not disclose what happens if the property is missing, whether all properties are accessible, or the return format. Given the annotation, the low bar is not met with extra value.
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 description is a single short sentence, which is concise in length but severely under-specified. It omits essential information about the parameter and behavior, making it under-specification rather than effective 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?
For a tool with one unknown parameter and no detailed schema, the description is incomplete. While an output schema exists (not shown), the input semantics are undocumented, and with many sibling tools offering similar functionality, the context is insufficient for correct invocation.
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 carries the full burden for explaining the 'prop' parameter. It merely says 'scene property' but does not provide any valid values, examples, or format. This is insufficient for a required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Baca' (read) and identifies the resource as 'scene property', making it clear this is a read operation on scene properties. However, it does not differentiate from sibling tools like get_scene_info, which likely also retrieves scene data, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. With many sibling tools such as get_scene_info and scene_summary, the description does not mention any exclusions or preferred contexts, leaving the agent without 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?
The annotations already declare destructiveHint=true and readOnlyHint=false, indicating this is a mutating operation. However, the description adds no additional context about what changes occur to the mesh, whether it is reversible, or any side effects. It does not contribute beyond what annotations already provide.
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 extremely short, consisting of a single sentence with no fluff. It is concise, but it is under-specified: it does not provide enough detail for an agent to use the tool effectively. It is not a tautology, but it lacks necessary content, making it only minimally acceptable in terms of 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 that this is a destructive mesh editing tool with four parameters, a required object_name, and no usage guidance, the description is far too sparse. The output schema exists but is not shown, and the description does not cover return values or side effects. The tool cannot be used correctly based solely on this description.
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 compensate. The parameters depth, thickness, face_index, and object_name are left entirely unexplained. The words 'inset' and 'face' only hint at face_index, but the roles of depth and thickness are unclear, and there is no explanation of how object_name is used.
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 'Inset satu face' clearly states the verb 'inset' and the resource 'face', indicating the tool insets a face on a mesh object. It is specific enough to be understood, but it does not distinguish from sibling tools like extrude_face or bevel_mesh, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about prerequisites, such as needing a selected face or being in edit mode, and does not mention any exclusions or alternative tools. It merely states the operation without 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?
The annotations already declare destructiveHint=true and readOnlyHint=false, so the mutating nature is covered. The description adds little behavioral context beyond the vague phrase 'dengan nilai yang cocok' (with matching values), failing to disclose whether existing keyframes are overwritten or what prerequisites apply.
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, front-loading the core action. However, it is so minimal that it sacrifices informative value, though conciseness itself earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is severely inadequate for a tool with five parameters and no schema-level descriptions. It does not explain how frames and values pair, what property defaults to, or the effect of interpolation, making it impossible for an agent to use correctly without external knowledge.
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 clarify parameter meaning. It only hints that frames and values correspond, but does not explain the array structure, the role of 'property', the required 'object_name', or the 'interpolation' option. This leaves most parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Sisipkan' (insert) and identifies the resource as keyframes placed at multiple frames with matching values. This distinguishes it from singular keyframe tools like insert_keyframe, though it does not explicitly mention the object or property parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 insert_keyframe, animate_location, or set_keyframe_interpolation. The description is a standalone statement with no contextual cues, exclusions, or 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?
The annotations already declare destructiveHint=true and readOnlyHint=false, so the description needed to add context like reversibility, effect on the armature, or required scene state. The description adds nothing beyond a simple restatement of the action, so it does not enhance transparency.
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 description is extremely short, but it is under-specified rather than concise. It only contains 'Hapus tulang' which is essentially a translation of the tool name, providing no additional structured information or segmentation.
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 that this is a destructive operation with two parameters and no parameter descriptions, the description is incomplete. It fails to mention expected outcomes, prerequisites, or how the tool handles errors, leaving significant gaps for an agent.
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%, yet the description does not explain the two required parameters (bone_name, armature_name). The agent must infer their meaning only from the parameter names, which is insufficient for correct invocation.
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 'Hapus tulang' (meaning 'Delete bone') clearly states the action and resource, so the core purpose is understandable. However, it does not differentiate from sibling tools like add_bone or rename_bone, and merely restates the tool name in another language.
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 about when to use this tool versus alternatives. The description only gives a bare action phrase and provides no context, 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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. However, the description adds no extra behavioral context: it doesn't specify that the UV map is removed by name, whether the operation is irreversible, or if there are any side effects. It simply restates the action without explaining what gets destroyed beyond the literal 'layer UV'.
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 description is extremely short ('Hapus layer UV' only), but this is under-specification rather than helpful conciseness. It lacks essential context and could be written in two or three clear sentences without losing brevity. Every word is spent on restating the name, providing no added 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?
For a destructive tool with two required parameters, the description is grossly incomplete. It does not explain the removal process, what happens when the UV map doesn't exist, or the expected return value. Even though an output schema exists, the description fails to provide sufficient context for an agent to use the tool correctly in a workflow.
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 provides no parameter semantics. The required parameters 'name' and 'object_name' are left entirely unexplained; the description doesn't clarify that 'name' refers to the UV map name and 'object_name' to the owning object. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hapus layer UV' (Remove UV layer) clearly states the action (remove) and resource (UV layer), which is specific enough to distinguish from sibling tools like add_uv_map and list_uv_maps. However, it does not explicitly differentiate itself from other 'remove' tools beyond the resource, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description only states the action without any context, prerequisites, or exclusions. The agent receives no information about when removing a UV map is appropriate or how it differs from related operations like unwrap_object or add_uv_map.
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 already indicate destructiveHint=true and readOnlyHint=false. The description only adds 'write_still', which effectively restates the write nature without disclosing file overwrite behavior, side effects, or permission needs.
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 extremely short with no fluff, but it is under-specified rather than meaningfully concise. It conveys the core action but omits essential context, so it is not optimally structured for tool selection.
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 tool with one parameter, an output schema, and annotations, the description is incomplete: it lacks parameter semantics, usage guidance, and behavior beyond the annotation basics. A minimal viable description should provide at least some context about the filepath and when to use this 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 sole parameter 'filepath' has no schema description and the description provides zero explanation of its meaning, format, or usage. With 0% schema coverage, the description fails to compensate for the missing parameter 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 'Render frame saat ini (write_still)' clearly states the tool renders the current frame, with 'write_still' indicating a file-writing operation. It is specific but does not differentiate from sibling tools like 'render_viewport_to_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 gives no guidance on when to use this tool versus alternatives such as 'render_viewport_to_path' or other render-related tools. There are no usage conditions or exclusions 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?
The description adds no behavioral context beyond what annotations already indicate. Annotations specify destructiveHint=true, but the description does not elaborate on what is destroyed or how the operation affects existing geometry. No contradiction, but minimal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded and free of fluff. However, it is so brief that it under-specifies the tool, sacrificing essential detail for 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 the tool has 5 parameters, a destructive hint, and an output schema, the description is incomplete. It lacks information about return values, side effects, or usage context, leaving the agent with insufficient guidance.
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% and the description provides no explanation of the parameters (seed, count, scale, object_name, instance_object). The description completely fails to clarify the meaning or required formats of these inputs.
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 scatters instance objects on a surface via Geometry Nodes, specifying the verb (scatter) and resource (instance objects on surface via GN). It is distinct from many siblings, though not explicitly differentiated from similar distribution tools like 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?
No guidance is provided on when to use this tool versus alternatives like distribute_objects or array_object. There are no usage conditions, 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?
Annotations indicate destructiveHint=true and readOnlyHint=false, but the description adds no additional behavioral context. It simply restates the tool's action without disclosing side effects, reversibility, or impact 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (single sentence) and front-loaded with the core action. However, it is under-specified, sacrificing necessary detail for brevity. It earns its place but fails to deliver sufficient 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 simplicity (1 param, no nested objects) and presence of output schema, the description is still inadequate. It does not explain the gravity vector semantics, units, or effect on the scene, leaving critical gaps for correct invocation.
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 explain the 'gravity' parameter. The array type and default value suggest a 3D vector, but without explicit explanation (e.g., units, coordinate system, x/y/z meaning), the agent cannot accurately set the parameter.
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 ('Atur gravitasi scene' = 'Set scene gravity') and identifies the resource (scene gravity). It is specific enough to distinguish from sibling tools, though it lacks detail on what gravity setting entails.
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. There is no mention of prerequisites, exclusions, or comparison to sibling tools, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows it performs a mutation. However, the description adds no additional behavioral context, such as what happens to existing resolution settings, whether the change is reversible, or if there are side effects on the render pipeline. The description merely restates the action implied by the tool name and annotations.
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 description is extremely short, but this is under-specification rather than effective conciseness. It provides minimal value and omits critical details about usage, parameters, and behavior. While every word earns its place, the whole message is too sparse to be useful.
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 three parameters, a destructive hint, and an output schema, the description is just one sentence. It does not explain return values, side effects, or how this tool relates to other render settings. Given the complexity of render configuration, the description is incomplete and leaves the agent guessing.
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 defines width, height, and percentage with defaults, but the description provides no explanation of these parameters. With schema description coverage at 0%, the description carries full responsibility for parameter semantics, yet it offers nothing. The agent is left to infer parameter meaning solely from schema names, which is insufficient (e.g., percentage relative to what?).
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 'Atur resolusi render' translates to 'Set render resolution', which clearly identifies the action (set) and the resource (render resolution). It distinguishes itself from sibling tools like set_render_engine and set_render_samples by focusing specifically on resolution. However, it does not elaborate on the aspects of resolution (e.g., width, height, percentage), making it slightly less descriptive than an ideal 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?
There is no guidance on when to use this tool versus alternatives such as set_render_samples or set_render_range. The description does not provide context, prerequisites, or exclusions. It is a bare statement of function with no 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?
The annotations indicate destructiveHint=true, but the description does not elaborate on what destructive behavior occurs, such as overwriting existing lights or altering the scene. It also does not mention any side effects or required permissions. The description adds no context beyond the basic function, failing to leverage the opportunity to 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, front-loading the core purpose. However, it is so terse that it omits essential details, which slightly detracts from its structural value. It earns a high conciseness score for efficiency, but not a perfect one because it sacrifices informativeness.
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 that this tool is destructive (per annotations) and has a required parameter, the description is incomplete. It does not mention how the tool interacts with existing lights, what the output schema represents, or any setup needed before calling. The presence of an output schema doesn't excuse the lack of explanation about the tool's effects, making the context insufficient for an agent to use it correctly.
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 schema description coverage is 0%, meaning the description does not explain the 'intensity' or 'target_name' parameters. While their names are somewhat self-explanatory, the description offers no insight into how values affect the lighting setup, what units intensity uses, or what 'target_name' refers to exactly. It completely fails to compensate for the low schema 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 the tool creates a key + fill + rim lighting setup around the object's bounding box, which distinguishes it from the generic 'create_light' sibling. However, it lacks an explicit verb in the description itself, relying on the tool name ('setup') for the action, making it slightly less assertive than the highest standard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is absolutely no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when a three-point setup is appropriate, or that it might be preferred over manual light creation or other lighting tools. The description is purely functional with no 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?
The description only restates the action ('rescale UV') and provides no additional behavioral context. The annotations indicate destructiveHint=true, telling the agent the operation is destructive, but the description does not elaborate on what exactly gets modified or whether the change is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is under-specified for a tool with two parameters and a specific domain concept (texel density). It is concise but at the expense of necessary 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 and the lack of parameter documentation, the description is insufficient. It does not mention whether the object needs an existing UV map, the units of density, or the effects of the operation on the object's UV layout.
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 schema has 0% description coverage, and the description does not compensate by explaining the 'density' or 'object_name' parameters. The meaning of 'texel density' and how the density parameter influences the operation is completely 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?
The description states a clear verb and resource: 'Skala ulang UV' (rescale UV), indicating this tool rescales UV coordinates. It is likely distinguishable from sibling tools like add_uv_map or unwrap_object, though it does not explicitly differentiate itself from 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?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as having a UV map, or scenarios where this tool is preferred over 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?
While annotations already declare destructiveHint=true, the description adds no additional behavioral disclosure. It doesn't state that an existing emission setting will be overwritten or what exactly gets modified. The description carries minimal burden beyond the annotations, but still fails to explain 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, achieving brevity, but it is under-specification rather than effective conciseness. It omits essential details about the operation, making it too minimal to be helpful. Every word should add value, but here the value is negligible.
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 three parameters, is marked destructive, and has an output schema, the description is far too sparse. It doesn't mention which material is affected, how the parameters influence the result, or any potential side effects. The agent lacks critical information for correct invocation.
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 schema description coverage at 0%, the description must compensate, but it does not. It only says 'make material emit' without linking the color and strength parameters to any meaningful behavior. The agent must rely solely on parameter names and defaults, 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 'Buat material memancar (emissive)' clearly states the tool's function: making a material emissive. This distinguishes it from sibling tools like set_color or set_transparency, though it could be more specific about targeting the emission shader. The verb-resource relationship 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?
The description provides no guidance on when to use this tool compared to alternatives. It does not mention prerequisites, such as requiring an existing material, or any exclusions. The agent is left without contextual 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?
Annotations declare the tool is mutating and destructive. The description adds no behavioral detail, such as what happens if a UV map with the same name exists, which object is modified, or whether existing UV layers are preserved.
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 short sentence with no fluff, making it very concise and front-loaded. However, it is too terse and omits critical information, so it doesn't fully earn 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?
The tool has only 2 simple parameters and a destructive hint, so one might argue a short description suffices. However, it omits any mention of the required object parameter or the naming option, and provides no usage context, making it incomplete for an agent.
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%. The description does not mention either parameter (object_name, name). It gives no hint that the UV layer is added to a specific object or that a custom name can be specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Tambah' = add) and resource ('layer UV' to 'mesh'), clearly indicating it creates a UV map. It distinguishes from sibling tools like remove_uv_map or list_uv_maps, though it doesn't explicitly contrast with unwrap_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 unwrap_object or add_vertex_color. It simply states the action without context on prerequisites or typical workflows.
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 already indicate destructiveHint=true, but the description adds no behavioral context beyond that. It doesn't disclose that this creates animation keyframes over a frame range, modifies the object's rotation in a destructive way, or any side effects. The description adds minimal value beyond the 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 extremely concise (one short sentence) and front-loaded, but it is under-specified for a tool with 7 parameters. It doesn't waste words, but it also doesn't include essential details needed to use the tool effectively.
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 and annotations, the tool is complex with many parameters and animation behavior. The description leaves out critical information about how the rotation animation works, the meaning of revolutions relative to frames, and the role of interpolation, making it incomplete for practical 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 must compensate for parameter meanings. It only hints at 'revolutions' and 'axis' but leaves start_frame, end_frame, interpolation, start_rotation, and object_name undocumented. This is insufficient for 7 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 rotates an object N revolutions around an axis, providing a specific verb and resource. It distinguishes from sibling tools like animate_location or animate_scale by focusing on rotation, though it doesn't explicitly mention animation keyframes.
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 animate_location, keyframe_animation, or insert_keyframe. The description lacks any context about prerequisites, typical scenarios, 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?
The description only restates the basic action and adds no behavioral context beyond what the annotations (destructiveHint=true) already imply. It does not clarify what happens to existing keyframes, whether it replaces or appends animation data, or any side effects on the object. The description adds no value over the 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 that immediately states the purpose. It is not wordy or redundant. While it is minimal, it effectively communicates the core function without extraneous detail, making it appropriately sized for a tool whose purpose is straightforward.
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, a destructive annotation, and no schema descriptions, the description is insufficient for an agent to use it correctly. It lacks information about parameter relationships, default behavior, or what the output represents. The presence of an output schema does not compensate for missing operational 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?
The schema has 0% description coverage for its 6 parameters, so the description must compensate but does not. It provides no meaning for start_scale, end_scale, start_frame, end_frame, object_name, or interpolation. The agent must rely solely on parameter names and defaults, which are ambiguous for arrays like start_scale and end_scale.
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 function: animating the scale of an object between two frames. It uses a specific verb (animate) and resource (scale), which distinguishes it from location or rotation animation, but it does not explicitly differentiate from siblings like animate_location or animate_rotation.
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 any prerequisites, limitations, or contexts where another animation tool would be more appropriate. There is no indication of when not to use it, so an agent has no basis for choosing it 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?
Annotations already indicate readOnlyHint=false and destructiveHint=true, so the agent knows the tool mutates and is destructive. However, the description adds no extra behavioral context, such as which object is modified, whether the target_object is consumed, or how the operation handles failure cases. It merely restates the operation type.
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, a single sentence that immediately conveys the core purpose. It is front-loaded and avoids unnecessary verbosity. However, it sacrifices completeness for brevity, omitting parameter and usage details, but that is not a fault of structure or 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?
The tool has moderate complexity (binary mesh operation with order-sensitive parameters) and a 0% schema coverage. An output schema exists, so return values are covered, but the description fails to explain parameter roles, operation semantics, or prerequisites. This makes the definition incomplete for correct invocation, especially since boolean operations require understanding which mesh is the base and which is the target.
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 explain the parameters at all. Specifically, it does not clarify the distinction between object_name and target_object (which is critical for DIFFERENCE where order matters), nor does it list the possible operation values beyond the default. The agent has to guess parameter semantics, making this 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 indicates a Boolean operation (DIFFERENCE/UNION/INTERSECT) on two meshes, which is specific and distinguishes it from sibling mesh-editing tools such as join_objects or merge_by_distance. However, it lacks an explicit verb like 'perform' or 'compute', making it a noun phrase rather than a full command statement.
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., both objects must be meshes) or the destructive nature of the operation. It only states what the operation is, 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?
The annotations indicate readOnlyHint=false and destructiveHint=true, but the description adds no context about side effects such as overwriting existing datablocks or permission requirements. It does not contradict the annotations but provides no additional behavioral insight.
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 no redundancy, front-loading the core purpose. However, it is under-specified for a tool with four parameters, so it sacrifices completeness for 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 the simplicity of the tool, the description is too thin. It lacks information on parameter ranges, color format, or what 'procedural' means in this context. The presence of an output schema does not compensate for missing usage guidance.
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 explain any parameters. Properties like name, color, width, and height are only defined by their names and defaults, leaving the agent to guess their meaning and valid 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?
The description 'Buat datablock gambar prosedural' clearly states a create operation on a procedural image datablock, distinguishing it from sibling 'assign_image_texture' which assigns an existing texture. It uses a specific verb and resource, but does not elaborate on what 'procedural' entails.
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 'assign_image_texture' or 'create_material'. There are no prerequisites, exclusions, or contextual hints to help the agent decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds no further behavioral context, such as whether the change is persistent, affects viewport only, or is reversible. It merely restates the basic visibility toggle without extra insight.
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 short sentence, which is very concise and front-loaded. It avoids verbosity, though it lacks any structured breakdown of behavior or 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?
Given the simple action and existing output schema, the description is too minimal. It does not clarify the relationship between the 'hide' boolean and visibility states, nor does it provide enough context for a low-complexity tool. It leaves important parameter semantics ambiguous.
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 explain the 'object_name' or 'hide' parameters. Since there are two parameters and no compensation from the description, the agent has no semantic understanding of what parameters do or how they interact.
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 'Sembunyikan/tampilkan objek' clearly states the tool hides or shows an object, using a specific verb and resource. However, it does not distinguish this from the sibling tool 'unhide_all', and the Indonesian phrasing may be ambiguous for agents expecting English.
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 'unhide_all' or 'select_by_type'. The description gives no context, 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?
Annotations already mark the tool as destructive (destructiveHint=true), but the description adds no additional behavioral context. It doesn't mention potential side effects like breaking references, whether the armature must be selected, or what happens if the new name already exists. For a destructive operation, this is minimal transparency beyond the annotation.
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, short sentence with no wasted words or redundancy. It is front-loaded and direct. However, its extreme brevity veers into under-specification; while concise, it could easily add a bit more useful information 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 tool has three required parameters, no parameter descriptions, and only a basic destructive annotation, the description is far from complete. There is no mention of how to use the tool, what the output might look like, or any warnings. Even though an output schema exists, the description fails to provide essential operational 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 description coverage is 0%, and the description does not compensate. It only says 'rename bone' without explaining the required parameters (armature_name, bone_name, new_name). An agent cannot infer what each parameter means or how they relate to the operation.
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 'Ganti nama tulang' clearly states the action (rename) and resource (bone), which is a specific verb+resource pair. While it implicitly distinguishes from sibling tools like add_bone and remove_bone by the verb 'rename', it doesn't explicitly mention the armature context or differentiate itself further.
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, no prerequisites (e.g., the bone must exist), and no context about how it fits into the broader workflow. It is a bare command without any usage instructions.
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 does not disclose whether selection replaces the current selection, whether it operates on visible or all objects, or any side effects. Given that annotations include destructiveHint=true, the description should clarify the impact, but it remains silent. No additional behavioral context beyond the annotations is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in length but under-specified. It is not verbose, but it lacks essential details. It is front-loaded with the verb, but the overall structure is too minimal to be fully helpful.
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 address return values, selection behavior, or any prerequisites. With annotations indicating destructive potential and a simple parameter, the description is incomplete for safe and correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, object_type, with a default of MESH and zero description coverage. The description only says 'sesuai tipe' (according to type), which minimally maps to the parameter but does not explain valid values, default behavior, or what happens when omitted. The description fails to compensate for the lack of schema documentation.
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 'Pilih semua objek sesuai tipe' clearly states the tool selects all objects of a given type. It is a specific verb+resource statement, but it does not explicitly distinguish from sibling tools like select_all or select_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 such as find_objects or batch_delete_by_type. The description lacks any context about selection behavior, replacing existing selection, or when 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, and the description says 'scale object' which implies mutation. However, the description adds no extra context about side effects (e.g., overwriting existing dimensions, affecting object children, or being non-reversible). It relies entirely on the annotation without elaborating, so it adds minimal value beyond structured data.
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 highly concise and easy to read. However, it is under-specified for a tool with four parameters and destructive behavior, so the brevity reflects incompleteness rather than efficient information density.
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 required parameters, no schema descriptions, a destructive hint, and an output schema, the one-sentence description is inadequate. It doesn't explain return values, behavior on non-existent objects, units handling, or any preconditions. The agent cannot fully understand the tool's scope from this 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?
The input schema has 0% description coverage, and the description only mentions 'dimensi milimeter' which simply reiterates the unit from parameter names (width_mm, height_mm, depth_mm). It does not clarify the meaning of object_name, axis mapping, or whether values are absolute or relative. The description fails to compensate for the absent schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('skala' / scale) and names the resource (object) and exact dimensions (milimeter presisi). This clearly identifies the tool's function, but it does not differentiate from sibling tools like transform_object or batch_set_scale, which also modify object scale.
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, whether it's for design-time scaling, or how it relates to other scale/transform tools. The agent is left without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, so the agent knows it's a mutating operation. The description adds no additional behavioral context—it simply restates the action without explaining consequences (e.g., moving the playhead, invalidating certain states, or affecting rendering). It does not contradict the annotations, but it fails to disclose any behavioral traits beyond what annotations already provide.
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 sentence, making it concise. However, it under-specifies the tool's behavior and parameter semantics. It is not overly verbose, but the brevity comes at the cost of clarity, so it earns a middle score.
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 simple schema but the presence of an output schema and annotations, the description is still too thin. It does not explain the impact of setting a frame, how the output looks, or any side effects. The lack of usage guidelines and parameter elaboration makes it incomplete for an agent to confidently invoke the 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 schema has one integer parameter 'frame' with no description, and schema description coverage is 0%. The description says 'ke sebuah frame' (to a frame), which implies the parameter is a frame number, but it does not explain units, meaning, or default behavior. This is insufficient given the low schema coverage, as the description only faintly hints at the parameter's 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 'Lompat timeline ke sebuah frame' clearly states the action: jumping the timeline to a specific frame. It includes a specific verb ('jump') and resource ('timeline'), which distinguishes it from sibling tools like render_frame or set_render_range. However, it lacks explicit mention of the parameter or scope, so it's not as detailed as the highest 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or which sibling tools to consider instead. This is a clear gap given the many related timeline/animation tools available.
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 annotations already indicate destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds no additional behavioral context, such as whether the previous render range is overwritten or if keyframes are affected. It is consistent with annotations but provides no extra value beyond them.
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 with no fluff, which is concise. However, it is under-specified—it omits parameter semantics and usage context, making it more minimal than appropriately complete. The brevity does not compensate for the missing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two integer parameters, but the description does not mention the start/end parameters, any constraints, or the behavior after setting the range. The output schema exists but is not explained. The description is insufficient for an agent to confidently invoke the tool correctly without additional inference.
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 defines 'start' and 'end' integers with defaults, but the description does not explain these parameters or their meaning. With schema description coverage at 0%, the description fails to compensate by defining the start/end semantics, leaving the agent to infer them from the tool 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?
The description 'Atur rentang frame animasi' translates to 'Set animation frame range,' which clearly identifies the verb (set) and resource (render range). It distinguishes from sibling tools like set_frame and set_render_engine by focusing on the frame range. However, it is in Indonesian and does not explicitly mention 'render,' which could reduce clarity for some agents.
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 offers no guidance on when to use this tool versus alternatives. It does not mention that set_frame is for the current frame or that this tool is specifically for the render range, nor does it provide any exclusions 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a destructive write operation (readOnlyHint=false, destructiveHint=true), so the description's 'Constraint IK' confirms modification but adds no extra context about what exactly changes (e.g., whether existing constraints are overwritten, or if the pose is altered). It does not disclose any side effects beyond the implicit constraint addition.
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 it reads more like a summary phrase than a structured explanation. It front-loads the core concept but omits vital details, making it minimally informative rather than efficiently complete.
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 schema description coverage, and a destructive annotation), the one-line description is insufficient. It fails to explain the setup process, what the pole target does, or how the IK chain is applied to the bone. An output schema exists but the description should still convey high-level 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 description coverage is 0%, so the description must compensate for parameter meanings. It only mentions chain_count and pole_target, leaving armature_name, bone_name, and target_object undocumented. These required parameters are not explicitly tied to the action, providing shallow semantics for a 5-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Constraint IK pada pose bone dengan chain count dan pole target' clearly indicates the tool applies an IK constraint to a bone pose, mentioning key parameters (chain count and pole target). This distinguishes it from generic constraints like add_constraint and from posing tools like pose_bone, though it lacks an explicit verb like 'sets up'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as add_constraint or auto_rig_weight. There is no mention of prerequisites (e.g., armature in pose mode) or scenarios where this tool is preferred, 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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds no extra context about side effects, reversibility, or what 'move' entails. It fails to explain whether the object's transform, origin, or other properties are affected, and does not clarify the significance of the 27 anchors.
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 in Indonesian, making it concise and front-loaded. It wastes no words, but its brevity comes at the cost of omitting critical details, which is a minor penalty.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no schema description coverage, yet the description only covers the general concept. It lacks essential context about anchor naming conventions, expected usage patterns, and prerequisites. Although an output schema exists, the description does not sufficiently prepare the agent to invoke the tool correctly.
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 schema description coverage at 0%, the description was expected to compensate for the lack of parameter documentation. It does not. The parameters obj_move, obj_target, anchor_move, and anchor_target are not explained, and the default anchor values (A_CENTER_CENTER_CENTER) are left undefined, leaving the agent without meaningful guidance.
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 object) and the resource (object) with a specific goal (match one of 27 anchors to another object's anchor). It distinguishes from siblings like snap_and_parent by focusing only on moving, not parenting, though the reference to '27 anchor' is somewhat ambiguous.
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 align_objects or snap_and_parent. There is no mention of prerequisites, conditions, or exclusions, leaving the agent to infer usage solely from the action verb.
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 already indicate destructiveHint=true and readOnlyHint=false, so the description adds the note 'memerlukan UI' (requires UI), which is a behavioral requirement not captured by annotations. However, this is vague and does not clarify what the UI requirement entails or any other side effects. Credit is given for adding some extra context beyond the 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 short sentence with no filler. It directly states the purpose and includes a parenthetical caveat. While minimal, every word earns its place, and the structure is front-loaded. It could be longer for completeness, but conciseness itself is well-executed.
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 and 7 parameters, the description is extremely brief. It does not explain what adding a rigid body entails, prerequisites, or any side effects beyond the destructive hint from annotations. The UI requirement is ambiguous. For a tool of this complexity, the description is insufficiently complete.
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 any of the parameters (mass, shape, animate, friction, body_type, bounciness, object_name). The description provides zero additional meaning beyond the schema's titles and defaults. With no descriptions in the schema, 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 clearly states the action: 'Jadikan objek rigid body' (make object a rigid body), using a specific verb and resource. It distinguishes from siblings like create_object or add_modifier by focusing on rigid body functionality. However, it could be more explicit about the target object and the effect.
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, exclusions, or context in which this tool is preferred over other physics-related tools. The description simply states the action without any usage caveats.
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 already declare the tool is mutating (readOnlyHint=false) and destructive (destructiveHint=true). The description adds no extra behavioral context—it does not explain what gets replaced, whether the node is auto-connected, or what happens with duplicate names. With annotations present, this lacks additional useful 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 concise sentence with an enumerative list, which is efficient. The trailing '...' is a minor flaw, but the sentence earns its place with a clear action and examples. Overall well-structured for its 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?
The description is too thin for a tool with 3 parameters and a destructive mutation. It lacks context about required material existence, post-conditions, and interaction with other shader node tools. While an output schema exists, the description still needs to articulate prerequisites and side effects.
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 partially covers node_type by listing possible values, but leaves name and material_name unexplained. The ellipsis truncation makes the list incomplete, and the purpose of the name parameter is entirely absent.
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 (add shader node) and enumerates supported node types (bsdf_principled, bsdf_diffuse, etc.), distinguishing it from sibling tools like remove_shader_node or list_shader_nodes. However, it does not explicitly mention that it operates on a material, which is implied by the required material_name 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 guidance on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., material must exist) or alternatives like connect_shader_nodes for wiring nodes. It simply states the action without contextual usage cues.
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 declare destructiveHint=true and readOnlyHint=false, which already signal mutation. However, the description adds no context about what gets changed, whether objects are moved, resized, or potentially overlapping, or if any placement constraints apply. The one-line description offers no additional behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is front-loaded with the action and resource. While extremely brief, it is not merely a tautology and earns a good score for concision, though it sacrifices detail.
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 tool with 4 parameters (1 required) and no parameter descriptions, this description is insufficient. It does not explain how the grid is computed, how margins and bed dimensions interact, what constitutes a valid object_names list, or what the output/result is beyond repositioning objects. The presence of an output schema does not mitigate the lack of input semantics and behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It only implies that 'object_names' lists the objects to arrange, but does not explain margin_mm, bed_width_mm, or bed_height_mm, nor does it mention that they have defaults. The term 'grid' suggests layout behavior, but parameter meanings remain largely 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 uses a specific verb 'susun' (arrange) with a clear resource (objects) and scope (grid on print bed), clearly indicating the tool's function. It does not explicitly differentiate from sibling tools like align_objects or distribute_objects, but the grid+print bed context makes it fairly distinct.
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. The description does not mention prerequisites, exclusions, or compare with similar layout-related tools, leaving the agent to infer the use case 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?
The description only restates the operation ('create + assign') without disclosing behavioral details beyond the annotations. While destructiveHint=true already signals mutation, the description does not explain what happens to existing materials, whether it overwrites slots, or any other side effects. It adds no new 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is structurally simple and front-loaded. However, it is so under-specified that it fails to convey essential details for a destructive tool with four parameters. This is under-specification, not effective conciseness, as the brevity comes at the cost of critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with destructiveHint=true and four parameters, the description is extremely incomplete. It lacks usage context, parameter semantics, and any behavioral caveats. The existence of an output schema does not offset the complete absence of guidance for selecting and invoking this tool, making it nearly insufficient for an AI agent.
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 parameters (color, metallic, roughness, object_name). With schema description coverage at 0%, the description should compensate by explaining how these parameters relate to the PBR material, but it is entirely silent. The only hint is 'PBR material,' which is not tied to any specific parameter, leaving the agent to guess the 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 tool's function: 'buat + tetapkan material PBR ke objek' (create + assign PBR material to object). It distinguishes itself from siblings like create_material and assign_material by combining both operations in a single call. The verb+resource 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Sekali jalan' (in one go) implies a combined create-and-assign workflow, but there is no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like create_material or assign_material, though the implication of a one-step convenience is present. This is implied usage, not explicit 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 adds no behavioral detail beyond the annotation's destructiveHint=true. It does not explain what destructive action may occur or how this affects the scene, despite annotations indicating potential destructiveness. No contradiction, but also no elaboration.
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 fluff. It is efficiently structured and front-loaded with the verb, though it sacrifices informative content for 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?
For a creation tool with 3 parameters and no required ones, the description lacks critical context about object behavior, coordinate system interpretation, or potential conflicts with existing objects. The output schema may define return values, but scene effects and parameter semantics remain undocumented.
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 for parameter meanings. It only hints at add_root_bone via the parenthetical '(optional root bone)' and leaves name and location entirely unexplained, relying on schema defaults that are self-explanatory but lack 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?
The description clearly states the tool creates an armature object with a specific verb+resource combination. However, it lacks differentiation from sibling tools like create_object or add_bone, which may also create or modify objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as create_object or rig_from_scratch. It does not mention prerequisites, contexts, 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?
Annotations already mark destructiveHint true, and the description adds the behavioral note that data is shared ('data dibagi'), which is not visible from annotations alone. However, it does not explain the implications of shared data (e.g., whether the original is modified, material/transform relationships) or any side effects on scene structure. No contradiction with 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 extremely concise, a single short clause with no filler. However, it is under-specified for the required parameters and usage, so while compact, it sacrifices needed information. Structure is simple and front-loaded.
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 an output schema existing and a simple operation, the description lacks parameter semantics and usage guidance. It does not clarify how 'name' is used, what 'new_name' defaults to, or the consequences of shared data. Given low schema coverage and the destructive annotation, more context is needed.
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, and the description adds no meaning for the parameters 'name' and 'new_name'. The parameter names are somewhat self-explanatory, but the description fails to clarify their roles, requiredness, or default behavior. Given the low schema coverage, the description was expected to compensate but does not.
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 the tool duplicates an object and indicates shared data ('Duplikat objek (data dibagi)'), providing a specific verb and resource. It is distinguished from siblings like batch_duplicate by the singular focus, though it does not explicitly contrast alternatives. The shared-data note gives useful scope, but the lack of a title or more context 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 vs alternatives such as batch_duplicate, create_object, or delete_object. The description does not state prerequisites, scenarios, or exclusions. A brief note on typical use cases would be 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?
Annotations already indicate readOnlyHint=false and destructiveHint=true, so the agent knows it's a mutating operation. However, the description adds no additional behavioral context, such as whether the original face is replaced, whether it requires a specific selection state, or what could be destroyed. It doesn't go beyond the annotation's safety profile.
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 short sentence with no redundancy. It is concise but slightly awkward due to the mixed language ('satu face' and 'sepanjang offset'). Still, it conveys the core operation efficiently without 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 the low parameter coverage, destructive annotation, and the presence of an output schema, the description is insufficiently complete. It doesn't explain the required object_name, how face_index is used, or what happens to the object after extrusion. The tool is part of a large sibling context, but the description provides no clues about its integration or 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?
Schema description coverage is 0%, so the description must compensate for parameter clarity. It only mentions 'offset' ('sepanjang offset'), which gives some meaning to that parameter, but it omits face_index and object_name entirely. The required object_name is particularly important and unexplained, leaving a significant semantic 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 action ('Extrude') and the target resource ('satu face' meaning one face), indicating a mesh operation. It distinguishes from sibling tools like inset_face or bevel_mesh by the unique verb, though it doesn't explicitly contrast with them. The phrase 'sepanjang offset' conveys direction/amount, giving a basic understanding of the tool's 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?
The description offers no guidance on when to use this tool versus alternatives, nor does it mention prerequisites like edit mode or object selection. It simply defines what it does. Without context on when to choose extrude_face over similar mesh tools, an agent lacks sufficient 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?
Annotations declare readOnlyHint=true, and the description is consistent, adding that the output is 27 anchors in global space. However, it does not disclose potential errors, coordinate format details beyond 'global space', 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no extraneous language, making it concise and front-loaded. However, the extreme brevity sacrifices detail needed for full comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one required parameter with no explanation, and the description does not provide context about what 'anchors' are in Blender or how to identify the object. Although an output schema exists, the lack of parameter context and usage examples makes the description incomplete for correct invocation.
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 schema has no description for obj_name, and the tool description does not explain what this parameter represents or how it should be provided. With 0% schema coverage, the description fails to compensate, leaving the parameter semantically empty.
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 returns 27 anchor points of an object in global space, using a specific verb and resource. It does not explicitly distinguish itself from sibling tools, but the specificity of '27 anchor points' differentiates it from general object-information 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 offers no guidance on when to use this tool or how it compares to alternatives. There is no mention of use cases, prerequisites, or excluded scenarios, leaving the agent 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?
The annotation readOnlyHint=true already indicates a safe read operation. The description adds context by listing what is analyzed (tris/quads/ngons, non-manifold, loose geometry), but does not disclose output format, edge cases, or any additional behavior. It provides moderate value beyond annotations without contradiction.
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, compact sentence with no filler words. It front-loads the key topic (topology quality) and briefly enumerates the checks. Though terse, it earns its place as concise, but could be slightly expanded without losing efficiency.
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 tool with a single parameter and an output schema, the description is too minimal. It does not explain the purpose of the parameter or provide usage context relative to sibling tools. The output schema covers return values, but the overall description leaves significant gaps in understanding when and how to invoke the tool correctly.
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 schema has one parameter 'object_name' with no description, and schema description coverage is 0%. The description fails to explain what 'object_name' refers to or how it is used, leaving the agent without guidance. No compensation for the low coverage 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 states what the tool analyzes: topology quality including tris/quads/ngons, non-manifold, and loose geometry. It clearly identifies the resource (mesh topology) and specific aspects, but lacks an explicit verb like 'analyze' or 'check', which would fully clarify the action. It partially distinguishes from sibling tools like validate_geometry by listing concrete topology metrics.
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 validate_geometry or check_manifold. The description implies it is a topology analysis tool but does not specify scenarios or exclusions, 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?
Annotations already indicate destructive behavior (destructiveHint=true), but the description adds no context about what destructive means here—e.g., whether it overwrites an existing file, requires a specific file format, or has other side effects. The word 'eksplisit' (explicit) adds minimal value beyond the tool name.
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 and front-loaded, with no filler words or repetition. It is appropriately sized for a simple tool, though the term 'eksplisit' is somewhat redundant given the word 'path'.
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 destructive tool with only a one-line description and no output format or behavior details, the description is notably incomplete. The output schema exists, which helps, but the lack of clarity on overwrite behavior, supported file formats, and usage context leaves significant 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?
Schema coverage is 0%, and the description only confirms that 'filepath' is a path file, adding little beyond the parameter name. It does not specify expected format, allowed extensions, or default behaviors, which would be necessary to compensate for the lack of schema documentation.
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 'Render ke path file eksplisit' clearly identifies the action as rendering to an explicit file path, which aligns with the tool name and distinguishes it from sibling tools like render_frame or get_viewport_screenshot. It is specific about the resource (viewport) via the name and the output destination (file path). However, it does not explicitly mention the viewport in the description, slightly reducing differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as render_frame or export_scene. The description only states what it does, not the context or conditions under which it should be selected.
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 annotations already indicate that this is a non-read-only, destructive operation. The description adds no additional behavioral context beyond stating the action itself, such as side effects or reversibility, so it provides little value beyond the structured 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 a single, concise sentence that conveys the tool's purpose with no unnecessary verbiage or redundancy. It is appropriately sized for the simple operation described.
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 essential context for correct usage, such as what camera_name should refer to, what happens to the previous active camera, or any error conditions. While the operation is simple, the lack of parameter guidance and behavioral details makes it incomplete for reliable invocation.
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 schema has one parameter (camera_name) with no description, and the schema description coverage is 0%. The tool description does not mention the parameter or explain what values are valid, leaving the agent to infer the expected input purely from the parameter 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?
The description clearly states the tool's function: making a camera the active camera of the scene. It uses a specific verb and resource, but does not explicitly distinguish itself from sibling tools like set_camera_target.
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 are no usage contexts, prerequisites, or exclusions mentioned, leaving the agent without direction on selecting 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?
The description reveals that the tool works via alpha and blend mode, which is some behavioral insight beyond the tool name. However, given destructiveHint=true, it fails to disclose what is overwritten or how existing transparency settings are affected, and it does not mention irreversible changes or requirements for the material. This lack of transparency is a significant gap for a mutating 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 a single concise sentence that is appropriately short and front-loaded with the core purpose. It avoids unnecessary elaboration, though it is arguably too terse to cover the necessary details. Nevertheless, it earns its place by conveying the essential function 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?
Given that this is a destructive mutation tool (destructiveHint=true) with zero schema property descriptions, the description is insufficiently complete. It does not explain why a user would choose this over other material tools, what the output or side effects are, or how to handle the existing material state. The presence of an output schema reduces the need to explain return values, but the description still lacks critical contextual information for safe and correct invocation.
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 must compensate for the parameters. It mentions 'alpha + metode blend' but does not explain units, valid values, default behavior, or the relationship between alpha and blend_mode. The description adds only minimal meaning beyond the raw schema fields, leaving the agent to guess at parameter 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 'Buat material transparan (alpha + metode blend)' clearly identifies the action (making a material transparent) and the resource (material), and the mention of alpha and blend mode helps distinguish it from sibling tools like set_color or set_emission. However, the verb 'Buat' could be interpreted as 'create' rather than 'set', introducing slight ambiguity about whether it creates a new material or modifies an existing one.
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 create_material, assign_material, set_color, or set_emission. There is no mention of prerequisites (e.g., material must exist) or exclusions, leaving the agent without 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?
Annotations already declare destructiveHint=true, so the safety profile is known. The description adds that this is a Solidify modifier, providing a useful clue about its procedural nature. However, it does not disclose what happens to the original geometry, whether the modifier is applied or left unapplied, or any side effects beyond adding thickness. This is minimal but not misleading.
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 filler. It is appropriately brief for a simple operation, but given the lack of parameter context, it leans toward under-specification rather than effective conciseness. Still, it earns points for economy of 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 tool has 3 parameters and an output schema, but the description is minimal. It does not explain the role of offset (a scaling factor) or thickness (the amount of skin added), nor does it distinguish this from similar siblings like add_wall_thickness. Given the ambiguity and missing parameter semantics, the description is incomplete for a destructive modification 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?
Schema description coverage is 0% and the description does not explain any of the parameters (offset, thickness, object_name). It only says 'Add skin thickness' without mapping these terms to specific effects. The schema provides default values but no semantic meaning, so the description fails to compensate for the coverage 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 states a clear verb+resource: 'Add skin thickness (Solidify modifier)'. It identifies the tool's function unambiguously and distinguishes it from generic mesh tools by naming the specific modifier. However, it could be more explicit about what the modifier does (e.g., creating an extruded wall around the 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 offers no guidance on when to use this tool versus alternatives. Sibling tools like add_wall_thickness or bevel_mesh are not mentioned, and no contexts or exclusions are provided. The user is left to infer usage.
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 already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds the 'bmesh' note but does not describe behavioral nuances such as how cuts or smooth affect the existing geometry, whether the operation is reversible, or any side effects beyond what annotations 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 a single short sentence, front-loaded with the action, which is concise. However, it is under-specified and omits critical information, making it more a lack of specification than a well-structured concise description.
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 three parameters and modifies geometry, the description is far too brief. It does not explain the role of each parameter, what happens to the mesh, or any output details. The presence of an output schema helps but is not enough to compensate for the missing contextual information.
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 explain the parameters. It fails to mention that 'cuts' controls subdivision levels or that 'smooth' adjusts smoothness, leaving the agent with no semantic understanding beyond 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 tool subdivides all edges of a mesh using bmesh, with a specific verb ('Subdivide') and resource ('edge mesh'). However, it does not explicitly distinguish itself from sibling mesh-operation tools like bevel_mesh or inset_face, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, intended scenarios, or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate destructiveness (destructiveHint=true) and non-read-only nature (readOnlyHint=false), but the description adds no additional behavioral context. It doesn't explain how adding a constraint affects the object, if it replaces existing constraints, or if it requires a valid target. This is a gap given the tool's mutation potential.
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 is front-loaded with the action. Every word serves a purpose, and the example constraint types add useful specificity without extra 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?
With five parameters and a destructive mutation, the description is far too sparse. It omits any context about object selection, target requirements, or the meaning of 'subtarget' and 'influence'. The output schema exists, but the description still fails to convey enough operational context for a complex 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%, and the description only lists constraint types, which partially explains 'constraint_type'. It does not clarify 'object_name', 'target_name', 'influence', or 'subtarget'. While parameter names are somewhat self-explanatory, the description should have compensated for the lack of schema descriptions, especially for parameters like 'influence' and 'subtarget'.
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 constraint, with a specific verb 'Tambah' (Add) and resource 'constraint', and lists example types (COPY_LOCATION, COPY_TRANSFORMS, TRACK_TO, IK). It is distinct from sibling tools like add_modifier or add_bone, though it doesn't explicitly differentiate itself for potential overlap with setup_ik_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 is given on when to use this tool versus alternatives. Sibling tools like setup_ik_chain may be more appropriate for specific IK setups, but the description offers no such context, exclusions, or prerequisites, 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?
Annotations already indicate a destructive, read-write operation, so the description adds no further behavioral context. It does not explain side effects (e.g., whether an existing modifier is replaced, how node groups are handled) or special behaviors. No contradiction with 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 a single, concise sentence with no filler. It is front-loaded and efficient, earning its place 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?
For a tool with two parameters, no parameter documentation, and an output schema, the description is under-specified. It lacks details about the node group behavior, the role of 'name', and what the tool returns, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. The 'name' parameter is ambiguous (likely the modifier name, but not stated), while 'object_name' is implied by 'ke objek' but not explicitly explained. There is no added meaning beyond 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: adding a Geometry Nodes modifier and node group to an object. It distinguishes from the general add_modifier sibling by specifying the modifier type, though the term 'node group' is ambiguous (whether it creates a new one or uses an existing one).
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 add_modifier or list_gn_modifiers. There is no mention of prerequisites, scenarios, or exclusions, leaving the usage context entirely implied by the name.
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 already mark destructiveHint=true, and the description adds that keyframing is optional ('optional di-keyframe'), which is a behavioral trait. However, it does not disclose side effects, prerequisites, or the effect of setting keyframes beyond the annotation.
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 phrase with no unnecessary words, which is concise. However, it is too brief and lacks structure to adequately describe a tool with five parameters, so it does not fully earn 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 tool's complexity (five parameters), the description is inadequate. It does not explain behavior, relationships between parameters, or what the returned output means (though an output schema exists). The description leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only vaguely references optional keyframing, which maps to the 'keyframe' parameter, but provides no explanation of 'frame', 'value', 'name', or 'object_name'. This is insufficient for a five-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add shape key' (Tambah shape key), indicating a specific verb and resource. It distinguishes from sibling tool 'list_shape_keys' by being an add operation. However, it does not explicitly mention the target object, making it slightly less 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?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The tool simply states the action without contextual cues.
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 readOnlyHint=true annotation already declares the tool as read-only, and the description does not contradict it. However, the description adds no additional behavioral context (e.g., return format, error behavior, or object requirements), so it provides no extra value beyond the 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 very short (three words) and front-loaded, but it sacrifices necessary detail. It is arguably under-specified rather than appropriately concise, and the non-English wording may hinder comprehension for many agents.
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 a single required parameter, a readOnly annotation, and an output schema present, the tool's core function is simple. However, the description lacks usage context, parameter guidance, and any elaboration on what 'UV mesh layers' means, leaving the agent to infer too much for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, object_name, with zero description coverage. The description does not explain the parameter's role, format, or connection to the UV maps. The parameter name is somewhat self-explanatory, offering minimal compensation, but the description fails to explicitly link it to the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Daftar' meaning 'list') and identifies the resource ('layer UV mesh'), distinguishing it from sibling tools like add_uv_map or remove_uv_map. However, the non-English phrasing and lack of explicit scope (e.g., 'for the given object') slightly reduce 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?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites. The description is purely declarative and offers no contextual usage information.
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 adds 'Aman di background' (safe in background), a behavioral trait not covered by annotations. However, it does not explain destructive effects on the modifier stack or that it modifies the object. Annotations already provide readOnlyHint=false and destructiveHint=true, so the description contributes minimal extra 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 one short sentence, front-loaded with the main purpose and efficiently lists supported modifier types. It avoids fluff, though the use of ellipsis after a long list is acceptable. It is appropriately sized for the information it conveys.
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 (19 parameters, 1 required), the description is severely incomplete. It does not specify which parameters apply to which modifier types, does not mention the required object_name parameter, and provides no usage examples or caveats. The output schema exists but does not cover parameter semantics or usage scenarios.
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%, and the description does not compensate. It lists modifier types, which are potential values for the modifier_type parameter, but it does not explain the 19 parameters such as object_name, target_object, axes, or angle. The list provides some meaning for one parameter but leaves the rest 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?
The description clearly states 'Add modifier' (Tambah modifier) and lists specific modifier types, establishing a clear verb and resource. It distinguishes from more specific siblings like add_armature_modifier by being generic, though it could potentially overlap with boolean_operation without explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or how to choose between this and related tools like boolean_operation or apply_modifiers. The 'safe in background' note hints at non-interactive use but not at 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?
Annotations already mark the tool as destructive and readOnly=false, but the description adds no extra behavioral context. It does not explain what happens over an existing vertex color layer, whether the operation overwrites data, or any side effects beyond the stated purpose.
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 wasted words. It is front-loaded with the verb 'Tambah' and directly communicates 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?
Even though an output schema exists, the description is incomplete for a mutating tool with 3 parameters. It lacks parameter explanations, usage context, and behavioral details, making it insufficient for reliable invocation.
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 was expected to compensate, but it only says 'satu warna' (single color). It does not explain the color array format, the layer_name default, or the required object_name parameter, leaving the agent guessing about the parameter 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 tool adds a vertex color layer painted with a single color. The verb 'Tambah' (add) and resource 'layer vertex color' are specific, and the qualifier 'dicat satu warna' distinguishes it from sibling tools like add_vertex_group or assign_vertex_weights.
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, exclusions, or situations where a different vertex/color tool might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, which cover the mutation risk. However, the description adds no extra behavioral context, such as how existing vertex groups are affected, whether the operation is reversible, or if any object state is overwritten.
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 extremely short (one sentence), making it concise but also under-specified. It is front-loaded with the key action but omits useful detail. While it avoids unnecessary words, it does not earn its place by conveying additional value beyond the tool name.
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, explicit annotations, and an output schema, the description provides a baseline understanding. However, it does not mention potential caveats like needing an active mesh object or interactions with existing vertex groups. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 elaborate on object_name or group_name. It only mentions 'mesh', which hints at object_name, but does not explain default behavior for group_name or any constraints. The description fails to compensate for the low 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 'Buat vertex group pada mesh' clearly states the action (create) and the resource (vertex group on mesh), distinguishing it from sibling tools like remove_vertex_group and assign_vertex_weights. It uses a specific verb and noun, making the purpose unmistakable.
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 assign_vertex_weights or remove_vertex_group. There is no mention of prerequisites, selection requirements, or conditions under which this tool should be 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?
Annotations already indicate readOnlyHint=false and destructiveHint=true, but the description adds no additional behavioral context. It does not disclose what happens to the original object, how duplicates are named, or whether the operation is reversible. This is a significant gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the core purpose. It is front-loaded with the action and resource, and contains no redundant information. It earns a perfect score for efficiency.
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?
While the tool is relatively simple, the description omits essential details such as whether the original is kept, how offsets are computed in world space, and naming conventions for the duplicates. Even with annotations and an output schema, the description is insufficient for an agent to predict the tool's full 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?
The description explicitly maps 'N kali' to the count parameter and 'offset linear' to the offset parameter, providing some meaning beyond the raw schema. However, with 0% schema description coverage, it fails to explain the offset array format (units, axis order) and does not mention object_name at all, leaving the agent to guess details.
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 duplicates an object N times with a linear offset, identifying the verb 'duplicate' and the resource 'object'. It distinguishes itself from sibling tools like duplicate_object (single copy) and array_object (which likely creates an array modifier). However, it lacks specifics about whether duplicates are separate objects or instances and how offsets are applied, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 duplicate_object or array_object. It does not mention use cases, exclusions, or prerequisites, leaving the agent to infer context from the tool name and minimal description.
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 already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds the bmesh context, which implies direct mesh manipulation, but doesn't specify side effects like whether UVs are preserved or if the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with one sentence conveying the core idea. It is efficiently written but lacks additional structure or examples that could aid understanding without adding length.
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 tool with four parameters and an output schema, the description is too sparse. It doesn't explain the effect of width and segments, what happens to the object, or how the output is structured. The presence of an output schema mitigates the need to describe return values, but the parameter semantics and usage context are insufficient.
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, but it only hints at the 'affect' parameter with 'edge atau vertex'. Width, segments, and object_name are not explained, leaving the schema to carry the burden without semantic 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?
The description clearly specifies the action (bevel), the resources (edges or vertices), and the method (bmesh). It distinguishes itself from other mesh tools by its unique purpose, although it doesn't explicitly contrast with 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 is provided on when to use this tool versus alternatives. It only states what it does, leaving the agent to infer applicability 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 readOnlyHint=false and destructiveHint=true, the annotations already indicate a write operation with potential destructive effects. The description adds no further behavioral context, such as whether it overwrites objects or affects the scene. It merely restates the purpose without additional 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 one short sentence, fully front-loaded, with no unnecessary words. It is concise 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?
The tool has 6 parameters, all with defaults, and an output schema, but the description is highly incomplete. It does not explain how the parameters interact, what the defaults do, or how the tool fits into the broader context. For a tool with moderate complexity and no schema descriptions, this description is insufficient for an agent to invoke it correctly.
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 the 6 parameters (body, name, size, extrude, location, font_name). It does none of this, providing no information about parameter meaning or 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 'Buat objek teks 3D' clearly states the action (create) and the resource (3D text object), making it distinct from generic tools like 'create_object' or other creation tools. It is specific and not a tautology.
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 only states the function without any context, exclusions, or comparison to sibling tools like 'create_object' or 'create_curve'.
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 adds the unit context (millimeters), which is meaningful for STL exports. Annotations already indicate destructive behavior (destructiveHint: true) and that it is not read-only, so the safety profile is covered. The description does not disclose additional behaviors like file overwriting or scene requirements, but the unit specification adds value beyond 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 that is front-loaded with the key action. It wastes no words, making it easy to parse. However, it lacks additional structure like parameter summaries or usage examples, but this is acceptable for its 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?
The tool is relatively simple with only two parameters and an output schema, but the description omits important usage context such as what object_name does, whether the export replaces an existing file, and any prerequisites. The presence of an output schema reduces the need to explain return values, but the missing parameter semantics and usage guidance make the description incomplete for reliable invocation.
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%, and the description does not mention the two parameters (filepath, object_name). The parameter names are somewhat self-explanatory, but object_name's meaning and behavior when empty are not clarified. The description fails to compensate for the lack of schema descriptions, leaving the agent to infer 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 STL in millimeters, using a specific verb and resource. It distinguishes from sibling export tools like export_glb, export_scene, and export_selected by specifying format and units. However, it does not clarify whether it exports the whole scene or a specific object, leaving scope ambiguous.
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 export_glb, export_scene, or export_selected. The description only states what it does, not the context in which it is preferred. No exclusions or alternative references 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?
The annotations already indicate destructiveHint=true and readOnlyHint=false, so the mutation nature is known. However, the description adds no further behavioral details, such as whether existing keyframes are overwritten or how interpolation is affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It effectively communicates the core function in one line.
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 the presence of an output schema, the description is minimally sufficient. However, it omits the object_name context and does not clarify insertion behavior, leaving some ambiguity for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It mentions 'location/rotation_euler/scale/...' which offers examples for the property parameter, but it does not explain the frame or object_name parameters or acceptable 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 'Sisipkan keyframe (location/rotation_euler/scale/...) pada sebuah frame' clearly conveys an insertion operation for keyframes on a frame. It identifies the action and resource, though it does not explicitly distinguish itself from animation-related siblings like set_keyframe_interpolation.
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 information about when to use this tool versus alternatives. The description only states the action without context on prerequisites or when to prefer it over other animation 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 already declare destructiveHint=true, and the description is consistent with that. However, the description adds no extra behavioral context beyond the annotation, such as whether original objects are removed, whether the operation is reversible, or any side effects. It relies entirely on the annotation for 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no superfluous words. It achieves maximum conciseness, even though it under-specifies other aspects.
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 moderate complexity and destructive nature, the description is too sparse. It doesn't mention what happens to the original objects, whether the objects must be mesh type, or how the merge is performed. While an output schema exists to cover return values, the description fails to provide essential usage context for a destructive operation.
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 was expected to compensate by explaining the parameters, but it does not. It doesn't clarify that object_names is the list of mesh objects to merge or that new_name is the optional name for the merged result. The description adds no meaning beyond what the schema property names already imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: combining multiple mesh objects into one. The verb 'Gabungkan' (combine/join) is specific, and the resource and outcome are explicit. This distinguishes it from sibling tools like merge_by_distance (merges vertices) or boolean_operation (combines via boolean), as it focuses on joining whole 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 guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only states the basic action, leaving the agent to infer the appropriate context from the tool 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?
The readOnlyHint annotation already indicates a safe read operation, but the description adds no behavioral context beyond that. It does not disclose the return format, error behavior for nonexistent objects, or any other side effects, so it does not go beyond what annotations already provide.
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 that earns its place. It is appropriately sized for a simple tool with one parameter, with no unnecessary words or 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 low complexity and the existence of an output schema, the description is minimally sufficient. However, it lacks any details about behavior or error handling, so it functions as an adequate but bare minimum for 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%, and the description only vaguely references 'the object' without explaining the object_name parameter's format or expected values. It does not compensate for the lack of parameter documentation in 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 'Daftar modifier pada objek' (List modifiers on the object) uses a specific verb and resource, clearly indicating the tool's function. It distinguishes from sibling tools that add, remove, or apply modifiers, though it lacks explicit scope qualifiers like 'all' or 'existing'.
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 add_modifier or remove_modifier. There is no mention of prerequisites, context, or exclusions, leaving usage entirely 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 references bmesh.bisect_plane, implying a direct mesh modification that aligns with the annotations' destructiveHint=true and readOnlyHint=false. However, it does not disclose specific behavioral traits such as what happens to geometry when clear_inner/clear_outer are set, or that the cut is permanent. It adds minimal context beyond the 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 a single sentence that efficiently communicates the action and resource, with a useful parenthetical note about the underlying Blender API. There is no redundancy or filler, making it well-structured and appropriately sized for its clarity.
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 five parameters and no schema descriptions, the description provides only a one-line summary. It omits parameter roles, usage guidance, and any workflow context. The presence of an output schema does not compensate for the missing parameter semantics and implementation details, leaving the description inadequate for a tool of this complexity.
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 contains no parameter information. The tool has five parameters including plane_co, plane_no, clear_inner, clear_outer, and object_name, but the description offers no explanation of their roles or interrelationships. This is a significant gap for a tool with this many 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 uses the verb 'Potong' (cut) and identifies the resource as a mesh loop, with the method of cutting along a plane via bmesh.bisect_plane. This makes the core purpose clear. However, it does not explicitly differentiate it from sibling mesh-editing tools like boolean_operation or bevel_mesh, so it lacks explicit sibling 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. It fails to mention use cases, prerequisites, or exclusions. An agent is left without context for choosing this over similar mesh operations.
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 already declare readOnlyHint=false and destructiveHint=true, so the destructive nature is known. The description adds one behavioral trait: it requires a UI, which is useful for headless contexts. However, it does not explain the actual mirroring behavior (e.g., whether it creates new bones or overwrites existing ones). The added value over annotations is minimal but present.
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, a single sentence without unnecessary words. It front-loads the core action and the UI requirement. There is no structural formatting, but for such a short description it is acceptable. It does not waste 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 destructive nature and the existence of many sibling tools, the description is too minimal. It does not clarify what 'symmetrize armature bones' entails (e.g., does it duplicate bones, flip them, or remove them?). It also lacks guidance on when to use this tool instead of 'apply_symmetry' or other armature tools. The output schema exists but is not shown, so the description does not help the agent understand return values or side effects.
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%, and the description provides no explanation of 'axis' or 'armature_name'. While 'armature_name' is self-explanatory, 'axis' remains ambiguous (its valid values and meaning are not documented). The description does not 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 'Simetrikan tulang armature' is a specific verb+resource combination, clearly indicating the tool mirrors/symmetrizes armature bones. It is concise and understandable. However, it does not differentiate from sibling tools like 'apply_symmetry', which could have a similar function, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage hint is 'memerlukan UI' (requires UI), which imposes a constraint but does not clarify when to use this tool over alternatives. It provides no context on when to mirror bones, prerequisites, or when to avoid this tool. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds that it resets to rest position but doesn't disclose behavioral details like whether it affects all bones when bone_name is empty, whether it clears keyframes, or if it can be undone. With annotations covering the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core function without fluff. It is front-loaded with the action and resource. However, it could be slightly clearer with proper grammar, but it earns a high score for efficiency and lack of 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?
For a destructive mutation tool, the description is incomplete. It doesn't specify the scope of the reset (one bone vs. all bones), whether it resets only the pose or also affects rest pose, or any side effects. While annotations and schema provide some context, the description leaves critical gaps that could lead to incorrect usage.
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, but it doesn't mention either parameter. The schema provides names (armature_name, bone_name) but no additional explanation. The optional bone_name is particularly ambiguous—does leaving it empty reset all bones? The description fails to clarify this, providing no added meaning 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 the tool resets a bone's transform pose to its rest position. It identifies the verb ('reset') and the resource ('bone pose'), distinguishing it from other bone-related tools like pose_bone. However, it's slightly ambiguous whether it resets a specific bone or all bones, as the bone_name parameter is optional.
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 pose_bone for setting poses or mirror_bones. It doesn't mention any prerequisites or conditions under which resetting the pose is appropriate, leaving the agent to infer usage from the tool 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?
The description adds no behavioral context beyond what annotations already provide. Annotations indicate destructiveHint=true, and the description merely states the operation without explaining consequences, such as whether the previous target is overwritten or if any constraints apply.
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, consisting of a single sentence with no unnecessary content. It is front-loaded and to the point, but it lacks substance that could aid the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no behavioral explanation and minimal usage guidance, this description is incomplete. It does not describe what happens when setting the target, any side effects, or why an agent would choose it. The lack of context makes it insufficient for confident invocation.
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%, and the description does not mention the parameters. Although parameter names are self-explanatory (camera_name, target_name), the description adds no additional meaning or examples, leaving the agent to rely solely on 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's function: making a camera track a target object. It uses a specific verb ('Buat' / 'Make') and identifies the resource (camera) and action (tracking), distinguishing it from sibling tools like create_camera or set_camera_active.
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 exclusions or prerequisites. It is a bare statement of functionality 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?
The description offers no behavioral context beyond the annotations. Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description does not explain what is destroyed or changed (e.g., whether existing keyframe interpolation is overwritten). It adds no extra detail about side effects or required 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 a single concise sentence, well under any length limits. It efficiently conveys the core action without unnecessary words. However, it is somewhat terse and could benefit from a brief example or clarification of 'action objek'.
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 and only 2 parameters, the description is insufficiently complete. It fails to specify what constitutes an 'object action', how to identify it, or any constraints (e.g., object must have an action with keyframes). Given the destructive annotation, more context is needed for safe usage.
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 mentions the three allowed interpolation values (CONSTANT/LINEAR/BEZIER), which partially explains the 'interpolation' parameter, but it does not explain 'object_name' or the default behavior of LINEAR. The parameter semantics are 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 the tool's function: setting interpolation (CONSTANT/LINEAR/BEZIER) on an object's action. It uses a specific verb ('Atur' meaning set) and resource ('action objek'), distinguishing it from sibling tools like insert_keyframe or animate_location.
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, such as needing an existing action or selected object, nor explicit comparison to similar animation tools like clear_keyframes or keyframe_animation.
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 already declare destructiveHint=true, and the description adds that it bakes and resets, but it does not detail what exactly is destroyed or changed (e.g., transform values zeroed, mesh vertices permanently modified). Some additional context is present beyond the annotations, but it remains vague.
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 no redundancy, making it concise and front-loaded. However, it is arguably under-specified, which slightly reduces its effectiveness.
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 low complexity (one parameter, output schema exists, annotations present), the description is minimally adequate but omits details about the operation's effects on the object and its transforms. It lacks the depth needed for full contextual 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?
Schema description coverage is 0%, and the description does not mention object_name at all. While the schema's object_name is self-explanatory, the description adds no semantic context or constraints, leaving the parameter only minimally documented.
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 the object's transform into mesh data and resets it, which is a specific verb and resource. It distinguishes from siblings like transform_object and apply_transforms_all by implying a permanent baking process.
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 apply_transforms_all or reset_pose. The description does not mention context, exclusions, or 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?
Annotations mark this as destructive (destructiveHint: true) and non-read-only, but the description adds no context about what gets modified or potential side effects (e.g., disconnecting existing Base Color connections, creating duplicate nodes). It merely states the additive/connective action without elaborating on the destructive implications.
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 one concise sentence that communicates the core function with no redundant words. It is appropriately sized for a straightforward tool and front-loads the essential 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?
The description is minimal and lacks crucial context: it does not mention prerequisites (e.g., material and image must exist), how it interacts with the material's node tree, or whether it replaces existing Base Color connections. The output schema exists, so return values are not needed, but the missing parameter semantics and usage guidance leave the description 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%, and the description does not explain any parameters. While parameter names (material_name, image_name, connect) are somewhat self-explanatory, the description does not clarify how they map to the operation, what 'connect' controls, or prerequisites like image existence.
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: 'Add Image Texture node and connect to Base Color' in Indonesian. It specifies the exact operation and target connection, making it easy to understand the tool's purpose. However, it does not differentiate from sibling tools like add_shader_node or create_image_texture, so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you want to assign an image texture to a material's Base Color, but it provides no explicit guidance on when to use it versus alternatives (e.g., add_shader_node, connect_shader_nodes, create_image_texture). There are no when-not-to-use conditions or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds the important context that it affects ALL objects of a type, which is significant behavioral info. However, it does not mention irreversibility, confirmation, or scope beyond type.
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 filler words. It efficiently communicates the core purpose in one clear line, which is appropriate 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?
For a destructive batch tool with one undocumented parameter and no parameter value guidance, the description is incomplete. It does not explain what object types are accepted, whether an empty type deletes everything, or any safety measures. The output schema exists but is not described, and the tool's danger level warrants more contextual detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (object_type) with 0% description coverage and a default of 'EMPTY'. The description mentions 'tipe' (type) but does not clarify valid values, what 'EMPTY' means, or whether the tool requires a type or would delete all objects if unset. The description adds minimal value beyond the parameter 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?
Description clearly states the action 'Hapus semua objek sesuai tipe' (delete all objects by type), using a specific verb, resource, and scope. It implicitly distinguishes from sibling delete_object by targeting all objects of a type, but the phrase 'sesuai tipe' is somewhat ambiguous about which types are valid.
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 delete_object or select_by_type. There is no mention of prerequisites, type restrictions, or exclusions, leaving the agent to 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds that it cleans orphan datablocks and normalizes names, giving some behavioral context. However, it does not disclose what happens to objects, whether normalization is reversible, or how the 'purge_unused' parameter affects behavior. The description aligns with annotations (no contradiction).
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 short sentence that front-loads the primary purpose. Every word contributes to stating the core actions, making it highly concise and 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?
Despite annotations and output schema existing, the description is too vague for a destructive tool. It omits parameter semantics, the exact scope of 'orphan datablocks', and what 'normalize names' entails. An agent would not know the full side effects or prerequisites, making the description 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% for the single 'purge_unused' parameter, so the description must compensate. It only implies the parameter's effect through 'clean orphan datablocks' but never explicitly explains what 'purge_unused' controls or its default behavior. Insufficient for an agent to understand the parameter.
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 identifies the action ('clean' and 'normalize') and resource ('datablock', 'nama'), conveying the tool's main purpose. However, it is written in Indonesian and does not differentiate from sibling tool 'purge_orphans', which likely overlaps in 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 'purge_orphans' or other cleanup tools. There are no exclusions, prerequisites, or contextual hints for selecting 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?
Annotations already declare destructiveHint=true, so the safety profile is known. The description adds context that the Empty is a reference/control point, which is useful, but it does not disclose any additional behavioral traits such as scene modifications or reversibility. With annotations covering the safety aspect, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence without fluff, efficiently stating the core purpose. It is well-structured and front-loaded, though it omits parameter details which are not required for conciseness alone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three optional parameters, and an output schema exists. However, the description provides no explanation of the parameters, their allowed values, or usage context, making it incomplete for an agent to select appropriate arguments. It fails to compensate for the 0% schema description coverage.
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, but it does not mention any of the three parameters (name, location, display_type) at all. This fails to provide necessary meaning beyond the schema, making parameter understanding impossible from the 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 'Buat objek Empty (titik referensi/kontrol)', which translates to 'Create an Empty object (reference/control point)'. It uses a specific verb and resource, and distinguishes this tool from generic creation tools like 'create_object' by specifying the Empty object type.
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 create_object or other specific creation tools. There are no mentions of use cases, exclusions, or 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?
The description adds 'Aman di background' (safe in background), a behavioral trait not present in the annotations, which is useful context. However, this phrase is ambiguous: 'aman' (safe) could suggest non-destructiveness, conflicting with destructiveHint=true in the annotations. Since the annotations already signal the write/destructive nature, the description doesn't directly address or clarify the destructive behavior, and the term 'safe' introduces potential confusion.
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, compact sentence that front-loads the core action and lists the available primitive types. Every word contributes to the purpose or adds the behavioral note about background safety, with no redundancy or 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?
Despite having an output schema, the tool has 10 parameters and carries a destructive hint. The one-sentence description fails to explain parameter semantics, the consequence of creating an object (e.g., adding to scene, selection behavior), or the meaning of 'safe in background.' It is notably incomplete for a tool of this complexity, leaving the agent to rely solely on schema structure without behavioral or parameter 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% with 10 parameters, so the description must compensate by explaining parameter meanings. It only provides a list of values for the 'type' parameter, offering some guidance for that field, but it says nothing about name, size, scale, radius, segments, or other parameters. This is inadequate compensation for the low 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 'Buat primitive dari nol' (Create primitive from scratch) and enumerates possible types (CUBE, PLANE, etc.), which identifies the tool's core function and distinguishes it from sibling creation tools like create_text and create_curve. However, including EMPTY in the list creates ambiguity because a dedicated create_empty tool exists among siblings, slightly weakening differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool vs. alternatives. It does not mention when not to use it, nor does it reference sibling tools like create_empty or create_text. The only implied usage is 'when you need a primitive object,' but there is no exclusion or comparison, leaving the agent to infer selection criteria on its own.
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 already declare destructiveHint=true and readOnlyHint=false, covering the safety profile. The description adds a UI requirement, which is useful behavioral context not present in annotations. However, it does not elaborate on side effects beyond the destructive flag.
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 front-loaded with the main action, with no redundant words. The parenthetical 'memerlukan UI' is a concise, relevant addition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, output schema present, and annotations available. The description gives the core purpose and a UI requirement, but lacks parameter clarification and usage guidance. It is minimally viable but has clear 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?
Schema description coverage is 0%, and the description does not explain the 'obj_name' parameter at all. While the parameter name is somewhat self-explanatory, the description fails to compensate for the lack of schema documentation and provides no additional meaning about what should be passed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Hitung ulang' (recalculate) and a clear resource 'normal mesh' (mesh normals), stating the exact operation and its goal of consistency. It distinguishes from sibling tools like mesh_analysis by pinpointing the normal-recalculation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The only extra note, 'memerlukan UI' (requires UI), is a prerequisite rather than a usage context. There are no mentions of alternatives, exclusions, or specific 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?
Annotations already indicate the operation is destructive (destructiveHint: true) and not read-only, so the description does not need to repeat that. It does add the behavioral trait of matching a '27-point anchor' and performing a parent operation, which the annotations do not convey. However, it lacks detail on side effects, such as whether the object's transform is permanently changed or how the anchor matching behaves on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the operation directly without any filler words. It is concise and front-loaded, making it easy to parse.
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 tool that performs snapping and parenting with destructive annotations and anchor matching, the description is under-specified. It does not explain the return value (though an output schema exists), prerequisites such as object selection, or the behavior of the anchor system. The presence of an output schema helps, but the overall context for a complex, destructive operation is 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%, so the description must compensate. It mentions the two main parameters 'obj_move' and 'obj_target' implicitly through the sentence, but does not explain the 'anchor_move' and 'anchor_target' parameters at all. The names themselves are somewhat self-explanatory, but the description adds no value in clarifying acceptable anchor values or how they are used.
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 function: it snaps an object to a target using an anchor system, then parents it. The verb 'snap' and 'parent' plus the resource objects are specific. However, the phrase 'anchor 27-titik' is vague and does not clarify what the anchors are or how they differ from the sibling tool snap_to_anchor, limiting differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like snap_to_anchor or align_objects. It does not mention exclusions, prerequisites, or scenarios where this tool is preferred. This is a significant gap given the 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?
The description adds no behavioral context beyond the annotations. While annotations indicate destructiveHint=true and readOnly=false, the description does not explain what 'show' entails (e.g., affects both viewport and render visibility, impacts selected state, or is irreversible). No contradiction with annotations, but no added 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, short sentence with no fluff. It is front-loaded with the action and object. However, it is extremely terse, potentially sacrificing clarity for 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?
For a tool with no parameters and an output schema, the description is minimally adequate. However, it omits important context such as the scope of 'all objects' (scene-wide? visible layers?), potential side effects, and whether it returns a confirmation or count. Given the destructive hint, more context would help the agent assess consequences.
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 requires no explanation. The description's simplicity is appropriate; there is no parameter information to supplement.
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 'Tampilkan semua objek' clearly states the action (show) and resource (all objects), and the tool name 'unhide_all' reinforces its purpose. It distinguishes from siblings like 'hide_object' and 'delete_object', though it could be more explicit about 'unhiding' rather than 'showing'.
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, such as whether objects need to be hidden first, or contrast with other visibility-related tools like 'select_by_type' or 'hide_object'.
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 already signal destructiveHint=true, so the agent knows the operation is destructive. The description adds 'safe in background' as an execution detail, but does not disclose what destruction occurs (e.g., overwriting existing UV maps) or any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, immediately stating the core action and method list. Every word contributes value, making it highly concise and 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?
Although an output schema and annotations provide some context, the tool's destructive nature and 0% parameter schema coverage require a richer description. Missing details include what the `name` parameter does, when to use this tool over UV map management tools, and the exact effects on existing UV maps.
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 schema description coverage at 0%, the description must compensate for missing parameter details. It does clarify the `method` parameter by listing allowed values, but it does not explain the `name` parameter (likely the UV map name) or explicitly define `object_name` beyond the context of 'mesh'.
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 'unwrap mesh' and enumerates the projection methods (SMART/PLANAR/CUBE/SPHERE/CYLINDER), making the tool's function specific. It distinguishes itself from UV map management siblings like add_uv_map by focusing on unwrapping via projection, though it omits the explicit term 'UV'.
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 add_uv_map, list_uv_maps, or remove_uv_map. There are no exclusions, prerequisites, or context for appropriate usage.
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?
Annotations already indicate destructive behavior, and the description adds specific context by naming what will be affected (double vertices and loose geometry). This goes beyond the generic destructive hint, though it doesn't mention side effects like changes to UVs or materials.
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—a single sentence with no extraneous words. It is efficiently front-loaded, though it omits useful details that could be added without much length.
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 destructive tool with three parameters and no schema descriptions, the description is too thin. It lacks parameter explanations and usage context, even though the output schema partially compensates for return value clarity.
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 provides no explanation of the parameters (object_name, delete_loose, merge_distance). While parameter names are somewhat self-explanatory, the description fails to add meaning or guide usage, which is a significant gap for a tool with 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 a specific action ('Hapus' = remove) on a specific resource ('vertex ganda + geometri lepas' = double vertices + loose geometry). It distinguishes this as a cleanup operation, though it does not explicitly differentiate from similar siblings like 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 is given on when to use this tool versus alternatives. With siblings like merge_by_distance and validate_geometry, the description offers no criteria for selection, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior, and the description reinforces this by saying 'Hapus semua' (delete all). It adds useful context beyond the annotation by explaining that setting property to 'all' removes all keyframes, which is not evident from the schema or annotations alone.
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, compact sentence with no filler. It front-loads the main action and includes a parenthetical clarification. However, it sacrifices some clarity for brevity, so not a perfect score.
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 destructive tool, the description provides minimal context. It does not mention return values, reversibility, or whether the action must be the active one. The output schema is present but not shown, so the description cannot rely on it to explain outcomes.
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 must compensate, but it only clarifies the special 'all' value for the property parameter. It does not explain the object_name parameter, other possible property values, or the default 'location', leaving significant ambiguity for agent use.
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 ('Hapus' meaning remove) and the resource ('keyframe properti' from the object's action). It distinguishes itself from animation creation tools like insert_keyframe and animate_location, though it could be more explicit about targeting keyframes 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 guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, target selection, or complementary tools, leaving the agent to infer usage 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?
Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds no extra context about side effects, such as whether existing objects are overwritten or if a new object is always created. Minimal additional behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence, front-loaded with the key verb and resource. No wasted words or repetition of structural fields.
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 6 parameters, zero schema descriptions, and an existing output schema, this description falls short. It doesn't explain parameter semantics, output, or when the tool should be chosen over alternatives.
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 hints at the 'points' and 'bezier' parameters, leaving 'name', 'closed', 'extrude', and 'location' unexplained. This is insufficient for a 6-parameter 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 function: creating a bezier/poly curve from points. It uses a specific verb and resource, distinguishing it from sibling tools like create_object or create_text.
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 or when to avoid this tool. It doesn't mention alternatives or preconditions, leaving the agent 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a mutating/destructive operation (readOnlyHint=false, destructiveHint=true). The description adds no behavioral context beyond listing light types, such as how it affects the scene, selection, or existing lights. This is minimal but acceptable given the annotation coverage.
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 extremely short and front-loads the verb and object, which is good for scanning. However, it under-specifies a tool with 8 parameters, making it feel incomplete rather than efficiently concise. It could be 4 if the schema were richer, but here it is too sparse.
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 (8 parameters, 0% schema coverage, existing output schema), the description is far from complete. It provides no context on how parameters interact, what the created light object's defaults are, or common use cases. The output schema doesn't compensate for missing input semantics.
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 bears the burden of explaining all 8 parameters. It only reveals possible values for light_type, leaving name, color, energy, shadow, location, area_size, and spot_angle completely undefined. This is insufficient for a tool with this many 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 states the verb 'Buat' (Create) and resource 'cahaya' (light), and explicitly lists the four supported types (POINT/SUN/SPOT/AREA). This clearly differentiates it from sibling tools like create_camera or setup_three_point_lighting.
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. It does not mention conditions like needing a specific light type, or when setup_three_point_lighting might be more appropriate. No exclusions or contextual cues 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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the write behavior is known. The description adds no new behavioral context such as overwrite behavior, file creation side effects, or confirmation that the entire scene is exported. It relies entirely on annotations without enriching them.
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, compact sentence that efficiently communicates the tool's purpose and supported formats. It contains no fluff and is appropriately sized for a simple export tool, though it could have included a bit more 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 the presence of closely related sibling tools (export_glb, export_selected, export_stl_mm), the description is incomplete. It fails to specify whether 'scene' means the entire scene or selected objects, and it does not mention any output behavior. The existing output schema may help, but the description alone does not adequately equip an agent to choose this tool 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?
The input schema has zero coverage for parameter descriptions. The description lists acceptable values for the 'format' parameter, adding some semantic value beyond the raw schema. However, 'filepath' is left unexplained, and the description does not clarify that it is the destination path or how the file is named. Partial compensation only.
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 identifies the tool as exporting the scene and enumerates supported formats (glb/gltf/fbx/obj/stl/ply/usd/usdz/dae/x3d), providing a specific verb and resource. However, it does not explicitly differentiate from sibling tools like export_glb or export_selected, leaving slight ambiguity about scope (scene vs selection).
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 format list implies this tool is for general scene export in various formats, but the description provides no explicit guidance on when to use it versus alternatives like export_glb, export_selected, or export_stl_mm. It neither names alternatives nor states exclusions, making the usage context implicit rather than 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?
Annotations already mark the tool as destructive, but the description adds no further behavioral details (e.g., whether it replaces or merges existing scene data, or side effects). No contradiction, but no added value beyond 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?
A single sentence that is entirely on-topic and wastes no words. It is front-loaded with the action and lists formats compactly.
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 and annotations, the description does not address import behavior, error handling, or parameter specifics. For a destructive tool, users need more context to use it safely and 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?
Description lists supported formats but does not explain how the 'format' parameter interacts with 'filepath' or what default behavior occurs when format is omitted. Schema has no descriptions, so the tool description fails to compensate for the low 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 imports 3D file formats (glb/gltf/fbx/obj/stl/ply/usd/usdz/dae). The verb 'Import' is specific and differentiates from sibling export tools. No 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 or when not to use it. The description only states what it does, not under what circumstances.
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 include readOnlyHint=false and destructiveHint=true, so the description is not the sole source. It adds the behavioral constraint "memerlukan UI" (requires UI), which is useful context, but does not explain side effects or what exactly changes in the viewport.
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 directly states the purpose and a key prerequisite. No unnecessary words or 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?
For a simple one-parameter tool, the description covers the basic purpose and a runtime requirement. However, it lacks usage guidance and parameter detail, and the output schema is not visible in the input. It is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter with 0% description coverage. The description only says "ke sebuah objek" (to an object), which vaguely links the 'name' parameter to an object but does not specify that it must match an existing object name or any format requirements. It fails to compensate for the missing schema documentation.
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: "Frame viewport 3D ke sebuah objek" (frame viewport 3D to an object), which is a specific verb+resource. It does not explicitly differentiate from sibling tools, but the tool name and description together make the function evident.
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. The only additional note is "memerlukan UI" (requires UI), which is a prerequisite rather than usage context or exclusion.
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 only readOnlyHint=true in annotations, the description adds minimal behavioral context. It lists the checked issues but does not describe what happens during validation, whether a selection is needed, or what form the QC report takes beyond what the output schema might already provide.
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 phrase, efficiently conveying the core purpose without unnecessary detail. It is appropriately sized, though slightly 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?
Despite having no parameters and an output schema, the description lacks usage context and behavioral nuance. It is adequate for a simple read-only validation tool but does not fully explain when or how it should be invoked relative to other 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?
The tool has zero parameters, so the schema coverage is 100%. According to the baseline for 0 parameters, this receives a 4; there is no need for parameter explanation in the description.
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 identifies the tool as a QC report covering three specific geometry issues: collisions (BVH), z-fighting, and floating objects. This distinguishes it from sibling tools like mesh_analysis or check_manifold, though it is a noun phrase rather than an explicit verb phrase.
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. The description only states what it does without indicating typical use cases, required setup, 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?
Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation and destructive nature are known. The description adds the mechanism 'via Solidify' and the unit 'mm', providing some context beyond annotations. However, it does not disclose whether the Solidify modifier is applied non-destructively or baked, nor what happens to existing geometry. This is acceptable given the annotation coverage but leaves 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 a single brief phrase with no redundant words or fluff. It effectively conveys the core mechanism and unit in four words, making it front-loaded and appropriately sized. There is no wasted content, so it earns a perfect conciseness score.
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 annotations and an output schema, the description is too sparse to be complete. It lacks usage guidance, fails to differentiate from sibling tools, and provides minimal behavioral context. For a tool that mutates geometry and may be destructive, the agent would need more information about when and how to use it, such as whether the modifier is applied or baked. The short description leaves the agent under-informed.
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 input schema has 0% description coverage, so the description must compensate. It mentions 'mm', which clarifies the unit for thickness_mm, and the tool name implies object_name refers to the target object. However, it does not explicitly explain parameter meanings or relationships. The unit information adds value, but the description is too terse to fully compensate 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Ketebalan kulit via Solidify (mm)' clearly states the tool adds wall thickness using the Solidify modifier, with units in millimeters. It provides a specific verb and resource, making the purpose understandable. However, it does not distinguish itself from the sibling tool 'solidify_mesh', which appears to perform a similar operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or references to sibling tools like 'solidify_mesh' or 'bevel_mesh'. The agent is left to infer the appropriate context, which is inadequate given the presence of closely 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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows it's a destructive operation. The description adds no extra behavioral context (e.g., scope, reversibility, or side effects) but also doesn't contradict the 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 a single, concise sentence that front-loads the action and key modes. It contains zero redundant words, making it efficient, though it sacrifices important details for 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 the destructive nature, 4 optional parameters, and no schema descriptions, the description is incomplete. It lacks scope (all objects vs selected), mode interaction details, and cautionary guidance. The presence of an output schema does not compensate for the missing operational semantics.
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 attempts to explain the two parameter modes (prefix+index and search/replace), which maps loosely to the parameters. However, it doesn't clarify how parameters combine, which mode takes precedence, or what start_index does beyond its 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?
The description uses a specific verb ('Ganti nama' – rename) and resource ('objek' – objects), and distinguishes the two naming modes (prefix+index or search/replace). It's clear but doesn't explicitly mention 'batch' scope or differentiate from rename_bone beyond saying '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?
No guidance is given on when to use this tool versus alternatives like rename_bone or other batch operations. There are no usage context hints, exclusions, or 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?
Annotations already indicate a destructive write operation, but the description adds no extra behavioral context such as name collision behavior, whether the material is automatically assigned to a selected object, or the effect on 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?
Single concise sentence, front-loaded with the action and resource, and lists the key properties without 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 destructive nature and 10 parameters, the description only lists properties and does not explain side effects (e.g., new material block creation, assignment behavior, or result when materials with the same name exist). An output schema exists but is not provided, so the description still needs to cover these 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 has 0% description coverage, so the description must compensate. It lists most parameters (warna, roughness, metallic, emisi, IOR, alpha, transmission, blend mode) but omits the 'name' parameter and doesn't clarify the split between emission_color and emission_strength, 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?
Description states 'Buat material PBR (Principled BSDF)' with specific properties (color, roughness, metallic, emission, IOR, alpha, transmission, blend mode), clearly indicating a create operation and distinguishing it from sibling tools like assign_material or list_materials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention exclusions such as 'use assign_material to apply an existing material' or any 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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds no additional behavioral context (e.g., whether files are overwritten, if selection is required). It does not contradict the annotations, so a score of 3 is appropriate.
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 filler. It is front-loaded and every word serves the purpose. However, it is quite sparse, potentially leaving out important nuances, so it doesn't earn a perfect 5.
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, the description is minimally adequate for understanding its core function. However, it lacks guidance on when to use it, parameter details, and any behavioral caveats despite having annotations and an output schema. The presence of many similar export tools heightens the need for more contextual information.
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%, and the description does not explain the 'filepath' or 'format' parameters. It implies an export destination but lacks details on format defaults or required/optional semantics. Since the description fails to compensate for the schema's lack of documentation, a low score is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 objek yang dipilih' (Export selected objects), using a specific verb and resource. The 'selected' scope distinguishes it from sibling tools like export_glb, export_stl_mm, and export_scene. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There are no mentions of when it is appropriate, prerequisites, or exclusions. Sibling tools like export_glb and export_stl_mm suggest format-specific options, but this tool's relation to them is not clarified.
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 readOnlyHint annotation already signals a safe read operation. The description adds value by specifying the informational scope (transform, topology, material, modifier), but it doesn't disclose any additional behavioral details such as output structure or potential edge cases, which is acceptable given the simple read-only 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?
The description is a single, compact sentence that front-loads the core purpose and enumerates the relevant information categories. Every word contributes to the meaning, with 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?
For a simple read-only info tool with one parameter and an output schema present, the description provides sufficient context: it names the object scope and the specific data areas covered. It could mention that the tool requires an existing object name, but the output schema and readOnlyHint fill in the remaining 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?
With one required parameter 'name' and 0% schema description coverage, the description should explicitly clarify that 'name' is the object identifier. It only says 'satu objek' indirectly, which implies the parameter refers to the object, but it does not explicitly explain the parameter's meaning or expected 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 'Info satu objek: transform, topologi, material, modifier' clearly states the tool fetches information about a single object, listing the exact categories of information returned. It differentiates from siblings like get_scene_info by focusing on a single object, though it doesn't explicitly contrast with overlapping tools like get_object_detail_summary.
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 guidance is provided. The description does not state when to prefer this tool over siblings such as get_object_detail_summary, mesh_analysis, or get_scene_info, nor does it offer any exclusions 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?
The annotation readOnlyHint=true already signals the safe read-only behavior. The description simply states 'list' without adding any further behavioral context such as return format, error conditions, or dependence on an existing armature. It is consistent with annotations but adds little beyond them.
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 phrase of four words, entirely front-loaded with the core purpose. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, an output schema, and a readOnly annotation, the description is minimally adequate. However, it lacks any context about prerequisites (e.g., the armature must exist) or what the returned list will contain, so it 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.
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 elaborate on the 'armature_name' parameter at all. The parameter name is self-explanatory, but the description 'Daftar tulang armature' adds no semantic detail beyond what the schema field title 'Armature Name' already provides. With low coverage, the description 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 'Daftar tulang armature' translates to 'List armature bones', which is a specific verb+resource combination. It clearly distinguishes this tool from siblings like add_bone, remove_bone, and rename_bone by indicating its read-only listing 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, no prerequisites, and no exclusions. The only usage cue is the tool's name and the phrase 'list', which implies its purpose but offers no explicit contextual 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?
The description adds minimal behavioral context beyond the annotations. It confirms the mutation (setting base color) but does not disclose side effects such as overwriting existing values or requiring an existing material.
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 wasted words, making it easy to parse and front-loaded with 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 straightforward setter, the description covers the core action but omits edge cases like missing objects or materials. Given the tool's simplicity and presence of an output schema, this is partially complete.
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 must compensate. It does mention 'Base Color' and 'object', giving some semantic hints, but does not explain the color array format (e.g., RGBA) or that color is optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 the Base Color of the active material of an object. The specific term 'Base Color' distinguishes it from sibling tools like set_emission or set_transparency.
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 offers no guidance on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent to infer usage solely from the 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?
The annotations indicate a destructive write operation (destructiveHint=true, readOnlyHint=false), but the description adds no context about side effects, such as affecting rendering performance or needing a compatible GPU. It only repeats the action and lists options, without explaining consequences.
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 wasted words. It is appropriately sized for the simple tool it describes.
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 setter with a well-defined value list, the description covers the core semantics, but omits when to use it and what effects setting the device has. It is minimal but not inadequate, leaving room for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description for the 'device' parameter (coverage 0%), but the description compensates by enumerating the accepted values (CPU/GPU/OPTIX/CUDA/HIP/METAL). This gives the agent the necessary vocabulary to make a valid choice, though it does not explain the meaning or trade-offs of each option.
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 ('Atur device Cycles' meaning 'Set Cycles device') and lists the supported device options (CPU/GPU/OPTIX/CUDA/HIP/METAL), making the tool's purpose unambiguous. It could be improved by explicitly mentioning the Cycles render engine's compute device, but the name and options make that 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 is provided on when to use this tool versus alternatives like set_render_engine or set_render_samples. It does not mention prerequisites (e.g., GPU availability) or contrast with other device-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?
The description adds the scoping detail 'current scene', which clarifies which scene is affected. However, it does not elaborate on side effects beyond what the annotations already indicate (destructiveHint=true, readOnlyHint=false). No contradiction with 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?
A single concise sentence that is front-loaded and earns its place. There is no wasted text, and the structure is appropriately minimal for a simple tool.
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 low-complexity tool with one parameter, output schema, and annotations covering destructive behavior, the description is reasonably complete. It states the target (current scene) and the action, though it could mention if the scene name must be unique or other constraints.
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 description does not explicitly explain the 'name' parameter, though it is clearly implied as the new scene name. No additional meaning beyond the schema's type and default 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 'Ganti nama scene saat ini' clearly states the tool renames the current scene, using a specific verb (rename) and resource (current scene). It is unambiguous but does not explicitly differentiate from sibling tools, though no sibling tool for renaming scenes exists.
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 any exclusions or prerequisites. It simply states what the tool does without contextualizing its 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 annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds some context by stating 'all modifiers' are baked to 'mesh data', but it does not disclose that the modifiers are likely removed or that the geometry becomes permanently altered. This is additional but not rich behavioral detail beyond the 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 a single short sentence with no redundant words. It is front-loaded and efficiently conveys the core action, earning its place without any filler.
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 is destructive and has a required parameter, the description is too sparse. It lacks usage guidance, parameter semantics, and behavioral consequences beyond what annotations already provide. The presence of an output schema does not compensate for these 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?
Schema description coverage is 0%, and the description does not explain what object_name refers to. It is reasonable to infer object_name is the mesh to bake modifiers onto from the tool's purpose, but the description itself contributes no explicit parameter meaning. The parameter is left entirely to the schema field name, which is insufficient when coverage is zero.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Bakar semua modifier ke data mesh' clearly states the tool bakes all modifiers to mesh data, using a specific verb and resource. This distinguishes it from sibling tools like add_modifier, list_modifiers, and remove_modifier, which concern managing modifiers rather than permanently applying 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 is provided about when to use this tool versus alternatives such as add_modifier or boolean_operation. The description is purely declarative and offers no context for selecting it over other modifier-related operations.
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 already indicate destructiveHint=true and readOnlyHint=false, covering the mutation risk. The description adds a useful behavioral constraint: it affects all objects of a specified type, not individually selected ones. However, it does not disclose whether existing scale values are overwritten, whether 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 a single concise sentence with no fluff, immediately conveying the core purpose. It is front-loaded and efficient, earning a top score for structure.
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 batch mutation tool with destructive potential, the description is minimal. It does not explain return values (though an output schema exists), does not describe what happens if the types list is empty or invalid, and lacks information about whether the scale is absolute or relative. The description is too sparse for an agent to fully anticipate the tool's 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 description coverage is 0%, so the description must compensate. It mentions 'scale' and 'type' which map to the parameter names, but it does not explain that 'scale' is an array of three numbers (x,y,z) or that 'types' is an array of strings like MESH and CURVE. The defaults in the schema carry some meaning but are not explicitly 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 'Atur skala semua objek dengan tipe tertentu' clearly states a specific action: setting the scale of all objects matching a given type. It uses a specific verb ('set') and resource (scale of all objects by type), distinguishing it from sibling tools like batch_set_location or transform_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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or when another tool (e.g., transform_object for single-object scaling) would be more appropriate. Usage is only implicitly inferred from the action itself.
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 declare readOnlyHint=true, which already covers the safety profile. The description adds that the output is an ASCII scene, but it does not elaborate on the coordinate system, orientation, or how to interpret the spatial telemetry data.
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 short sentence and front-loads the key concept (ASCII scene). It is concise but somewhat terse, which slightly undermines 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?
Given the tool has no parameters and an output schema exists, the description is minimally adequate. However, it lacks detail on the output's exact content and interpretation, forcing the agent to rely on the output schema for return value specifics.
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 there is nothing to explain. The description correctly implies no inputs are required, and with 100% schema coverage, the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides a 'spatial ASCII scene' for the agent, indicating a specific format and resource. This distinguishes it from siblings like get_scene_info (structured info) and render_frame (image). However, the verb is implicit and the term 'telemetri' is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_viewport_screenshot or render_frame. The description simply states what it returns without specifying use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not contradict the readOnlyHint annotation and adds no extra behavioral context beyond the basic function. Since the annotation already covers the read-only nature, the description lacks additional useful detail such as return format or scope.
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 is appropriately sized for a simple tool, though it could be slightly more informative without being verbose.
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 read-only list tool, the description is minimally viable but does not clarify the exact scope of nodes returned (e.g., all nodes vs. only shader nodes). The output schema may cover return values, but the description is still thin.
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% for the material_name parameter, and the description does not elaborate on the parameter's meaning or format beyond the name. It fails to compensate for 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 action (list) and the resource (shader nodes in a material node tree). It distinguishes itself from sibling tools like add_shader_node or remove_shader_node by specifying the reading operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply states what it does without indicating context, 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?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the behavioral detail that transforms are relative by default, which is useful, but does not disclose side effects like overwriting existing pose transforms or any prerequisites. This matches the pattern of adding some context beyond 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 a single sentence, front-loaded with the main action, and contains no fluff. It is appropriately sized for the straightforward action it describes.
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 6 parameters, a destructive operation, and an output schema not described, the description is too sparse. It omits prerequisites (e.g., armature/bone existence, Pose Mode), error conditions, the meaning of 'relative', and side effects. The brevity is not sufficient 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (6 parameters, none described in the schema). The tool description only mentions the 'relative' default, adding a small semantic detail for that one parameter. However, it does not explain location, rotation, scale, bone_name, or armature_name, nor their formats or units, failing to compensate 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 'Atur transform pose bone (relatif secara default)' clearly states the action (set/adjust), the resource (pose bone transform), and a key behavioral note (relative by default). This distinguishes it from sibling tools like reset_pose or add_bone.
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, no prerequisites, and no exclusions. It only implies use for setting pose transforms without explaining context such as needing Pose Mode or how it differs from transform_object.
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 annotations already indicate destructiveHint: true, and the description simply restates the removal action. It does not disclose additional behavioral details such as whether the removal is permanent, what happens if the modifier does not exist, or whether it affects the object's geometry. No extra context is added beyond the annotation.
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 short sentence that immediately conveys the core function. It is front-loaded and contains no filler or 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?
For a simple removal tool with an output schema and destructive annotation, the description is mostly adequate, but it omits any mention of error conditions or prerequisites (e.g., object must exist). Given the presence of an output schema, the lack of return-value explanation is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage). The description only clarifies that removal is 'by name', which hints at modifier_name, but it does not explain the role of object_name or any format requirements. This provides minimal help to 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 ('remove') and the target resource ('modifier'), and specifies the selection criterion ('by name'). This distinguishes it from sibling tools like add_modifier or apply_modifiers.
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, such as list_modifiers or apply_modifiers. No prerequisites or exclusions are mentioned. The only clue is the tool name and bare description.
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 already indicate a write operation (readOnlyHint=false, destructiveHint=true). The description adds the scope constraint that samples apply to the active engine, which is useful behavioral context. However, it does not disclose potential side effects like impact on render time or quality, nor does it explain how it interacts with different engine types beyond the parenthetical mention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler words. It front-loads the action and includes scope information in a compact manner. While it could be more informative, it does not waste words. The use of a non-English phrase is still concise but may slightly reduce universal 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?
For a one-parameter tool with an output schema and annotations, the description is minimally viable. It states the purpose and scope, but lacks usage guidance and detailed parameter semantics. Given the simplicity of the tool, the absence of these details is a visible gap, though not crippling.
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 schema description coverage at 0%, the description carries the burden of explaining the 'samples' parameter. It merely repeats the parameter name and provides a generic context ('set sample'), but does not explain what the value controls, acceptable ranges, or how the default (64) behaves. The schema shows the type and default, but the description adds no new 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 states a clear action ('set samples for active engine') with a specific resource (render samples) and scope (engine aktif, Cycles/EEVEE). It distinguishes this tool from siblings like set_render_engine and set_render_resolution, which target different aspects of 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit context for when to use this tool vs alternatives. It does not mention prerequisites (e.g., having an active engine) or contrast with sibling tools that may also affect render quality, such as set_cycles_device or set_render_resolution. The only implicit cue is the phrase 'engine aktif', which hints at a precondition but does not guide 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?
Annotations already declare readOnlyHint=false and destructiveHint=true, indicating a potentially destructive write operation. The description adds the 'absolute or relative' distinction, which is useful context for how the transform is applied, but does not disclose additional behavioral traits like whether it overwrites existing transforms, requires object selection, or has undo limitations. The description doesn't contradict the annotations, but the added value beyond annotations 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 a single concise sentence that front-loads the core operations and mode. Every word adds meaning, and there is 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 tool's destructive nature and the presence of an output schema, the description is too sparse. It doesn't mention return values, coordinate systems, or any side effects (e.g., whether existing transforms are replaced). While the output schema may define return structure, the description lacks operational context needed to safely invoke this tool. The brief description is not enough for a tool with four required parameters and a destructive hint.
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 schema description coverage at 0%, the description must compensate for missing parameter meaning. It maps 'move/rotate/scale' to location, rotation, and scale parameters, and 'absolut atau relatif' to the 'relative' boolean. However, it does not explain the expected array formats (e.g., [x,y,z] vs [x,y,z,w]) or units, and the 'name' parameter is left completely undefined. The high-level mapping helps but is insufficient for a tool with five 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 identifies the tool's purpose: moving, rotating, and scaling objects (transform). It specifies the resource (objects) and the modes (absolute or relative), which helps distinguish it from sibling tools like apply_transform or batch_set_scale. The verb 'transform' plus the explicit list of operations makes 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?
The description provides no guidance on when to use this tool versus alternatives such as apply_transform or duplicate_object. It doesn't mention prerequisites, exclusions, or alternative tools for specific scenarios. This leaves the agent to infer usage solely from the tool name.
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 declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the 'polygon budget' context but does not disclose additional behavioral traits such as whether it requires a selected object, computes in real-time, or returns aggregate stats. With annotations partly covering safety, this is marginally sufficient.
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 sentence with no filler, directly stating the tool's purpose. It is front-loaded and skips unnecessary details, achieving maximum conciseness with reasonable 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?
Given the tool's simplicity (no parameters, output schema present, read-only annotation), the description is minimally sufficient. However, it lacks any explanation of how the polygon budget is calculated, what might affect the report, or how to interpret unusual results. An output schema likely covers the return format, but the description could still benefit from a sentence on prerequisites or expected 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 tool has zero parameters, so the schema already fully describes the input (none). The description adds semantic context about what the report covers, which is helpful even though there are no parameters to explain.
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 'Laporan anggaran poligon scene' (scene polygon budget report) clearly communicates the tool's output: a report on polygon budget/performance. It goes beyond the tool name, specifying the focus area, which helps distinguish it from broader tools like get_scene_info or mesh_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 guidance is provided on when to use this tool versus alternatives. Siblings include mesh_analysis, get_scene_info, and scene_summary, but the description does not explain how analyze_performance differs or when it should be 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 annotations already declaring destructiveHint=true and readOnlyHint=false, the description adds the context that the action is assigned to an object, implying modification of the object's data. However, it does not disclose whether existing action assignments are overwritten 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the primary action, containing 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 basic function, but lacks context about prerequisites (e.g., object must exist), behavior when the action name already exists, and relationship to other animation tools. Output schema exists, so return values are covered, but side effects for a destructive tool are not elaborated.
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 must compensate. It implies action_name is the Action datablock and object_name is the target object, but it does not clarify optionality, default values, or naming constraints. 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 that it creates an Action datablock and assigns it to an object, which is a specific verb+resource. This distinguishes it from sibling tools like list_actions and 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?
There is no guidance on when to use this tool vs alternatives, nor any exclusions or prerequisites. The description only states the function without context on appropriate 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?
Annotations already indicate readOnlyHint=true, which the description does not contradict. The description adds context about the depth and content of the summary (topology, material, UV, bones), which is useful. However, it does not disclose details like response format, performance implications, or limitations, but the annotation covers the core safety profile.
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 front-loads the core purpose ('deep summary of one object') and then lists key aspects. There is no unnecessary verbosity, making it highly 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 simplicity (one parameter, read-only annotation, output schema provided), the description is fairly complete. It does not need to explain return values since an output schema exists, and the key details are captured. The ellipsis suggests more omitted content, but this is acceptable for a summary 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 has one parameter 'name' with 0% description coverage. The description implies the parameter is the object identifier ('one object'), but does not explicitly explain that 'name' refers to the object's name. This is minimally adequate but leaves some ambiguity, especially since no schema description 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 tool provides a 'deep summary of one object' and lists specific aspects (topology, material, UV, bones), making the purpose explicit. It does not explicitly differentiate from sibling tools like get_object_info or get_model_blueprint, but the focus on 'detail' and listed topics gives reasonable 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?
There is no guidance on when to use this tool versus alternative tools. The description only describes what it does, but does not mention exclusions, prerequisites, or scenarios where another tool 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds that the tool returns object count, names, types, and locations, which is useful context. However, it does not mention performance, return format, or scope (e.g., all objects vs. selected), leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, terse sentence. It is concise and front-loaded, but the Indonesian language may reduce clarity for non-Indonesian agents. Still, it contains no unnecessary words and delivers the core message efficiently.
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 and no parameters, the description adequately covers the tool's purpose, specifying the key data returned (count, names, types, locations). However, it lacks guidance on how it differs from scene_summary or get_scene_graph, which 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 tool has zero parameters, so there is no parameter information to document. The baseline of 4 applies, as the empty schema requires no explanation and the description correctly avoids parameter details.
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 the tool returns scene condition: number of objects, names, types, and locations. This is a clear resource, though it lacks an explicit verb like 'get' or 'list' and does not distinguish it from similar sibling tools such as get_scene_property or scene_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_scene_graph, get_object_info, or get_scene_property. The description only states what it does, with no contextual usage 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 readOnlyHint annotation already communicates that this is a safe read-only operation. The description adds minimal behavioral context beyond the action itself, but there is no contradiction. It would benefit from clarifying what 'GN' means or the scope of modifiers listed.
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 unnecessary words. It conveys the core action and target efficiently, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is minimally viable. However, it fails to clarify the 'GN' acronym or differentiate from the sibling list_modifiers, leaving a contextual gap for agents unfamiliar with the domain.
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 elaborate on the object_name parameter. While the parameter name is self-explanatory, the description does not compensate for the missing schema description, leaving potential ambiguity about the expected value format or scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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) and specific resource (GN modifiers on an object). It distinguishes from the generic sibling tool list_modifiers by specifying 'GN' (Geometry Nodes) subset, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the generic list_modifiers or any other alternative. The description lacks context about selection criteria, prerequisites, or exclusionary 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?
The description identifies what is deleted (unused datablocks) and aligns with the destructiveHint annotation. It adds little beyond the annotation itself, lacking details on irreversibility or file-scope effects, so a mid-range score is appropriate.
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, front-loading the core action. It is appropriately brief for a no-parameter tool, though it could incorporate more usage context without becoming verbose.
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 destructive nature and the presence of an output schema, the description is minimally complete: it names the action and target but omits usage context and scope. With no parameters and clear annotations, a score of 3 reflects the adequate-but-basic level of 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 tool has zero parameters, and the input schema is an empty object, so the description cannot add parameter-level detail. Per the rubric, a baseline of 4 is given for tools with no 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 action 'Hapus' (delete) and the resource 'datablock yang tidak dipakai' (unused datablocks), making its purpose evident. However, it does not explicitly distinguish this from similar cleanup tools like cleanup_scene, so it falls short of 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 alternatives such as cleanup_scene or delete_object. There is no mention of prerequisites, scope, 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?
Annotations indicate destructiveHint=true and readOnlyHint=false. The description adds the constraint that UI is required, which is useful behavioral context. However, it does not elaborate on destructive effects or what happens to existing weights, so transparency is partial.
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 filler words. It front-loads the core action and adds the UI requirement 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?
For a tool with destructiveHint=true and no param descriptions, the description is too minimal. It doesn't specify prerequisites, error conditions, or behavior differences from similar tools. The UI requirement is mentioned, but overall completeness is low.
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 2 parameters with no descriptions (0% coverage). The description does not explain the parameters beyond the tool name itself; it relies on parameter names object_name and armature_name. This is insufficient compensation for the zero 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: 'Parent mesh ke armature dengan bobot otomatis' (Parent mesh to armature with automatic weights). This is a specific verb+resource and distinguishes from sibling parenting/weight tools like add_armature_modifier or assign_vertex_weights.
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 '(memerlukan UI)' (requires UI), which gives a condition for when the tool can be used. However, it does not mention alternatives or when not to use it, so guidance is limited to this single 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 readOnlyHint annotation already signals no mutation, and the description adds value by naming the specific geometric checks performed (boundary/non-manifold edges, holes, Euler). It does not describe any unexpected side effects, which is consistent with a read-only analysis 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 extremely concise, using a short, front-loaded phrase that immediately conveys the purpose. It is not a full sentence but is free of redundancy and unnecessary detail, making it efficient for an agent 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 simplicity of the tool (one parameter), the readOnlyHint annotation, and the presence of an output schema, the description sufficiently covers the core functionality. It names the analyses performed, and return-value details are left to the output schema. The lack of parameter explanation is a minor gap but not critical for such a simple 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 single parameter object_name has no schema description (0% coverage). The description does not mention or elaborate on the parameter, leaving the agent to rely solely on the parameter name. With zero coverage, the description should have compensated by at least referencing the object name, but it does not.
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 'Analisis watertight: edge boundary/non-manifold, lubang, Euler' clearly specifies the tool's function as watertight analysis and lists concrete checks (boundary/non-manifold edges, holes, Euler characteristic), distinguishing it from broader siblings like validate_geometry or mesh_analysis. However, it uses a noun phrase rather than a verb, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The description implies usage for watertight checking but does not mention sibling tools or clarify scenarios where it should be preferred, such as before 3D printing or boolean operations.
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 readOnlyHint annotation already communicates the safe, read-only nature. The description adds minimal behavioral context ('lists all actions') but does not elaborate on output format, potential limitations, or other behavioral traits. It is consistent with annotations, so no contradiction, but adds little beyond them.
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, short sentence that front-loads the core purpose. There is no redundancy or unnecessary detail, making it appropriately concise for a straightforward list operation.
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 low complexity, absence of parameters, and presence of an output schema, the description is essentially complete. It states the operation and scope ('in file') without needing to describe return values. However, it lacks any usage context, which slightly lowers the completeness score.
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 is fully covered. According to the rubric, the baseline for 0 params is 4. The description does not add parameter details, but none are needed.
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 'Daftar semua action di file' clearly states the tool lists all actions in the file, using a specific verb ('list') and resource ('actions'). It distinguishes itself from other list_* tools by naming a unique resource, though it does not explicitly differentiate from siblings.
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. The description lacks context about prerequisites, typical use cases, or exclusions, leaving the agent without direction on when to select 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 annotation `readOnlyHint=true` already establishes its safe read-only nature, so the description doesn't need to restate that. It adds the output content (count, frame range, engine) but no further behavioral traits such as performance implications or data freshness. This meets the lower bar set by annotations without adding significant extra 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 a single, concise sentence that front-loads the main purpose (complete scene summary) and lists the key output items. Every word contributes information; there is no waste or 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 simple nature (0 params, read-only annotation, and existing output schema), the description covers the essential information. It mentions the main output fields, though 'jumlah' (count) is ambiguous about what is being counted (objects, frames, etc.). Since the output schema exists, this ambiguity is partially mitigated, but a bit more context 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 tool has zero parameters, so the description cannot add parameter-level meaning. Per the rubric, 0 params yields a baseline score of 4. The description instead clarifies the semantics of the output, which is helpful for a no-argument tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces a scene summary with specific contents (count, frame range, engine). The verb 'Ringkasan' and resource 'scene' are specific, and it partially distinguishes from siblings like get_scene_info and get_scene_property by focusing on aggregate metrics. However, it doesn't explicitly differentiate itself beyond content listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_scene_info or get_scene_property. The description only explains what it does, not the context where it is preferable, nor any 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?
Annotations already indicate destructiveHint=true, so the agent knows it's a mutating operation. The description adds no further behavioral context, such as side effects on existing settings or prerequisites. It only lists valid values, which is more relevant to parameters than 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 a single concise sentence that immediately states the action and the allowed options. It front-loads the key information with no unnecessary words or 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?
For a simple one-parameter setter, the description covers the core action and valid values. However, it lacks usage guidance and behavioral side effects, and the output schema's presence is not leveraged to explain return values. It is adequate but has clear gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and no enum values for the engine parameter. The description compensates by explicitly listing the three allowed values (CYCLES, EEVEE, WORKBENCH), providing essential meaning that the schema alone 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 sets the render engine and explicitly lists the accepted values (CYCLES / EEVEE / WORKBENCH). This is a specific verb-resource combination that distinguishes it from sibling tools like set_render_resolution or set_render_samples.
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. The description only states what it does, without mentioning when it should be applied (e.g., before rendering) or any exclusions. Usage is only implied by the tool 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?
Annotations already declare destructiveHint=true and readOnlyHint=false, indicating a write/destructive operation. The description adds no further behavioral context (e.g., overwrite behavior, file existence handling). This is acceptable given the annotations, but no extra value is added beyond the purpose statement.
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, short sentence that directly states the action and target. There is no fluff or redundant information, making it highly concise 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?
The tool is simple with one parameter and has an output schema, so the description doesn't need to explain return values. However, it lacks usage context relative to sibling tools (e.g., when to use export_glb over export_scene), and there is no mention of file path handling or overwriting behavior, which are important given the destructive hint.
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 for the sole parameter 'filepath'. It does not provide details on expected path format, file extension, or how the path is interpreted. The parameter name is somewhat self-explanatory, but lacks crucial semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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), the resource (entire scene), and the target format (GLB). It distinguishes itself from sibling tools like export_selected and export_stl_mm by specifying 'seluruh scene' and 'GLB'.
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 phrase 'seluruh scene' implies usage for exporting the whole scene rather than selected objects, providing an implicit differentiation from export_selected. However, there is no explicit guidance on when to prefer this over export_scene or other export tools, and no mention of prerequisites or limitations.
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 readOnlyHint annotation already declares the operation is read-only. The description adds what data is included (topology, physics, dimensions, anchor) but does not disclose other behavioral traits such as performance or limits. With annotations covering safety, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the core function. Every word earns its place, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter) and presence of an output schema, the description is minimally complete. However, it lacks usage guidance and parameter detail, which limits completeness in real-world selection scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero coverage for the single parameter obj_name, and the description does not explain it beyond implying it refers to a mesh. The parameter name is somewhat self-explanatory, but the description fails to compensate for the lack of schema documentation, leaving ambiguity about required format or 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 it provides a complete technical blueprint of the mesh, enumerating specific content areas (topology, physics, dimensions, anchor). This distinguishes it from sibling tools like get_object_info or get_object_anchors by implying a comprehensive overview.
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 context is implied by the word 'lengkap' (complete), suggesting use when a full technical blueprint is needed, but there is no explicit guidance about when to use this tool versus alternatives like mesh_analysis or get_object_info.
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?
Beyond the readOnlyHint annotation, the description adds no behavioral context such as return format, source of documentation, or potential limitations. The example hints at input format but doesn't describe what happens on success or failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the purpose and immediately accompanied by an illustrative example. Every word is useful, and the structure is ideal for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description is largely complete. It covers the core purpose and gives an example. Minor gaps include not mentioning whether the topic must be a valid Blender API identifier, but the example mitigates this.
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 for the 'topic' parameter, but the description provides a concrete example ('bpy.ops.mesh.primitive_cube_add') that clarifies the expected format as a dotted API path. 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 provides detailed documentation for Blender API topics, with a concrete example ('bpy.ops.mesh.primitive_cube_add'). This distinguishes it from sibling tools like search_api_docs, which implies searching rather than fetching detailed docs.
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 gives no explicit guidance on when to use this tool versus alternatives such as search_api_docs. It only states the function without indicating context, 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 annotation readOnlyHint=true already establishes the safe read-only nature of the operation. The description adds that it searches 'included' documentation and should be read before coding, but does not disclose search behavior such as result format, matching, or limits. It adds some value beyond the annotation without contradicting 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 two concise sentences, front-loaded with the core action and followed by a usage directive. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description adequately covers scope ('included' docs) and usage timing ('before writing code'). It does not detail the return value, but the presence of an output schema shifts that burden, and the description is sufficient for an 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a 'query' string with zero description coverage. The description implies 'query' is the search phrase, but provides no syntax, formatting, or examples. Since the schema gives no guidance and the description only trivially defines the parameter, the description fails to meaningfully compensate for the missing schema documentation.
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 a specific verb ('search') and resource ('included Blender API documentation'), making the tool's purpose unambiguous. However, it does not differentiate from the sibling tool get_python_api_docs, which may also provide API documentation access.
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?
'Baca SEBELUM menulis kode' explicitly instructs when to use this tool (before writing code), providing clear contextual timing. It does not mention alternatives or exclusions, but the guidance is direct and actionable.
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 already indicate readOnlyHint=false and destructiveHint=true, so the tool is known to modify state and potentially be destructive. The description adds the toggling behavior (select or deselect) but provides no further context about what 'deselect' means, whether it clears the entire selection, or what impact the destructiveHint implies in practice.
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, short sentence in Indonesian that immediately conveys the core function. No filler or redundancy; it is optimally concise 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?
The tool is very simple (one optional parameter, no required args), and an output schema exists, so return values are covered. However, the lack of parameter explanation and the vague behavioral disclosure (especially given destructiveHint) leave notable gaps. The description is minimally sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'action' with a default but no description or enum, and schema description coverage is 0%. The description fails to explain what values 'action' can take, even though the description mentions both selecting and deselecting, which likely maps to action values. This leaves the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool selects or deselects all objects ("Pilih atau batalkan semua objek"). This is a specific verb+resource pair that distinguishes it from sibling tools like select_object (single object) and select_by_type (type-based selection).
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 intended use is implied: use this when you want to select or deselect all objects at once. However, there is no explicit guidance on when to prefer this over alternatives like select_by_type or select_object, and no mention of any prerequisites or side effects.
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?
Annotations already declare the tool as non-read-only and destructive. The description adds that it must run in edit mode and requires the native Blender UI, which is an important behavioral constraint for headless or background workflows. It does not contradict annotations, and the added context is useful.
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 communicates the core action and key constraints without redundant phrasing. It is appropriately sized for a simple tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no schema descriptions, and an output schema, but the description explains neither the parameter semantics nor the expected behavior beyond 'add bone'. The edit mode/UI note is useful, but critical operational details (e.g., how head/tail are interpreted, what armature_name does, what the collection parameter means) are missing, making the description incomplete for effective use.
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 schema has 6 parameters with zero description coverage, and the tool description provides no parameter details whatsoever. Parameter names like head, tail, and collection are minimally informative but the description fails to compensate for the absence of schema descriptions, leaving crucial meaning (units, coordinate handling, defaults behavior) unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Tambah' (add) and resource 'tulang ke armature' (bone to armature), clearly distinguishing it from sibling tools like remove_bone, rename_bone, or create_armature. The edit mode and UI requirement are additional 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?
The description states 'edit mode; memerlukan UI di Blender asli', which provides clear context that the tool requires the user to be in Blender's edit mode with an active UI. However, it does not explicitly mention alternatives or when-not-to-use conditions, so it stops short of full exclusion 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 annotations indicate readOnlyHint=false and destructiveHint=true, but the description adds no additional behavioral context. It does not mention side effects, potential for irreversible changes, error handling, or any execution environment details beyond the fact that it runs Python inside Blender. The description provides no behavioral traits beyond what annotations already state.
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 states the purpose, the second gives usage guidance. It is front-loaded and free of unnecessary detail, earning its place. No fluff or repetition of schema 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 an arbitrary code execution tool, the description covers purpose and usage guidance, but lacks behavioral warnings (e.g., risk of destructive changes) and parameter specifics. However, annotations cover the destructive hint and an output schema exists, reducing the need to describe return values. The strong guidance to prefer structured tools adds context, but the description still misses safety caveats expected for a powerful 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 schema has one parameter 'code' with zero description coverage. The description says 'Jalankan Python bebas', which clarifies that 'code' is the Python code to be executed in Blender. However, it does not elaborate on expected syntax, whether it is a script or expression, access to bpy, or any constraints. It minimally compensates for the schema 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 'Jalankan Python bebas di dalam Blender' (run free Python in Blender), specifying the verb and resource. It also distinguishes itself from sibling tools by advising to prioritize structured tools, implying it is a fallback for arbitrary code execution. However, it does not explicitly name alternative tools or further scope the purpose beyond 'free Python'.
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 provides usage guidance: 'Utamakan tool terstruktur' (prioritize structured tools) and 'gunakan search_api_docs dulu untuk mencari API yang benar' (use search_api_docs first to find the correct API). This clearly tells the agent when to use this tool (after structured tools and API docs are insufficient) and suggests a prerequisite step.
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 already declare readOnlyHint=true, and the description's 'Ringkasan' (summary) aligns with a read operation. The description adds scope (entire scene, per object) but does not disclose what the summary contains (e.g., dimensions, hierarchy, statistics), leaving some uncertainty about the output.
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 phrase in Indonesian, front-loaded with the key idea. It is efficient with no wasted words, though it could benefit from a bit more structure (e.g., a sentence) to separate the purpose from scope.
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 (zero params, read-only) and presence of an output schema, the description is minimally adequate. However, with many sibling tools that could overlap (get_scene_info, scene_summary, get_object_detail_summary), it does not fully disambiguate what type of summary is returned, making it less complete than it could be.
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 description does not need to explain parameter semantics. The schema coverage is effectively 100% (vacuously), and the baseline for 0 params is 4, which is appropriate here.
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 'Ringkasan per objek seluruh scene' (Summary per object of the entire scene) clearly indicates this tool returns a summary of objects in the scene. It distinguishes from siblings like get_scene_info and scene_summary by specifying 'per objek' (per object), though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'seluruh scene' (entire scene) and 'per objek' (per object) provide clear context for when to use this tool: when needing an overview of all objects rather than a single object or high-level scene info. However, it does not mention when not to use it or explicitly reference 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 destructiveHint=true and readOnlyHint=false in annotations, the tool's mutation nature is already known. The description adds no additional behavioral context, such as side effects, prerequisites (e.g., material must exist), or reversibility. It simply restates 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It front-loads the core action and immediately gives a clarifying example, making it highly 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 setter tool, the description plus schema and annotations are mostly sufficient. However, it lacks guidance on error conditions (e.g., node or input not found) and does not explain the effect of not providing the optional value parameter (defaulting to 0). This prevents it from being 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?
The schema has no parameter descriptions (0% coverage), but the description's example (Roughness on Principled BSDF) effectively clarifies how material_name, node_name, and input_name map to real concepts. The value parameter is not explicitly explained but its purpose is self-evident from the tool's 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: set the value of a shader node input, with a concrete example (Roughness on Principled BSDF). This distinguishes it from sibling tools like add_shader_node or connect_shader_nodes, which perform different 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 through the example, suggesting this is for setting arbitrary shader node input values. However, it does not explicitly compare with alternatives or provide when-not-to-use guidance, which would be helpful given the many shader-related sibling 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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds useful behavioral context: it is 'background-safe' and performs the operation without weight painting. This clarifies the scope of the operation and execution environment, going beyond the structured annotation hints without contradicting them.
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 a parenthetical note. Every element ('add Armature modifier', 'without weight painting', 'background-safe') carries essential information, with no redundant or filler content. It is front-loaded and appropriately sized.
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 only 2 required parameters, the description covers the core action and two key behavioral caveats. However, it does not mention prerequisites such as the object being a mesh or the armature existing, nor error conditions. The context is adequate but not comprehensive, so a middle score is appropriate.
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 the parameters. It does not explicitly mention object_name or armature_name, nor does it map them to 'mesh' and 'armature' in the text. Although parameter names are self-explanatory, the description adds no additional meaning or constraints beyond the schema, failing to bridge the coverage 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 ('Tambah' = add) and the resource ('modifier Armature ke mesh' = Armature modifier to mesh), and further specifies 'tanpa weight painting' (without weight painting). This distinguishes it from generic modifier tools like add_modifier or weight-painting tools like auto_rig_weight. The purpose is unambiguous and 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 context through phrases like 'background-safe' and 'tanpa weight painting' (without weight painting), but it does not explicitly state when to use this tool versus alternatives such as add_modifier or auto_rig_weight. There are no exclusions or alternative tool names, so guidance is 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?
Annotations already declare destructiveHint=true, which signals destructive behavior. The description adds minimal context beyond the annotation; it does not detail consequences like permanent removal or behavior on missing objects. With annotations covering the safety profile, a score of 3 is appropriate as the description adds only the 'by name' scoping.
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 short sentence: 'Hapus objek berdasarkan nama.' (Delete object by name.) It is concise, front-loaded, and contains no unnecessary words. Every word contributes to the tool's 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?
This is a simple delete tool with one parameter and an output schema. The description is sufficient for basic selection, and annotations provide the destructive warning. However, it could benefit from noting that it deletes a single object (not batch) or mentioning error behavior when the object is not found. Given the tool's low complexity, the description is nearly 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 schema has one required parameter 'name' with 0% description coverage. The description clarifies that the name parameter identifies the object to delete, which adds a bit of meaning over the schema property title. However, it does not add format details, constraints, or edge-case semantics, so it only partially compensates for the low 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 action (delete) and the resource (object) with a specific criterion (by name). This distinguishes it from sibling tools like batch_delete_by_type and purge_orphans, making the tool's 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting a single object when its name is known, but it does not explicitly mention when to use this tool versus alternatives, nor does it provide exclusions or refer to sibling tools. It lacks explicit guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description discloses that old animation is cleaned first, which is specific destructive behavior. It also states the scope (location/rotation) and that a frame range is set, providing transparency about what will be modified. No contradiction with 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 a single concise sentence that is front-loaded with the main action (clean old animation) and then the new behavior. It contains no wasted words and is easy to parse.
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 (9 parameters, destructive behavior, output schema), the description is minimal. It conveys the core behavior but lacks detail on parameter usage, return values, or edge cases. The output schema exists, so return format is covered, but parameter handling and special conditions are 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?
With 0% schema description coverage, the description needed to compensate by explaining parameter meanings. It only vaguely references 'location/rotation' and 'frame range', which map to some parameters (start_loc, end_loc, start_frame, end_frame) but does not explain any of the 9 parameters explicitly. The required object_name is not mentioned 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 the tool's function: it cleans old animation and creates new location/rotation movement with a frame range. The verb 'Bersihkan' (clean) and 'buat' (create) specify the action and resource, distinguishing it from sibling tools like animate_location or animate_rotation which only animate without resetting.
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: use this tool when you want to discard existing animation and start fresh. However, it does not explicitly mention when to use it over alternatives, nor does it provide exclusions or prerequisites. The context is clear but not fully 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?
Annotations already indicate a mutating and destructive tool. The description adds that the tool applies multiple operations (primitive, scale, subdivision, bevel, smooth), which is useful context. However, it does not disclose what exactly is destructive (e.g., whether it replaces an existing object or requires a selected object), so it adds only partial behavioral 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, concise sentence that immediately states the tool's purpose and key capabilities. It contains no filler or 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?
For a tool with 7 parameters, no schema descriptions, and destructive annotations, the description gives a high-level overview but lacks important details such as prerequisites, behavior on existing objects, and parameter specifics. The presence of an output schema helps, but the description still leaves the agent under-informed for correct 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 7 parameters with 0% description coverage, so the description must compensate. It mentions primitive, scale, subdivision, bevel, and smooth shading, which map to type, scale, subdivisions, bevel_width, and smooth parameters. However, it omits name and location, and provides no details on units, formats, or valid values, 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 it creates a complete basic model from scratch, listing the included features (primitive, scale, subdivision, bevel, smooth shading). This distinguishes it from sibling tools like create_object or bevel_mesh, which focus on individual 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 implies this is for building a full basic model in one step, which provides context for when to use it. However, it does not explicitly mention alternatives or when not to use it, such as needing finer control with individual tools like subdivide_mesh or bevel_mesh.
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 annotations already indicate a destructive, non-read-only operation. The description adds that multi-bone configurations require manual weights, which is a behavioral caveat beyond the annotations. It does not detail what is destroyed, but this is partially covered by destructiveHint=true.
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 in Indonesian, front-loading the main action and adding a conditional note. No waste, easily scannable.
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 leaves out critical details about parameters, the meaning of 'background', and how the binding works. For a complex tool with 4 parameters, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has four parameters with no descriptions, and the tool description does not explain any of them. There is a hint that manual weights are needed for multi-bone, which vaguely relates to auto_weight, but no explicit mapping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 the verb 'buat' (create) with a clear resource ('armature dan rantai tulang') and outcome ('ikat ke mesh'), stating it builds a rig from scratch and binds it to the mesh. This distinguishes it from sibling tools like auto_rig_weight and create_armature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for starting a fresh rig and warns that multi-bone setups in the background need manual weight assignment, which is a clear contextual guideline. However, it does not explicitly name alternatives or state when not to use it, so it's not a full 5.
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 adds valuable behavioral details beyond the annotations: it explains that alignment uses the actual bounding box (not origin), and it defines the reference parameter behavior (defaults to first object). This goes beyond the destructiveHint annotation by clarifying how the alignment is performed, though it does not mention other 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 and well-structured: two sentences, front-loaded with the action, using compact notation for parameters. Every sentence adds substantive information without unnecessary filler, 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.
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 (though not shown), the description does not need to explain return values. It covers the core behavioral details (bounding box alignment, modes, reference) and provides enough context for a 4-parameter tool. Minor gaps remain, such as the effect on object transformations or whether alignment is relative to the scene, but overall it is complete enough 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?
With 0% schema description coverage, the description compensates by explaining axis (X|Y|Z), mode (MIN/CENTER/MAX with meaning), and reference (fixed object, default first). However, it does not explicitly describe the required 'names' parameter, leaving its role implicit as the objects to align. Partial coverage of parameters, but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Alinea' (align) with the resource 'objetos' (objects), and specifies the scope 'por su bounding box real' (by real bounding box). This distinguishes it from sibling tools like snap_to_anchor or transform_object by highlighting the alignment basis, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when aligning objects by bounding box rather than origin) but does not explicitly mention alternatives or exclusions. It lacks explicit when-not-to-use guidance or comparison with similar sibling tools, making it only 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?
Annotations already indicate destructiveHint=true, so the description does not need to restate the mutating nature. It adds useful context about the spacing parameter's semantics (uniform vs. fixed gap in meters) but does not disclose potential side effects such as modifying object origins or overwriting existing transforms. Given annotations cover the core safety profile, a score of 3 reflects that additional 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 concise, consisting of two sentences that are front-loaded with the main action and then detail the two spacing modes. Every sentence adds meaningful information without repetition or fluff. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (3 parameters, destructive hint, no schema description coverage), the description explains the essential behavior and the critical spacing logic. It does not mention the return value or explicitly warn about side effects, but the annotations cover the destructive nature. Overall, it is complete enough for an agent to understand the tool's core functionality and use it 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?
Schema description coverage is 0%, so the description must compensate. It effectively explains the key parameter 'spacing' with its two states and units (meters), and mentions 'axis' as the distribution line. However, 'names' is left implicit (obviously the objects to distribute). While it doesn't fully document all parameters, it covers the most nuanced one, earning a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: distributing objects along an axis. It specifies two distinct modes (uniform spacing preserving extremes vs. fixed gap in meters), which distinguishes it from siblings like align_objects or array_object by its precise behavior. The verb 'reparte' is specific and the resource ('objetos sobre un eje') 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when distributing objects along an axis with either uniform or fixed spacing) but does not explicitly state alternatives or exclusions. It does not mention when not to use it or how it compares to align_objects or array_object. Thus, usage guidance is only implied, not explicitly detailed.
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?
Annotations already indicate readOnlyHint=false and destructiveHint=true. The description adds useful context: it creates real objects (not a modifier) and explains that linked=True shares the mesh. This goes beyond the annotations without contradicting them.
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 the action and key distinction. Every phrase adds value, with no 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?
The description covers the core behavior and the linked parameter, but omits critical parameters like count and axis that control the array's size and direction. While an output schema exists, the description should still address these key inputs for a complete picture.
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 'gap' (own size plus gap) and 'linked' (shares mesh), but does not explain 'axis', 'count', or 'name'. With 5 parameters, this partial coverage leaves gaps for important repetition settings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 in a row, separating copies by size plus gap. It explicitly distinguishes itself from the Array modifier by creating real, individually selectable/editable objects, which sets it apart from siblings like duplicate_object or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contrasts this tool with the Array modifier, implying when to use it (when real objects are needed) and noting linked=True as a lighter alternative. While it doesn't enumerate all alternative tools, the key trade-off is clearly communicated.
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 show readOnlyHint:true, and the description aligns fully, describing a read-only introspection operation. It adds modest context by mentioning that the signature includes permission info, implying permission-aware usage, but no further behavioral details are 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 highly concise, using two short sentences to deliver the core purpose and a usage directive with no redundancy. Every word earns its place.
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 single-parameter read-only introspection tool with an output schema, the description covers what it does and when to use it. No additional context is needed; the output schema handles return value 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 description coverage is 0%, so the description must compensate for the lone 'name' parameter. It indirectly indicates that 'name' refers to a tool from the catalog, but it doesn't explicitly define the format or validation, leaving the parameter meaning inferable but not fully 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 returns the exact signature of a catalog tool, listing parameters, types, requiredness, permission, and examples. This specific verb+resource description distinguishes it from siblings like list_registry_tools and call_registry_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 instruction 'Consúltala antes de invocar' (consult it before invoking) explicitly tells the agent when to use the tool. It doesn't mention alternatives or exclusions, but the context is clear enough for an agent to know to call this before invoking another 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 readOnlyHint annotation already declares the read-only nature, so the description carries less burden. It adds the scope 'in file', clarifying it lists only materials in the current document. It does not disclose additional behavioral details like return format, but an output schema exists to cover that.
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 short sentence, immediately front-loaded with the verb and resource. It contains no unnecessary words or filler.
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?
The tool is simple: no parameters, readOnlyHint annotation, and an output schema present. The description fully conveys the purpose and scope ('all materials in file'), while the output schema handles return value specifics.
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 description does not need to explain parameter semantics. The baseline of 4 for 0-parameter tools applies, and the description adds no redundant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all materials in the file, with a specific verb ('list') and resource ('materials'). It distinguishes from sibling tools by indicating a read-only enumeration operation, not creation or assignment.
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 is given on when to use this tool versus alternatives. Usage is implied: call when you need all materials in the current file. There are no exclusions or alternative tool mentions.
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 readOnlyHint annotation already indicates this is a safe read operation, and the description is consistent with that by using 'Lista' (lists). The description adds minor context by mentioning the catalog size and available categories, but it does not disclose additional behavioral traits such as return size, pagination, or potential costs. With annotations covering the safety profile, a score of 3 is appropriate.
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, then lists the valid categories in a compact way, and ends with a clear usage instruction. The category list is necessary for parameter understanding, and while it adds length, every sentence earns its place. It is not overly verbose for the information conveyed.
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 the presence of an output schema, the description covers the essential aspects: what it does, when to use it, and what parameters it accepts. It does not explain return values, but the output schema compensates for that. It could mention the read-only nature, but the annotation covers that. Overall, it is sufficiently complete for a catalog-listing 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%, and the description compensates by explaining that the 'category' parameter filters the list and enumerates all valid category values (objects, materials, lights, etc.). This gives meaning beyond the raw string type and default, though it does not explicitly state that omitting the category returns the full catalog.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Lista el catálogo completo de tools de Blender' (Lists the complete Blender tools catalog), with a specific verb and resource. It distinguishes itself from siblings by explicitly saying to use it before call_registry_tool, and it provides a filtering capability that is not present in other listing 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 gives an explicit usage directive: 'Úsala antes de call_registry_tool' (Use it before call_registry_tool), which indicates when to use this tool. It also lists valid categories for filtering, providing context for typical usage, but it does not mention alternatives or when not to use the 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 readOnlyHint annotation already declares this as a safe read operation. The description adds only the target resource (Blender) and does not disclose additional behavioral traits such as response format or potential timeouts, but for a ping tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that fully conveys the tool's purpose with no wasted words. Front-loaded and easily scannable.
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 zero-parameter ping tool with a read-only hint and an output schema, the description is complete. There are no complex inputs to document, and the purpose is sufficiently clear for an agent to invoke it 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?
There are zero parameters, so the baseline is 4. The description does not need to elaborate on parameter meaning since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Pemeriksaan liveness' (liveness check) and clearly identifies the resource as Blender. It is unambiguous and distinguishes this health-check tool from the many other Blender manipulation 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 is provided. However, for a ping tool, the usage is self-evident: to verify that Blender is responsive. The context implies usage without stating 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?
Annotations already set destructiveHint=true and readOnlyHint=false, so the description doesn't introduce contradictions. It adds a caution to inspect parameters via describe_registry_tool, which is useful, but doesn't elaborate on specific side effects, error handling, or scope of destructive actions beyond what annotations provide.
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: the first states the core action with an example, the second gives a mandatory prerequisite step. No fluff, information is front-loaded and directly useful.
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?
An output schema exists, so return values needn't be described. The description covers the tool's purpose, parameter format, and a key workflow step (describe first). It doesn't discuss edge cases or error behavior, but given it's a generic dispatcher and annotations cover safety, it's sufficiently complete 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?
The schema has no descriptions for parameters (0% coverage), so the description carries the burden. It provides a concrete example mapping 'name' to a tool name and 'params' to an object with key-value pairs, clarifying both parameters effectively despite their generic nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Ejecuta una tool del catálogo por nombre' (executes a tool from the catalog by name). It gives a concrete example with 'object.create' and params, which distinguishes it from siblings like describe_registry_tool (describes) and list_registry_tools (lists).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using describe_registry_tool first to know the exact parameters, providing a clear alternative and context for when this tool is appropriate. It doesn't cover exclusions or all alternatives, but the guidance is actionable.
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 readOnlyHint annotation already covers the read-only nature. The description adds meaningful behavioral context beyond the annotation: the requirement for a Blender UI and the output format (PNG). No contradiction with annotations 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 a single, front-loaded sentence that conveys the action, target, format, and a key constraint with no wasted words. It is appropriately concise for a zero-parameter tool.
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 0-parameter tool with both an output schema and readOnly annotation, the description provides the core action, output format, and an environmental prerequisite. It is complete enough for selection and invocation, though it could be slightly more explicit about what viewport it captures.
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 and the input schema is empty, with 100% description coverage. Per the rubric, a 0-parameter tool receives a baseline of 4; the description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Tangkap' (capture) and names the resource and output format: 'viewport 3D ke PNG' (3D viewport to PNG). This clearly states what the tool does and distinguishes it from rendering tools like render_frame or render_viewport_to_path.
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 prerequisite 'memerlukan UI Blender' (requires Blender UI), implying when not to use (e.g., headless mode), but it does not explicitly state when to choose this tool over alternatives or provide exclusionary guidance. The usage context is implied, not clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds useful behavioral context: it does not truncate or flatten, and it preserves the full hierarchy. It does not explicitly state side effects, but the annotation covers safety. This goes beyond the annotation by describing data completeness.
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 dense sentences, front-loaded with the core purpose and then the contrast/usage guidance. Every word earns its place; no 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?
With an output schema present and readOnly annotation, the description need not explain return values. It covers purpose, usage, and differentiates from sibling tools. The only gap is the parameter, which is penalized separately. Overall the tool is well contextualized for a read-only hierarchy inspection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional boolean parameter (include_data) with 0% schema description coverage. The tool description does not mention this parameter or explain what 'data' is included/excluded, leaving the agent to guess. Since coverage is low, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the complete scene hierarchy (parent→child) with dimensions, materials, modifiers, and polygons. It explicitly differentiates itself from get_scene_info, so 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use it to understand an assembly before modifying it, and contrasts with get_scene_info which truncates/flattens. This tells the agent when to choose this tool over 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?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds nothing beyond this, but for a simple list tool, no further behavioral disclosure is necessary. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information. It is immediately front-loaded and every word carries meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, read-only, output schema present), the description is sufficient. The output schema covers return values, and annotations cover safety. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. Per the baseline for 0 params, a score of 4 is appropriate; there is nothing to disambiguate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Daftar format export yang didukung' clearly states the tool lists supported export formats. It uses the verb 'list' (implied by 'Daftar') and a specific resource (export formats), distinguishing it from sibling export tools like export_glb and export_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?
The purpose is self-evident: use this tool to see supported export formats. No explicit alternatives are mentioned, but the context is clear and there are no exclusions, so it meets the 'clear context, no exclusions' level.
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 readOnlyHint=true already covering the read-only nature, the description adds behavioral context by noting it avoids downloading the entire scene, indicating a lightweight, targeted operation. It doesn't detail edge cases or return behavior, but the output schema partially compensates.
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 front-loads the action and includes a valuable use-case hint. No filler or redundancy; 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 the output schema and read-only annotation, the description covers the essential purpose and context (lightweight search, avoid full scene download). It could explicitly mention matching behavior or result limits, but the current level is adequate for a search tool with four optional 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?
Schema description coverage is 0%, so the description must compensate. It mentions all four parameters in natural language: name, type (MESH, LIGHT, CAMERA), minimum mesh complexity (min_polygons), and material (has_material). This gives meaning beyond the bare schema, though exact semantics (e.g., substring matching) are not fully 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's action ('Busca objetos') and the resource (objetos) along with specific filter criteria (name, type, min mesh complexity, material). It differentiates itself from siblings by adding 'Evita descargar la escena entera', highlighting its lightweight search capability.
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 this tool: when you need to find objects by criteria and avoid downloading the full scene. It provides clear context for usage but does not explicitly name alternative tools or state when not to use it, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given the annotations (destructiveHint=true), the description adds valuable behavioral context: atomicity and rollback behavior, and that a failure leaves the scene intact. This goes beyond the annotations by explaining transaction semantics and how failures are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with line breaks, a clear format definition, and a concrete example. Every sentence adds value: purpose, step schema, atomic behavior, usage preference, and example. 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 complex batching tool, the description covers the key aspects: what steps look like, how atomicity works, and why to use it. It does not elaborate on the `label` parameter or behavior when `atomic=false`, but the output schema and annotations provide some context, and the core semantics are well covered.
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 carries the burden. It thoroughly explains `steps` with a precise format and concrete example, and clarifies the effect of `atomic=true`. The `label` parameter is not mentioned, but it is a minor omission given the default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Ejecuta varias operaciones como UNA transacción con rollback,' which is a specific verb plus resource, clearly distinguishing it from individual sibling tools. It explains the batch nature and transaction semantics, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states a preference over chaining individual calls ('Prefiérela a encadenar llamadas sueltas') and explains why (avoids half-built scenes). It does not mention specific scenarios where the tool should not be used, but the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral details beyond the readOnlyHint annotation, such as the interpretation of negative gap values ('negativo = se solapan') and the fact that it can measure collision. This adds meaningful context for the agent without contradicting the annotation.
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, tightly packed with specific information and no filler. It front-loads the primary action and details, making it easy to scan and understand.
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 output schema exists, the description does not need to explain return structure. It covers the main use cases (single object and pair relationship) and provides enough context for the agent to decide when and how to use it, making it highly complete for its 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?
With 0% schema description coverage, the description partially compensates by indicating that one or two objects can be measured, mapping implicitly to name_a and name_b. However, it does not explicitly name or detail the parameters, leaving the agent to infer the mapping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 a specific verb ('Mide') and resource (an object or two objects), detailing the measured quantities: dimensions, bbox, center, volume, distance, gap, and collision. This distinguishes it from siblings like get_object_info by focusing on spatial measurements and relationships.
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 use case: 'Verifica encajes antes de anclar' (verify fits before anchoring), indicating when to use the tool. However, it does not mention alternatives or explicit exclusions, so it falls short of a 5, but still offers strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![blender-mcp-ultra MCP server](https://glama.ai/mcp/servers/HitamLegit6777/blender-mcp-ultra/badges/card.svg)](https://glama.ai/mcp/servers/HitamLegit6777/blender-mcp-ultra)

Score Badge

Copy to your README.md:

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

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/HitamLegit6777/blender-mcp-ultra'

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