blender-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
The vast majority of tools target distinct domains (objects, materials, cameras, modifiers, nodes, etc.) with clear action-resource pairs. However, a few tools like execute_python vs evaluate_expression and set_frame_range vs set_playback_range could cause confusion, though descriptions clarify their intents.
Naming Consistency4/5Tool names overwhelmingly follow a verb_noun snake_case pattern (list_objects, create_material, set_transform, delete_object), making navigation predictable. Minor deviations include 'ping', 'remesh', 'playback_control' and the adjective-initial 'smart_uv_project', which break strict consistency but remain readable.
Tool Count1/5With 175 tools, this server is drastically over-scaled for any agent to effectively choose from, far exceeding the 50+ threshold for extreme mismatch. Even for a comprehensive application like Blender, the tool surface should be partitioned into several smaller, purpose-specific servers.
Completeness3/5The server covers an impressively wide range of Blender functionality, including objects, materials, lighting, animation, physics, nodes, armatures, and particles. However, notable lifecycle gaps exist, such as no mode-switching tool, no rename/material/action/image operations, no action deletion, and no way to delete UV maps or vertex groups, forcing reliance on escape hatches like execute_python.
Average 3.4/5 across 175 of 175 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.jsonto 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?
There are no annotations, so the description must disclose behavior. It does not explain side effects, whether existing connections are overwritten, how sockets are matched, or any other behavioral traits beyond the bare word 'connect'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. A single sentence that merely restates the tool name is not effective conciseness; it lacks the detail needed to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four required parameters, no annotations, and an output schema that is not elaborated. The one-sentence description is grossly insufficient for an agent to understand how to connect compositor nodes correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines four required parameters with zero description coverage. The description does not explain from_node, from_output, to_node, or to_input, leaving the agent unable to infer what values to provide or the relationship between them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Connect compositor nodes.' essentially restates the tool name connect_comp_nodes. It names a verb and resource but provides no additional clarity about what 'connect' entails or what distinguishes it from shader or geometry node connection tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 connect_shader_nodes or connect_geonodes. It does not mention 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It simply repeats the name and provides no behavioral details such as side effects, scene interaction, or return behavior. It fails to disclose anything beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. It is not concise in a valuable way; it merely restates the tool name without adding useful content, so it does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and the sparse description, the tool is not adequately contextualized. There is no mention of how the grease pencil object is created, what it affects, or what the output contains, making the description insufficient even for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 parameters name or location. It adds no semantic meaning beyond what the schema already provides, and the schema itself lacks descriptions, so the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a grease pencil object' is essentially a restatement of the tool name (create_grease_pencil). It offers no additional detail about what a grease pencil object is or any scope, making it tautological rather than informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives like create_object or create_gp_stroke. The description gives no context for selection.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention whether weights are replaced or added, whether the operation is destructive, or any special requirements, leaving behavior opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence—very concise. However, it is under-specified, lacking essential details, so it doesn't fully earn its place as an adequate tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no parameter descriptions, and no behavioral context. The one-sentence description is far from complete for an agent to confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 four parameters. It mentions 'bone' and 'vertex group' but doesn't clarify parameter meanings like 'vertices' (indices) or 'weight' (the value to assign).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Assign vertex weights') and the target ('a bone's vertex group'), using a specific verb and resource. It is distinguishable from siblings like create_vertex_group or set_vertices, though it doesn't explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or alternatives. It doesn't mention whether the vertex group must pre-exist or how this relates to other rigging tools.
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?
With no annotations, the description carries the full burden, but it only states 'Bake particle simulation.' It does not disclose that baking is likely a mutating operation that replaces cached data, nor any dependencies, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, which is efficient. However, it is under-specified rather than appropriately sized; it conveys purpose but omits needed context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with two parameters and no annotations, this description is insufficient. It lacks usage prerequisites, parameter semantics, and behavioral context, even though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation for the required 'object' parameter or optional 'system' parameter. The description does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'bake' and identifies 'particle simulation' as the target resource, which clearly distinguishes it from sibling tools like bake_physics. However, it does not elaborate on scope or effect beyond the action itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or what prerequisites are needed. The description is limited to the action and does not mention requirements such as an existing particle system or when baking is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It states 'Create' implying mutation, but does not explain side effects, prerequisites, or what happens to the original nodes. It also leaves 'selected nodes' undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler words. However, it is under-specified for a tool with 3 parameters, so the brevity comes at the cost of essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 incomplete for a mutation tool. It does not clarify the role of 'material', the meaning of 'selected nodes', or how this tool relates to node editing workflows. Insufficient guidance for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain any parameters. 'material' is required but not mentioned in the description, and 'nodes' is only vaguely hinted at as 'selected nodes'. The agent cannot determine the meaning or format of these parameters from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Create' and resource 'node group' clearly define the action, and 'from selected nodes' indicates the input. It distinguishes itself from sibling tools like create_shader_node and create_geonode by operating on a group level, though it doesn't specify which node tree 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives. No mention of prerequisites, such as having nodes selected or a material open in the node editor, nor any comparison with related tools like add_node_group_instance.
Agents often have multiple tools that could apply. Explicit usage guidance like "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—no mention of what settings are included, whether the object must exist, or error conditions. It does not contradict the annotation, but it doesn't enrich it either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, but it is under-specified. It achieves brevity at the cost of clarity, so it is acceptable but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema and two parameters, the description is minimal. It doesn't explain which particle system is being queried, how system selection works, or the relationship to add_particle_system/set_particle_property. The agent would need to rely on the output schema and parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions for its parameters, and the description 'particle system settings' provides no additional meaning for the 'object' and 'system' arguments. The agent must infer their roles from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves particle system settings, using a specific verb ('Get') and resource ('particle system settings'). However, it lacks detail about which object/system and how it relates to sibling tools, so it earns a 4 rather than 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/5Does 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_particle_property or get_physics_info. The description is a bare getter statement with no context about prerequisites or exclusions.
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?
No annotations are provided, and the description adds no behavioral context beyond the action implied by the tool name. It does not disclose whether removal is destructive, irreversible, or if there are dependencies. The description essentially restates the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and immediately front-loads the action and target. However, it lacks contextual details that would earn the highest score, but as far as word economy, it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a removal tool with two required parameters and no annotations, the description is minimal. The existence of an output schema reduces the need to explain return values, but the absence of usage context, prerequisites, and error conditions makes it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate but only mentions 'by name', which hints at the 'name' parameter. The required 'object' parameter is entirely unexplained, leaving the agent unclear about how to specify which object contains the particle system.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'remove' and the resource 'particle system', and clarifies the selection method 'by name'. However, it does not explicitly differentiate from sibling particle system tools like add_particle_system or set_particle_property, though the inverse relationship is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any prerequisites or exclusions. For example, it doesn't state that the object must exist or that the particle system must be attached to the specified 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?
With no annotations, the description carries full burden for behavioral disclosure. It reveals the mutation intent but omits key details such as side effects on transforms, whether parenting is hierarchical in a scene graph, or any constraints (e.g., cyclic parenting). This leaves the agent uncertain about the operation's consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff, but it is under-specifying for the operation. It could include essential parameter roles or use-case examples without becoming verbose, so it is not appropriately sized for a mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, but given its mutating nature and the presence of many sibling tools, the description lacks critical context about object types, scene graph implications, or return behavior. Even though an output schema exists, the description does not sufficiently explain the operation's scope or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not clarify that 'child' refers to the object to be parented and 'parent' the new parent. The two string parameters are left ambiguous, forcing the agent to guess their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('set') and the resource ('parent-child relationship between objects'), making it distinct from sibling tools like clear_parent. 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 Guidelines1/5Does 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 like clear_parent or set_transform. There are no prerequisites, exclusions, or context about 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?
With no annotations provided, the description carries full responsibility for disclosure. It only says 'Add a constraint' without revealing details such as whether the constraint is appended to existing ones, whether it requires the bone to be in a certain mode, or what the returned output represents. This is minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is easy to read, but it is under-specified rather than concisely complete. It front-loads the action but omits critical parameter and usage details. It is appropriately short but not information-dense enough to earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with zero schema-level descriptions, no annotations, and an output schema that is not explained, the description is inadequate. It fails to cover what the returned data is or any constraints on the input values, making the tool hard to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the 'type' values but does not explain the meaning of 'object', 'bone', or 'name'. The agent gets no help understanding what object/bone refer to or how the optional name behaves. This is insufficient for a 4-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a constraint to a pose bone and enumerates supported constraint types (IK, COPY_ROTATION, etc.). This is a specific verb+resource combination that distinguishes it from generic constraint tools like add_constraint, though it doesn't explicitly contrast with 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/5Does 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_constraint or set_constraint_property. There is no mention of prerequisites such as an existing armature or pose mode. The description leaves the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It lists the allowed types but does not explain side effects (e.g., whether it replaces existing constraints), how the `object` and `bone` parameters interact, or whether any constraints are added to the active object by default. The behavior remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear list of types. It is not bloated, but it omits critical context, so it earns a slight penalty for being too terse rather than genuinely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the mutation nature (add), four parameters with zero schema coverage, and no annotations, the description is incomplete. It provides no context about object vs. bone constraints, parameter semantics, or how this relates to sibling constraint tools. The presence of an output schema mitigates return-value explanation, but the input side remains poorly documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain any parameters: `object`, `type`, `bone`, or `name`. The type list partially informs the `type` parameter, but the meaning of `bone` (e.g., target bone for IK) and the optional `name` are left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a constraint') and provides an explicit list of constraint types, which adds clarity. However, it does not specify that this tool is for object constraints specifically, leaving potential ambiguity with the sibling tool `add_bone_constraint`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 `add_bone_constraint`, `set_constraint_property`, or `remove_constraint`. The description does not mention prerequisites, preferred 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?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states the action; it does not mention that this modifies node positions, whether it overwrites custom layouts, or any side effects. This is a mutation tool, and the lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the core functionality. It is front-loaded and free of fluff, though it achieves conciseness by omitting necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, minimal parameter info, and the potentially destructive nature of auto-arranging, the description is incomplete. It does not mention side effects, required material identification, or any caveats, making it inadequate for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 'material' parameter. It fails to explain how to specify the material (e.g., by name or ID) or any constraints, leaving the single parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Auto-arrange nodes in a material's node tree' clearly states the action (auto-arrange) and the resource (nodes in a material's node tree). It is specific and distinct from sibling tools like create_shader_node or connect_shader_nodes, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention scenarios, prerequisites, or contrast with other node layout/selection tools, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose what 'remove physics' entails: whether it removes all physics types, affects baked simulations, or is irreversible. The single sentence provides no side effects or behavioral nuances beyond the literal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is easy to scan and front-loaded. It is concise, though it may be under-specified. It earns its place but could benefit from more structure or elaboration without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 required parameters, no annotations, and only a minimal description, the context is incomplete. There is no information on return values (despite an output schema existing), error cases, or how 'type' interacts with the removal. The description is too sparse for a tool with this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 either parameter ('object' and 'type'). It does not clarify what 'type' refers to (e.g., rigid body, cloth) or what format 'object' should be in. The description adds no meaning beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Remove') and resource ('physics from an object'), making its purpose unambiguous. It distinguishes itself from siblings like 'add_physics' and 'set_physics_property' by indicating a removal 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/5Does 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 'set_physics_property' or 'free_physics_bake'. There are no exclusions or context about prerequisites (e.g., does the object need physics already?). The description merely states the action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation provides idempotentHint, indicating repeated calls have the same effect, but the description adds no further behavioral context. It does not disclose what 'position' means (e.g., absolute vs. relative), the coordinate system, or side effects on node connections. Since annotations exist, the bar is lower, but the description still fails to add value 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, front-loading the key action. However, it is so brief that it verges on under-specification. While concise, it lacks enough detail to be truly useful; but for Conciseness dimension, it earns points for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex environment with many sibling node-related tools, yet the description provides minimal context. It does not explain the editor context, coordinate system, return value, or relationships with materials and nodes. The presence of an output schema might help, but without its content, the description remains incomplete for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining it parameters. It only mentions 'position', which maps loosely to the 'location' parameter, but it does not explain 'material' or 'node' at all. Users receive no guidance on what each parameter represents or how to format them, making this a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set a node's position in the editor' clearly identifies the action (set), the object (node's position), and the context (editor). It distinguishes from sibling tools like set_node_input or connect_shader_nodes, which handle other node operations. However, it does not specify which editor (e.g., shader, geometry, compositor) or node type, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, such as needing a material or node to exist, nor does it clarify when a user would choose set_node_position over other node manipulation tools. There is no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of discussing side effects or behavioral traits. 'Configure' implies a state-changing operation, but the description does not disclose whether it creates a collection, modifies existing objects, or has specific requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, immediately stating the action and target. However, it is under-specified, losing some points due to missing useful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, low complexity (1 param), and an output schema that is not referenced in the description, the tool feels incomplete. It does not explain what 'configure' entails, what the collection parameter does, or what output to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not mention the 'collection' parameter at all. The schema only provides a type (string/null), leaving the meaning and effect of the parameter entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Configure' and identifies the specific resource 'rigid body world and collection'. While it doesn't explicitly compare against sibling tools, the tool name itself distinguishes it from related physics/simulation setup tools like setup_cloth_sim or setup_fluid_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 prerequisites, exclusions, or scenarios where a different setup 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?
No annotations are present, and the description does not disclose what 'set up' entails—whether it adds a physics modifier, requires an existing object, overrides prior physics settings, or has side effects. The behavior is entirely opaque beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (six words), which is concise but not necessarily effective. The word 'Template:' suggests it is a placeholder rather than a complete tool description, and the brevity leaves out essential context without being truly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a physics setup tool with siblings and a multi-step operation, the description is severely incomplete. It lacks prerequisites, configuration defaults, relationship to other physics tools, and any indication of what the output schema confirms. The agent would be guessing about the tool's actual effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter 'object' has no schema description and the tool description does not explain it. While the parameter name is self-explanatory, the description adds no semantic context, and with 0% schema coverage, the agent gets no help in understanding its format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Set up') and the resource ('softbody simulation'), which distinguishes it from sibling tools like setup_cloth_sim or setup_fluid_domain. However, it is terse and does not mention that it applies to a specific object, leaving the object parameter implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 add_physics, set_physics_property, or setup_cloth_sim. No exclusions or decision criteria are provided, so the agent cannot determine if this is the right tool for a given task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states only the action and target, without revealing behavior on duplicate names, invalid object type, whether the layer becomes active, or whether the object is mutated in place.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence (9 words) with zero filler. It is efficient, though the brevity comes at the cost of behavioral and parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple (2 required string params) and an output schema exists, the description is thin given 0% schema coverage and no annotations. It lacks preconditions, duplicate-name behavior, and usage context, leaving the agent to infer the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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. 'object' and 'name' are never explained beyond weak inference that 'object' is the grease pencil object and 'name' is the new layer's name. This is minimal added meaning over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action clearly: 'Add a layer to a grease pencil object,' with a specific verb ('add') and resource ('layer' to a target 'grease pencil object'). It is conceptually distinct from related GP siblings, but it does not explicitly name or differentiate itself from alternatives like set_gp_layer_property or create_gp_stroke.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many GP-related siblings, nor does it mention prerequisites such as the grease pencil object needing to exist or whether layer names must be unique. There is no when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the basic operation without revealing side effects, failure modes, or requirements. For example, it does not say what happens if the material is invalid or the node group does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, making it concise. However, its brevity comes at the expense of necessary detail, so it is not optimally calibrated for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no annotations, and an output schema that is not shown, the description is incomplete. It lacks parameter semantics, behavioral context, and any mention of return values or side effects. The tool has enough complexity to require a richer description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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. It does not clarify what 'location' represents, nor the format expected for material or group_name. The schema itself lacks descriptions, so the description offers no compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Add), the object (instance of an existing node group), and the target (material). It distinguishes from siblings like create_node_group which creates a new group, and create_shader_node which adds a generic shader node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as the material or node group needing to exist, nor does it reference any sibling tools. The only implicit usage is inferred from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses one useful trait ('Long-running operation'), but fails to mention whether existing baked data is overwritten, whether the operation blocks or runs asynchronously, whether it requires a specific object state, or that free_physics_bake exists to undo the process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, both earning their place: the first states the purpose, the second flags the long-running nature. It is front-loaded and appropriately sized with zero filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (so return values need no explanation), the description omits critical context. The optional nullable 'object' parameter is unexplained, and with 0% schema coverage and no annotations, the tool is under-specified for a baking operation that mutates scene data and has a counterpart (free_physics_bake) for cleanup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single 'object' parameter, so the description must compensate. It does not: there is no explanation of what 'object' refers to, why it is optional/nullable, or what happens when it is null (e.g., bake all objects vs. selected object). The description adds no parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Bake physics simulation.' This is immediately clear and distinct from most sibling tools. However, it does not differentiate from sibling bake_particles, which performs an analogous operation on particle systems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It doesn't mention prerequisites (e.g., setting up physics with setup_rigid_body_world/setup_cloth_sim), nor does it point to bake_particles or free_physics_bake as related alternatives. 'Long-running operation' is a timing warning, not 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action without detailing side effects (e.g., whether properties are overwritten, if invalid properties cause errors, or if operations are atomic). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the core meaning, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with zero annotations, zero schema descriptions, and an output schema not shown, the description leaves critical gaps. It doesn't clarify what 'property' can be (e.g., custom vs. built-in), value type compatibility, or object applicability, making it incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 'property' and 'multiple objects' but not 'value', and gives no meaning, constraints, or valid values for any parameter. The description adds minimal value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and resource (property on multiple objects), and the phrase 'at once' conveys batch operation. It distinguishes itself from sibling tools like set_transform or set_material_property by being a generic batch setter, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many specific setter tools (e.g., set_transform, set_material_property). The description does not mention exclusions or alternatives, leaving the agent to infer its niche from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the obvious action. It does not explain what happens to existing connections, whether type mismatches are validated, or any side effects that may occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise, front-loaded, and free of filler. However, it is so terse that it sacrifices useful detail, making it efficient but slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six required parameters, an output schema, and zero schema descriptions or annotations, this description is highly incomplete. It does not clarify how to identify nodes, what the input/output values represent, or any constraints, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain any of the six parameters, though the parameter names (from_node, from_output, to_node, to_input) imply the wiring direction. No details are given about acceptable value formats (e.g., string node IDs vs. integer indices) or required modifier names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Connect' and clearly identifies the resource as 'nodes in a geometry node tree,' which distinguishes it from shader or compositor node connectors. It conveys the core function effectively, though it could mention the from/to wiring detail to be even clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 connect_shader_nodes or connect_comp_nodes. The description is just a bare statement of functionality with no context on prerequisites, such as requiring an existing geometry node modifier or a valid node tree.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects and behavior. It only states that a new tree is created or an existing one is used, but does not mention how multiple modifiers are handled, whether existing modifiers are affected, or any prerequisites. This is a significant gap for a tool that mutates an object's modifier stack.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence with no filler. It front-loads the core action and immediately adds a key behavioral detail. However, it may be under-specified, which prevents a perfect score, but it earns credit for being economic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no annotations, and only a minimal description, context is incomplete. The output schema exists but doesn't provide usage context. The description fails to cover prerequisites, parameter relationships, or expected outcomes, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 vaguely relates to the tree_name parameter by mentioning new/existing trees, but it does not explain the meaning of 'name' or 'object'. The description adds minimal value over the raw schema, leaving parameter meanings unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add a geometry nodes modifier.' It also specifies a key differentiator from generic modifier tools by mentioning 'Creates a new tree or uses an existing one.' While it doesn't explicitly name sibling tools, the resource and scope are specific enough to distinguish it from add_modifier and create_geonode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 create_geonode. There are no explicit context cues, prerequisites, or exclusions. The description only implies usage for adding a geometry nodes modifier, which is insufficient 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?
With no annotations, the description alone must disclose safety and side effects. It only says 'Add', implying a mutation, but does not state whether this creates a new UV layer, overwrites existing ones, or requires specific mesh conditions. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clean sentence with no redundant wording. It front-loads the verb and object, making it immediately scannable. Every word earns its place, though it lacks detail covered in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two simple parameters and an output schema, but the description is too sparse for a mutating operation. It does not mention interactions with existing UV maps, object requirements, or the nature of the created UV map, leaving the agent with insufficient context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the parameters. 'object' is implied by the phrase 'mesh object', but 'name' is entirely unexplained, leaving its purpose and default behavior unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and identifies the resource ('UV map') and target ('mesh object'), making the primary function clear. It is implicitly distinct from sibling tools like get_uv_maps and smart_uv_project, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., smart_uv_project) or any prerequisites. There is no context provided beyond the single action statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'delete' without explaining that the operation is permanent, what happens if the keyframe does not exist, or how the 'index' parameter affects deletion (e.g., deleting all keyframes at the frame when index=-1). No side effects or prerequisites are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. However, it is so brief that it fails to convey necessary context for a 4-parameter operation. While it is appropriately front-loaded, it sacrifices critical details required for correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no annotations, and a non-trivial deletion operation. The description is far from complete: it does not explain the role of index, the required object/data_path combination, or the effect on f-curves. An output schema exists but the description should still provide usage context, which it lacks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 adds no parameter information. The names object, data_path, frame, and index are present in the schema but their roles are not clarified. In particular, 'index' with default -1 is ambiguous—does it mean delete all keyframes at that frame? The description is silent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'delete' with a clear resource 'keyframe' and scoping ('at a specific frame'). It is easily distinguished from sibling tools like set_keyframe or clear_animation, which create/modify or remove all keyframes respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that clear_animation exists for removing all keyframes, nor does it explain when one might need to use index to delete multiple keyframes at a frame. The context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure, but it only states the action. It does not explain what happens if the input is not connected, whether the operation is reversible, how it affects existing node values, or any dependencies on the material parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words, and it is front-loaded with the key action. It is appropriately sized for a simple tool, though it borders on under-specification due to its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an unannotated mutation tool with three required parameters and no parameter descriptions, the description is incomplete. It does not cover edge cases, expected behavior on failure, or the overall workflow context (e.g., that it operates within a shader node tree), making it hard for an agent to fully trust correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero descriptions for material, node, and input. The description adds that 'input' refers to an input socket, which is useful, but it does not clarify the format (name vs. index) or the relationship between material and node. With 0% schema coverage, the description insufficiently compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (disconnect) and the target (input socket on a node), distinguishing it from opposite siblings like connect_shader_nodes and from delete_shader_node. However, it does not explicitly say 'shader node', relying on the tool name, and could be more precise about the context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 connect_shader_nodes or set_node_input. There is no mention of exclusions, prerequisites, or typical scenarios, 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?
No annotations are present, so the description must disclose behavioral traits. It fails to mention whether remeshing modifies the object in place, creates a new object, requires specific mesh conditions, or affects UVs/materials. The mutation behavior is implied but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence front-loading the core action and modes. Every word earns its place. The structure is clear, though it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no annotations, and an output schema, the description should provide more context to be complete. It lacks information on the remeshing process, parameter dependencies, side effects, and typical use cases. The presence of an output schema doesn't compensate for missing behavioral and parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for the 'mode' parameter by listing valid values (VOXEL, QUAD), which the schema does not provide. However, 'voxel_size' is left entirely unexplained, and 'object' is self-evident. This partial compensation is insufficient for full parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Remesh an object.' It also lists the available modes, which adds specificity. While it doesn't explicitly distinguish from siblings like modifier-based remeshing, the primary purpose is 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/5Does 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, object types, or situations where other tools (e.g., add_modifier) might be more appropriate. The modes are listed, but without context for choosing between them beyond naming.
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 idempotentHint annotation indicates safe repeatability, and the description adds the 'default value' detail, distinguishing from a current value. However, it does not disclose any side effects, required context (e.g., existing node/modifier), or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for a simple operation, though it sacrifices explanatory detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five required parameters and no schema descriptions, the description is too sparse. It does not clarify the relationship between object/modifier/node/input, the return value, or how it differs from the plural set_geonodes_input tool, making 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/5Does 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 five parameters. While param names suggest roles, the 'input' can be string or integer, 'value' any type, and the description adds no meaning beyond the bare names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the target (a geometry node input's default value), with a specific resource. However, it does not differentiate from the similarly named sibling tool set_geonodes_input, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_geonodes_input or set_node_input. The description implies a singular input but does not explicitly state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only restates the basic action. It does not mention whether an existing vertex group is overwritten, whether the object must be in sculpt mode, or any side effects. The term 'sculpt mask' is assumed without clarification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and easy to read, though its brevity contributes to under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits critical context such as the need for an existing sculpt mask, the default vertex group name, and the overwrite behavior. Even with an output schema, the description does not sufficiently prepare the agent for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both parameters, yet the description provides no additional meaning for 'object' or 'vertex_group'. It fails to indicate that 'object' is the target mesh and 'vertex_group' is the name of the resulting group, leaving the user to guess from the default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Convert') and clearly states the resource ('sculpt mask') and the outcome ('to a vertex group'). This distinguishes it from sibling tools like create_vertex_group and assign_vertex_weights, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. There is no mention of prerequisites (e.g., needing an active sculpt mask) or exclusions, leaving the user to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It simply states removal without addressing what happens to connected nodes, whether the deletion is permanent/undoable, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise and front-loaded; it wastes no words. However, it is so brief that it sacrifices useful detail, which keeps it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, a short description is acceptable, but this one lacks essential context like what the parameter refers to and the operational consequences of deletion. The presence of an output schema does not compensate for the missing usage and parameter information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only says 'Remove a compositor node.' It does not explain what the 'node' parameter expects (e.g., name, ID, path), nor does it provide any additional semantic meaning beyond the bare schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a compositor node' uses a specific verb ('Remove') and clearly identifies the resource ('compositor node'), distinguishing it from sibling delete tools like delete_shader_node or delete_geonode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, context, or exclusions. The only implicit context is the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It simply says 'Remove a node' without mentioning side effects like breaking connections, irreversibility, or whether the node's subtree is also deleted. This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is efficient, though it could arguably include more detail while still remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 minimally adequate, but it lacks usage guidelines, parameter semantics, and behavioral details. No annotations are present, and the output schema (if any) is not shown, so the description should have provided more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 (node, object, modifier). The tool name and description imply what these might be, but the description adds no meaning beyond the parameter names, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a node from a geometry node tree' clearly states the action and the resource, distinguishing it from sibling tools like delete_shader_node or delete_object. It is a specific verb+resource combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 exclusions or prerequisites. The description only states what it does, not 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?
The readOnlyHint annotation already covers the safety profile. The description adds no additional behavioral context, such as error handling, return format, or side effects, so it goes beyond nothing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It conveys the essential purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, the description is too sparse for a tool with four required parameters and no parameter documentation. It does not explain how to identify the node or input, leaving the agent to guess at the argument values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate. It only hints that the tool involves a 'geometry node input' but gives no explanation for the four parameters (object, modifier, node, input). The parameter meanings remain largely unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Get' and resource 'geometry node input's current value' clearly indicate the tool's purpose. It is distinct from siblings like set_geonode_input and get_node_input, though it doesn't explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply states what it does, with no mention of 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?
The only annotation is idempotentHint, which is already structured. The description adds no behavioral context such as side effects, dependencies (e.g., compositor must be enabled), or error conditions. It fails to go 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. However, its brevity borders on under-specification, which limits its utility despite being well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameter descriptions, no output schema insight, and a simple setter that operates on a specific node tree, the description is incomplete. It lacks context about how the node tree is accessed or how inputs are referenced, making the tool risky to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain how to specify 'node', 'input', or 'value'—no node naming convention, input index vs. name, value types, or units. The agent is left without essential parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('compositor node input'), clearly distinguishing it from shader or geometry node setters. It unambiguously states 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/5Does 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 set_node_input or set_geonode_input. It simply states what it does without mentioning prerequisites, contexts, 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?
There are no annotations, so the description carries the full burden. It states the action ('Insert') and explains index usage, but does not disclose side effects (e.g., overwriting existing keyframes), prerequisites (e.g., object existence), or error behavior. This is a significant gap for a write 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and contains no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 annotations, no output description), the description is too minimal. It lacks return value/response information, error handling, and any relationship to sibling animation tools, making it incomplete for an AI agent deciding whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description must compensate. It explains the 'index' parameter meaningfully (0=X, 1=Y, 2=Z, -1=all), but does not clarify 'data_path', 'value', or 'frame' semantics beyond their names. This is insufficient for 5 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Insert a keyframe on an object property at a specific frame.' This is specific with a verb and resource. However, it does not distinguish itself from the sibling 'set_keyframes' tool, so it lacks 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/5Does 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 'set_keyframes', 'delete_keyframe', or 'get_keyframes'. It only explains index channel semantics, not context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description essentially restates the tool name, adding no behavioral context beyond the annotation (idempotentHint) already provides. It does not contradict annotations, but also does not disclose any additional traits such as side effects 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core action and resource. It is appropriately brief for the simplicity of the operation, though it could contain slightly more useful detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter, the description conveys the essential purpose. However, it lacks usage differentiation from similar tools and parameter explanations, making it less complete than ideal. The presence of an output schema and annotation mitigates some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no explanation of what 'start' and 'end' mean. While the parameter names are intuitive, the description does not 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a preview/playback range with the verb 'set' and a specific resource. However, it does not distinguish from the sibling tool 'set_frame_range', which could be considered similar in 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/5Does 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_frame_range or playback_control. The description gives no context about the intended use case 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 only include idempotentHint: true, which the description does not contradict. However, the description does not disclose any additional behavioral traits such as whether the brush change affects all objects or only the active one, or whether radius/strength values persist. The list of brushes is helpful but not behaviorally 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and efficiently enumerates brush options without wasted words. However, it could be slightly expanded to cover parameter meanings without becoming verbose, so it does not earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, 0% schema coverage), the description is incomplete. It omits prerequisites (e.g., being in sculpt mode), optionality of parameters, and any behavioral nuances. It relies on an output schema that is not shown, but that does not excuse the missing contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 brush values but fails to explain the meaning, units, or effects of 'radius' and 'strength' parameters. It only says 'settings' generically, leaving the agent without critical parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set the active sculpt brush and settings' with a specific verb and resource. It also enumerates all available brush types (DRAW, CLAY, etc.), which distinguishes it from any sibling tools that affect sculpt mode (e.g., enter_sculpt_mode).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives. It does not mention that the user must be in sculpt mode first, or whether this tool is appropriate only after entering sculpt mode. No exclusions or alternative tool references are provided.
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?
No annotations are provided, so the description must fully disclose behavior. It only says 'set up' without detailing side effects, whether existing particle systems are replaced, what 'children' means, or how physics is configured.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, though the 'Template:' prefix adds little value. It is concise but extremely thin.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no annotations, the description is severely under-specified. It does not mention return values or behavior on existing hair systems, and only output schema may partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 'count', 'length', or 'object' parameters. While the parameter names are somewhat self-evident, the description adds no semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: setting up hair particles with children and physics. It distinguishes from sibling tools like 'add_particle_system' by specifying a complete setup rather than just adding a system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'add_particle_system' or 'set_particle_property'. It does not state 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?
With no annotations, the description carries full behavioral burden, but it only restates the action and lists types. It does not disclose that the action mutates the object, whether existing physics is replaced, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a list. It is front-loaded with the action verb and contains no fluff, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with no annotations and sparse parameter descriptions, it should explain what happens when physics is added, how 'object' is referenced, and how this relates to the setup_* siblings. The output schema exists but does not cover usage semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds enum-like values for 'type' (RIGID_BODY, CLOTH, FLUID, SOFT_BODY, COLLISION), which is helpful given the bare string schema. However, it provides no semantics for 'object' (e.g., name vs. path), and with 0% schema coverage, it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a physics simulation' with a specific verb and resource, and lists the supported types. However, it does not explicitly differentiate from sibling setup tools like setup_rigid_body_world or setup_cloth_sim, 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/5Does 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 the setup_* siblings or set_physics_property. No prerequisites, such as whether the object must exist or be selected, 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 include readOnlyHint: true, and the description aligns with that. It adds minimal context beyond the annotation—just the nuance of 'default' value—but there is no mention of error behavior, return format, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a clear verb-first structure and no redundancy. However, it is arguably too short to cover necessary parameter semantics, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three required parameters, no schema descriptions, and an output schema present but not shown, the description is insufficient. It doesn't explain how to identify a node or input, nor does it describe what the returned default value looks like. The description is too terse for a tool with this parameter count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for its three parameters. The description only implies what 'input' means (the node input whose default value is returned) but leaves 'material' and 'node' undefined, forcing the user to infer their meanings from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a node input's current default value, using a specific verb and resource. However, it doesn't explicitly distinguish this from get_geonode_input or get_comp_node_input, relying on the material parameter to imply it's for material nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or which alternatives exist. Given many sibling tools like set_node_input and get_geonode_input, the description would benefit from noting it's for material/shader node trees, but it doesn't.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does explain the two mode behaviors (auto weights vs. no weights), but it does not disclose side effects such as whether existing vertex weights are overwritten, whether the previous parent is replaced, or any prerequisites. This is minimal behavioral context for a potentially destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two short sentences that front-load the core purpose and then detail the mode options. Every word earns its place, with no redundant or tangential content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a rigging operation with no annotations and no parameter descriptions in the schema, the description is too thin to be complete. It omits prerequisites (e.g., armature must have a pose, mesh must be selected), what happens to existing parenting or weight groups, and possible error conditions. The mode information is helpful but does not compensate for these significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for the 'mode' parameter, explaining what AUTOMATIC and EMPTY do. However, with 0% schema description coverage, mesh and armature parameters are left entirely undocumented, although their purposes are mostly inferable from their names. The mode explanation provides some value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Parent' and the resources 'mesh' and 'armature', and it provides distinct mode options ('AUTOMATIC' vs 'EMPTY') that differentiate it from the generic sibling tool 'set_parent'. However, it does not explicitly contrast itself with other parenting tools, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'set_parent' or clear_parent. The mention of modes implies a rigging/skinning context, but there is no stated exclusion or recommendation about which tool fits which scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 only behavioral annotation is idempotentHint=true. The description adds no additional behavioral context such as side effects, error conditions, or requirements (e.g., constraint must already exist). Listing common properties is more about parameter semantics 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two short phrases with no filler. It front-loads the main action and then provides examples. However, it may be too sparse for the tool's complexity, but that's a completeness issue rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, 0% schema description coverage, and an output schema that doesn't need explanation, the description is insufficient. It doesn't clarify how to reference the constraint (by name?), the role of the optional bone parameter, or what typical valid values look like. The provided examples are a start but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for parameter meaning. It provides common values for 'property', which is helpful, but gives no guidance for 'object', 'constraint', 'bone', or 'value', leaving most parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set a constraint property') with a specific resource, and provides common property examples (target, subtarget, influence, axis). While it doesn't explicitly mention overlapping sibling tools like set_constraint_influence, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples of common properties imply when the tool should be used, but there is no explicit guidance on when to prefer this over alternatives such as set_constraint_influence, nor any exclusions or prerequisites. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The idempotentHint annotation already indicates repeated calls are safe, and the description adds no additional behavioral context such as side effects on viewport or timeline. It doesn't contradict annotations, but it provides no extra value 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but it's under-specified. While it has no fluff, it lacks important details that could be included without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool being simple, the description fails to explain the semantics of the frame parameter or the effect of setting it. The output schema exists, so return values are covered, but the missing parameter details make it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only specifies 'frame' as an integer with no description, and the description does not explain what frame means (e.g., 0-indexed vs 1-indexed, whether it's frame number or time). With 0% schema description coverage, more compensation was needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the current frame with a verb+resource structure. However, it doesn't differentiate from sibling tools like set_frame_range, and 'frame' could be interpreted as frame number or object frame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use set_frame versus set_frame_range, playback_control, or frame_selected, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only an idempotentHint annotation, the description carries the burden of explaining behavior. It states that start and/or end frames can be set, but does not clarify the effect of null values (e.g., whether null means the existing value is kept). This is a key behavioral aspect that is left to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loading the verb and purpose. Every word contributes to understanding the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 mostly sufficient. However, it leaves out null-value behavior and does not differentiate from sibling set_playback_range, which is a completeness gap. The phrase 'scene frame range' provides some context but not enough to fully disambiguate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), so the description must compensate. It mentions that start and/or end frames can be set, which aligns with the schema, but it does not explain the semantics of null values or any constraints like end > start. The parameter meaning is mostly derived from the names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sets the scene frame range, specifying both start and end frames. It uses a specific verb ('set') and resource ('scene frame range'), making the purpose clear. However, it does not distinguish from sibling set_playback_range, which may be used for similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives like set_playback_range or set_frame, nor does it exclude any cases. Without this, an agent may select the wrong 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?
Annotations only provide idempotentHint. The description does not disclose side effects (e.g., whether it resets other settings), what happens with invalid values, or that it modifies the current scene. It adds no behavioral context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, just two lines, with the main action front-loaded. The lists compactly provide useful parameter values without unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and 0% schema coverage, the description is too sparse. It only covers three parameters and provides no context on when to use the tool or what the tool actually does beyond 'configure'. The presence of an output schema doesn't compensate for missing parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description's enumeration of valid values for engine, file_format, and color_mode is helpful for those three parameters. However, it does not cover the other six parameters (samples, resolution, filepath, film_transparent, resolution_percentage), leaving them undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description has a clear verb+resource ('Configure render settings') and lists some allowed values, which helps distinguish it from get_render_settings (get vs set) and render_image (rendering vs configuring). However, it could be more specific about which render settings are covered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like render_image or get_render_settings. No mention of prerequisites, ordering, or typical workflows.
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 added range (0.0 to 1.0) gives behavioral context beyond the idempotentHint annotation, but it does not disclose clamping behavior, whether the constraint must exist, or any other side effects. The annotation covers idempotency, so the description's minimal input is acceptable 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that gets directly to the point with no filler. The front-loaded structure and efficient phrasing are exemplary for a simple setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity and the presence of an output schema, the description fails to explain required parameters or usage context. An agent would struggle to know what 'object' and 'constraint' refer to, and there is no guidance on when to use this specialized setter versus the generic set_constraint_property.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It only explains the 'influence' parameter's range, leaving 'object', 'constraint', and optional 'bone' unexplained. Parameter names offer some clues, but the description adds value for only one of four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('constraint influence') with a numeric range, making the action clear. It does not explicitly distinguish itself from the sibling tool set_constraint_property, but naming the influence property provides enough specificity for basic selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 set_constraint_property, nor any prerequisites such as the constraint already existing. The description implies its use only from the name, offering no explicit 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?
The idempotentHint annotation already covers idempotency, and the description adds that the tool sets a default value rather than a current value, plus the allowed value types. However, it does not disclose potential side effects like whether setting a default value affects existing connections or whether it is limited to unconnected inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It front-loads the verb and object, making the intent immediately clear despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a 4-parameter tool in a large family of node-related tools. It does not specify which node tree type (shader, geo, compositor) it applies to, nor how to reference nodes and inputs. The idempotent annotation and presence of an output schema are helpful, but the missing operational context is significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only hints at the `value` parameter by naming supported types. It does not explain `material`, `node`, or `input` (including whether `input` is a socket name or index), leaving most parameter semantics underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('node input's default value'), and it lists supported value types (color, float, vector), making the core purpose unambiguous. It distinguishes from sibling tools like get_node_input or set_node_position, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 set_geonode_input, set_comp_node_input, or connect_shader_nodes. The description does not mention prerequisites or the node tree context it applies to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the nodes to be created. It does not mention side effects like clearing existing node trees, whether it overwrites current compositing setups, or any dependencies (e.g., render layer existence). This lack of detail makes potential impacts unpredictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, terse line that is front-loaded and free of filler. It conveys the core idea efficiently, but it is slightly under-specified, lacking behavioral context. This brevity is acceptable for a template description, though it sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role in compositing setup and the extensive list of sibling tools, the description is incomplete. It does not provide enough context about the resulting node tree, potential side effects, or any setup steps needed before invocation. The presence of an output schema is not disclosed, so the agent cannot infer return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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. The description does not need to explain parameter behavior since there are none. Baseline for zero parameters is 4, and the description neither adds nor detracts from this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool creates a composite setup with render layers, a composite node, and a viewer node. While it is phrased as a template rather than a full sentence, it effectively conveys the specific resource and action. It does not explicitly differentiate from sibling compositing tools, but the focus on a basic setup is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternative compositing tools or manual setup. It does not mention prerequisites, such as whether the compositor must be enabled, nor does it indicate when this template is preferred over creating nodes individually.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral details. It lists the modifier types but does not mention required parameters, potential side effects on the object, or what the tool returns. The description lacks transparency about the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: a one-sentence action statement followed by a list of supported types. It is front-loaded and contains no unnecessary words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool, the description is insufficient given the 0% schema coverage and the presence of sibling tools like add_modifier. It does not explain the object parameter, the optional name, or when to choose this over generic alternatives, leaving the description incomplete for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should explain parameter meanings. It adds the allowed values for 'type', which is helpful, but it does not clarify the roles of 'object' and 'name' parameters, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Add a GP modifier' and lists the specific modifier types. It distinguishes itself from the generic add_modifier sibling by focusing on GP (Grease Pencil) modifiers, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other GP-specific tools. The description only states what it does, without any when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the creation of an armature with a bone but omits critical behavior like whether null location uses origin or 3D cursor, whether the new armature becomes the active object, or any scene context requirements. This is insufficient for a creation tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. 'Create an armature' is concise, and 'with an initial bone' adds necessary qualifier. This is appropriately compact for such a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity and presence of an output schema, the description omits essential context for correct invocation, particularly the interpretation of location (null vs. array) and the behavior of the initial bone. The lack of annotations and parameter descriptions makes this description incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 'name' or 'location' parameters at all. It provides no semantic meaning for location (e.g., world coordinates) or the effect of a null default. The description completely fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'armature', with the qualifier 'with an initial bone' distinguishing it from generic object creation tools like create_object and bone-manipulation tools like add_bone. This unambiguously conveys the tool's specific function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an armature is needed but provides no explicit guidance on when to use this tool versus alternatives (e.g., creating an empty object then adding bones). No exclusions or alternative tools are mentioned, so it relies on implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavior such as failure cases (e.g., duplicate name or invalid parent) or return values. This is a mutation tool, so the lack of safety or side-effect information is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that communicates the core purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a trivial create operation, but given no annotations and no parameter details, it leaves important edge cases unaddressed. For a mutation tool, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds minimal meaning beyond the schema. It clarifies that parent is optional, but does not explain the expected format or constraints for name or parent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (collection), and notes the optional parent parameter, distinguishing it from sibling collection tools like delete_collection and move_to_collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 move_to_collection or list_collections. The parent option suggests hierarchy, but prerequisites or exclusions 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic function and gives type examples. It does not mention prerequisites (e.g., compositor enabled), side effects, return values, or what happens on invalid input. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action. The list of common types is informative and earns its place, adding practical value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with an output schema, the description is minimally adequate. The output schema likely covers return values, and the parameter schema covers types. However, missing behavioral context (e.g., does it need compositing enabled? does it auto-connect?) leaves the description incomplete for an agent deciding when and how to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides useful example values for the 'type' parameter, adding meaning beyond the bare string type. However, 'name' and 'location' are not described at all, leaving them under-specified. Partial compensation for the required parameter only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a compositor node') and the resource type. While it lists common compositor node types, it does not explicitly differentiate from similar create tools like create_shader_node or create_geonode, though the 'compositor' qualifier provides some 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/5Does 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. Sibling tools like create_shader_node or create_geonode exist, but no exclusions or contextual usage hints are given. The list of common types implies some usage scenarios but does not state when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. "Create" implies a write operation, but it doesn't disclose side effects, whether an object is added to the scene, what happens if the name already exists, or how the light is inserted into collections. It lists types but doesn't explain behavioral differences or defaults like type=POINT.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loaded with the action. The type list is efficient. However, it's under-specified, which slightly reduces the score for structure, but it earns points for not wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters with 0% schema coverage, no annotations, and only a trivial type list in the description, the context is incomplete. An output schema exists but the description doesn't explain what is returned (e.g., created light name/ID). For a creation tool with no annotation safety hints, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The description only mentions types, which correlates with the 'type' parameter, but provides no semantics for name, color, energy, or location. The type list adds some value, but it's minimal; no guidance on coordinate spaces, units, or energy scale is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description "Create a light. Types: POINT, SUN, SPOT, AREA." clearly states the tool's action (creating a light) and resource (light), distinguishing it from siblings like list_lights, create_light_rig, and set_light_property. It doesn't fully differentiate edge cases from create_light_rig, but 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it—when creating a light—but provides no explicit exclusions or alternatives. It doesn't mention that set_light_property is for modifying existing lights, or that create_light_rig is for rigs. The context is understandable but not explicit about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the core action ('Disconnect an input') but does not mention side effects, such as what happens if the input is already disconnected, whether all connections are removed, or any required state. This is minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant phrases. It is front-loaded with the action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4-parameter schema and absence of annotations, this description is underspecified. It does not provide enough context about required parameters, prerequisites, or expected behavior, even though an output schema exists. The tool is a specialized geometry node operation, and the description leaves out critical context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage, so the description must compensate. It only says 'an input on a geometry node,' which clarifies that 'input' refers to a node input, but it does not explain the roles of 'object,' 'modifier,' or 'node,' nor the expected format of 'input' (string name vs integer index). The description adds little meaning beyond the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Disconnect' and identifies the resource as 'an input on a geometry node.' This clearly distinguishes it from sibling tools like 'connect_geonodes' (which connects) and 'delete_geonode' (which deletes). It directly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or what prerequisites must be met. It does not mention exclusions or specific 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?
With no annotations, the description carries the burden of behavioral disclosure. It does mention the key linked=True behavior of sharing mesh data, which is useful. But it does not disclose other side effects like whether materials, children, or transforms are copied, nor the effect of new_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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences, and every word adds value. However, it might be too sparse given the parameter complexity, so it loses a point for lack of necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a duplication tool with no annotations and minimal parameter explanations, the description is incomplete. It lacks details about name/new_name semantics, and what exactly gets duplicated (materials, children, etc.). Output schema exists, so return values are covered, but the operational context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 linked=True's effect, but does not explain what 'name' refers to (the object to duplicate) or 'new_name' (the output name). Only one of three parameters is clarified, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Duplicate an object' which is a specific verb and resource, and the linked parameter adds scope. However, it does not explicitly differentiate from sibling tools like create_object or copy_modifiers, so it doesn't fully earn 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: duplicate an existing object when you want a copy. However, there is no explicit guidance on when to use this vs. other approaches (e.g., creating a new object and copying data), and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does not mention side effects like file overwriting, allowed formats, error behavior, or whether the entire scene or only selected objects are exported. The auto-detection note is the only behavioral trait 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and immediately followed by a useful parameter detail. 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 parameters, no enums, output schema exists), and the description covers the essential purpose and the main parameter nuance. However, it leaves gaps such as scope of export, overwrite behavior, and relation to sibling tools, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'format' parameter (auto-detected from extension if null), which adds meaning beyond the schema's default. However, 'filepath' is left to its name, with no additional context about path handling or accepted formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Export the scene to a file'), clearly indicating the tool's function. However, it does not distinguish from sibling tools like export_selection or save_file, as it doesn't clarify scope (whole scene vs selection) or differences from similar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 export_selection or save_file. The only usage hint is 'Format is auto-detected from extension if not specified,' which is a parameter behavior, not a tool-selection guideline.
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 'Irreversible,' which aligns with and slightly extends the destructiveHint annotation by emphasizing permanence. However, it does not disclose scope (e.g., whether it affects the whole object or just baked data) or any other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and a critical warning. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the description lacks essential context: what the optional 'object' parameter does, prerequisites (e.g., existing baked data), and expected results. The output schema exists but does not compensate for missing parameter and usage details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'object' with no description and zero schema coverage. The description does not mention the parameter at all, leaving its purpose and behavior completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Free') and resource ('baked physics simulation data'), which clearly distinguishes it from sibling tools like bake_physics. The verb 'free' unambiguously indicates releasing/clearing data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 bake_physics or remove_physics. The only hint is 'Irreversible,' which implies caution but does not specify conditions 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 indicates a safe read operation, and the description aligns with that. It adds the clarifying context that the operation targets mesh objects, but it does not disclose further behavioral details like error handling or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one parameter, readOnlyHint, and output schema, the description is minimally adequate. However, it lacks any usage context or note about what constitutes a valid UV map, making it only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'object' with no description and 0% schema coverage. The description compensates partially by specifying that the object must be a mesh, but it does not clarify whether the parameter expects a name, ID, or path, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets UV maps from a mesh object, using a specific verb and resource. It distinguishes itself from related tools like create_uv_map and smart_uv_project, though it does not specify whether it returns names or coordinate data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_mesh_info or get_vertices. The description simply states what it does without providing context for selection 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 conveys the non-mutating nature, so the description does not need to repeat that. It adds minor scope clarification (object vs pose bone) but does not disclose any further behavioral details, such as whether an empty list is returned for unconstrained objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. Every word contributes to the core meaning, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and there is an output schema (not shown), so the description need not detail return values. However, the ambiguity around parameter usage and the lack of differentiation from sibling tools leave the description slightly incomplete for an agent to use it correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description is the only source for parameter meaning. It identifies 'bone' as a pose bone but fails to explain the relationship between the 'object' and 'bone' parameters, such as whether providing a bone overrides the object or filters constraints on that specific bone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing constraints on an object or pose bone, with a specific verb ('List') and resource. However, it does not differentiate itself from the sibling tool 'list_bone_constraints', which may cover a subset of the same scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'list_bone_constraints' or 'get_bone_info'. The presence of a highly similar sibling makes the lack of usage direction a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only restates the purpose and fails to disclose behavioral traits such as how name conflicts are handled, whether the image references the file or is packed, or what happens when the filepath is invalid. This is a significant gap for a tool that mutates the blend file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of eight words, front-loaded with the verb and object. No redundancy, no wasted words. Perfectly sized for a tool with minimal parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters, no annotations, and 0% schema coverage, a one-sentence description is insufficient. The ambiguous 'name' parameter and lack of duplicate/error behavior leave an agent without enough information for correct invocation. The presence of an output schema partly mitigates return-value uncertainty, but input behavior remains underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter semantics. The 'name' parameter's behavior (e.g., data-block name, derived from filename when null) is undocumented in both schema and description. Only 'filepath' is self-evident from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('load') with a clear resource ('image from file') and destination ('into the blend file'). It distinguishes itself from siblings like load_file (loading a whole blend file) and import_file (external format import) by specifying it loads an image asset into the current Blender file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 import_file, load_file, or list_images. No exclusions, prerequisites, or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the action. It does not explain behavior at stack boundaries (e.g., moving an already-top modifier), whether the operation is reversible, or any side effects. It also fails to define valid values for 'direction' besides the hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the core action and the key direction parameter immediately conveyed. No unnecessary words or repetition, and the 'Direction: UP or DOWN' is a clear, structured hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and a 0% schema description coverage, so the description must carry the full context. While the action is clear, missing parameter details, usage context, and boundary behavior make it incomplete for a likely mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must clarify parameters. It only adds meaning for 'direction' ('UP or DOWN'), leaving 'object' and 'modifier' ambiguous. No hints about identifiers or accepted formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') and resource ('modifier') with clear scope ('up or down in the stack'), which unambiguously distinguishes it from related modifier tools like set_modifier_property or apply_modifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that it reorders modifiers, nor does it explain how it differs from set_modifier_property or reorder_constraint, 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?
With no annotations, the description carries full responsibility for disclosing behavior. It does not mention that the operation is destructive or irreversible, nor does it describe error handling if the constraint does not exist. The 'by name' detail is a minor behavioral hint but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no unnecessary words. It efficiently conveys the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks context about the object parameter, optional bone parameter, and any preconditions or return behavior. While an output schema is present, the description does not cover crucial contextual aspects for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only clarifies that the constraint is identified by name. It does not explain the 'object' or 'bone' parameters, leaving ambiguity about the optional bone context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove), the resource (a constraint), and the identification method (by name). This distinguishes it from sibling tools like add_constraint and list_constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or alternatives. The description simply states the operation without contextual 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?
No annotations are provided, so the description must carry the transparency burden. It merely states the action and target file, but does not disclose whether existing files are overwritten, whether current viewport settings are used, what happens if filepath is null, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that competes with several viewport/render siblings, the description is too sparse. It lacks alternative guidance, behavioral details, and parameter nuances. The output schema exists but the description does not clarify what result can be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'filepath' with no description. The description says 'to a file' but adds no detail about path format, null behavior, supported file types, or defaults. The parameter name is self-explanatory but the description contributes minimal additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it renders the viewport to a file and specifies 'OpenGL render', which differentiates it from full render operations like render_image or simple capture operations like capture_viewport. The verb 'Render' and resource 'viewport' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 capture_viewport or render_image. It does not mention that this is for quick previews or what scenarios are not 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?
With no annotations, the description carries the burden of explaining side effects, but it only provides a high-level purpose. It does not disclose how focus mode is selected, what happens if both focus_object and focus_distance are provided, or any required enabling steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the main purpose and add the key focus modes. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are 4 parameters, no annotations, and no parameter descriptions, the description is too sparse. It lacks critical details about parameter interactions, default behaviors, and output expectations, making it incomplete for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 implicitly maps 'Focus on an object' to focus_object and 'at a specific distance' to focus_distance, but it does not explain the camera or fstop parameters, their units, defaults, or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Configure depth of field') on a specific resource ('camera') and clarifies two focus modes ('Focus on an object or at a specific distance'). This clearly distinguishes it from broader camera tools like set_camera_property by focusing on DOF.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 set_camera_property or camera_look_at. It does not mention exclusions or prerequisites, leaving the agent to infer applicability from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but discloses little beyond the basic action. It does not mention side effects, prerequisites, whether existing physics are overwritten, or whether the target object must be a mesh. Only the pinning vertex group is noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the primary purpose and a key parameter in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a physics setup tool with no annotations, the description is under-specified. It does not explain when to use it, what happens to existing physics, or prerequisites. The output schema may cover return values, but behavioral and contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 clarifies the pin_group parameter as 'optional pinning vertex group' but leaves the required 'object' parameter unexplained, making its role ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'set up cloth simulation' and distinguishes it from sibling physics setup tools like setup_softbody and setup_rigid_body_world. The mention of an optional pinning vertex group adds specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use cloth simulation versus alternatives such as soft body or rigid body. There are no exclusions, prerequisites, or alternative tool references, leaving usage context solely implied by the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Add a particle system', which indicates a mutation, but does not state prerequisites (e.g., the object must be a mesh), effects on existing systems, or any side effects. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence plus a short type list. Every word contributes relevant information, and the key action is front-loaded. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that adds a particle system, the description fails to mention important context such as whether the target object must already exist, whether multiple systems are allowed, or how this relates to sibling tools like setup_hair. Although an output schema exists, the description itself is too thin to guide correct usage in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds valuable meaning to the 'type' parameter by listing EMITTER and HAIR as allowed values, which the schema does not constrain. However, it provides no explanation for 'name' or 'object', leaving those parameters semantically under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('a particle system'), and specifies allowed types (EMITTER, HAIR). This distinguishes it from sibling tools like remove_particle_system, set_particle_property, and setup_hair, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. For example, it does not mention when to choose this over setup_hair or how it relates to existing particle systems on an object. The description lacks any contextual or exclusionary hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only discloses that sockets can be specified by name or index, but fails to mention side effects such as replacing an existing input connection, type compatibility validation, or error behavior when nodes/sockets are invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary purpose and no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a graph-mutation tool with no annotations, this description is minimal. It omits critical operational details like connection replacement semantics, compatibility requirements, and potential failure modes. The output schema exists but does not compensate for the lack of behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds value by clarifying the anyOf types for from_output and to_input ('Sockets can be specified by name or index'). It also maps output/input to the parameter roles, though the remaining parameters are only clear by their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Connect an output socket to an input socket,' specifying the precise action and resource. The tool name 'connect_shader_nodes' distinguishes it from sibling tools like 'connect_geonodes' and 'connect_comp_nodes', and the note about name/index adds useful specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., connect_geonodes). It does not mention prerequisites like material/node existence, nor does it explain whether connecting replaces existing connections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explain whether existing modifiers on the target are preserved or overwritten, whether the source object's modifiers are removed (copy vs. move semantics), or what happens if source and target are the same. This lack of side-effect information is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. Every word earns its place, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and no output schema details, the description is incomplete. It does not mention return values, error conditions, or crucial side effects like how existing target modifiers are handled. This makes it insufficient for safe, confident use in a mutation tool, despite the tool's apparent simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only parameter names ('source', 'target') as strings with no descriptions. The description adds the meaning that these refer to objects, which is helpful, but it does not specify the expected identifier format (e.g., name, path, UUID) or any constraints. Since schema coverage is 0%, the description partially compensates but remains underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Copy all modifiers') and the resource ('from source object to target object'), with a specific verb and object scope. This distinguishes it from siblings like move_modifier, which implies relocation rather than duplication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 move_modifier or add_modifier. The description only states what it does, leaving the agent to infer usage context without any explicit conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the basic creation action and focal length, but does not mention whether the camera is created with defaults, what happens if a name already exists, or whether the operation has side effects. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the core action and key parameter. It is front-loaded and contains no superfluous words, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple creation tool with an output schema, so return values need not be specified. However, the description omits guidance on optional parameters and default behaviors. Given the simplicity, it is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It only mentions focal_length, ignoring name and location. The description adds no meaning for name/location beyond the schema's type/default, leaving significant ambiguity for those parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a camera'), and also specifies the key attribute ('focal length'). It distinguishes from sibling tools like list_cameras and set_camera_property by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 create_light. There is no mention of prerequisites, context, or exclusions, so the agent is left without directional 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?
With no annotations, the description must disclose behavioral traits, but it does not address side effects, error conditions, coordinate space, or how the tool interacts with existing strokes/layers. It only defines the input format, leaving the agent without information about what happens when the stroke is created.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and includes a compact data format example. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters (3 required), a minimal schema, and no annotations, the description is insufficiently complete. It does not explain how object/layer are used, the meaning of frame, return values, or failure modes, making it hard for an agent to safely predict the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does explain the 'points' parameter structure ({co, pressure, strength}), which is valuable, but it leaves 'object', 'layer', and 'frame' entirely undocumented. The partial compensation is useful but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Create a stroke') and specific input ('from point list'), distinguishing it from sibling GP tools like add_gp_layer or create_grease_pencil. It also provides a concise data format for the points, 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 Guidelines2/5Does 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, nor are prerequisites mentioned (e.g., needing an existing GP object/layer). The description only states what the tool does, not the context in which it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it creates lights and may aim at a target, but does not explain whether it replaces existing lights, requires a selected object, or has other side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, using two sentences to state the core purpose. However, the brevity may be the cause of missing critical information, but as a standalone structure, it is efficient and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, 0% parameter coverage, and 4 unrequired parameters, the description is insufficient. It provides a high-level overview but omits essential details about parameter semantics and behavioral consequences, leaving 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.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain any of the parameters (key_energy, fill_energy, rim_energy, target). While the phrase 'key, fill, rim' hints at the light types, the description fails to clarify that energy parameters control intensity or how the target parameter behaves. There is no added semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 three-point lighting setup with key, fill, and rim lights. It uses a specific verb and resource, distinguishing it from sibling tools like create_light or set_light_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear use case: setting up a standard three-point lighting rig, with an optional target. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to recognize when this tool is intended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It only states the action without disclosing side effects, reversibility, requirements (like mesh type), or potential errors. For a mode-switching operation, this lacks 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that gets straight to the point with no filler or redundant content. 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.
Completeness3/5Given 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 an output schema, and the description covers the core action. However, it lacks caveats, prerequisites, or failure conditions, and no annotations compensate, so completeness is only average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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' parameter beyond calling it the target. It does not explain what format the object identifier should take (name, path, etc.) or any constraints, leaving the agent under-informed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Switch an object to sculpt mode' uses a specific verb ('switch') and clearly identifies the resource (object) and target state (sculpt mode). It distinguishes from siblings like set_transform or apply_modifier by naming a unique mode transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. It does not state when to use this tool versus any alternative, nor does it mention prerequisites (e.g., object must be a mesh) or when not to use it. The intended usage is only implied by the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only idempotentHint: true in annotations, the description is the primary source for behavioral context, but it only lists parameter names and does not disclose effects like units, valid ranges, side effects, error conditions, or any dependency between properties. The idempotent annotation is not contradicted, but the description adds little beyond what is already known.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no wasted words. It front-loads the action and lists the settable properties clearly, 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 0% schema coverage and lack of annotations beyond idempotency, the description does not provide enough context for an agent to correctly set values. Missing units, ranges, and value-type associations make it insufficient for confident invocation, despite the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage for parameter descriptions, so the description must compensate. It does enumerate valid values for the 'property' parameter, which is valuable, but it does not explain value types per property (e.g., which properties expect numbers vs booleans) nor the meaning of the 'name' parameter. This partial compensation justifies a middle score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Set camera property') and enumerates the specific properties that can be set (focal_length, sensor_width, etc.), distinguishing it from other property-setting tools like set_material_property and set_light_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 setup_camera_dof or set_active_camera. It does not mention exclusions, prerequisites, or preferability, leaving the agent to infer usage from the generic 'Set camera property' phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It does not mention side effects such as whether geometry vertices are moved relative to the new origin, whether transformations are affected, or any other implications. The type list is present but lacks contextual details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single a sentence followed by a list of types. No filler or redundant content. It is appropriately short and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and low schema coverage, the description is incomplete. It lacks usage context, behavioral side effects, and parameter explanations. The presence of an output schema is not enough to compensate for these missing elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists valid values for the 'type' parameter (ORIGIN_GEOMETRY, etc.) but does not explain what these types mean or how they affect the operation. The 'name' parameter is only implied as an object reference, with no additional semantics provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set an object's origin point') and the resource (object). It distinguishes from sibling tools like set_transform by focusing specifically on origin manipulation rather than general transforms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 set_transform or apply_transform. The list of types implies some options but does not explain when each is appropriate or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the operation and clarifies head/tail positions, but does not disclose side effects, requirements (e.g., object must be an armature), or what happens upon failure. This is minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two short sentences with no fluff. It front-loads the core purpose and is easy to parse. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks crucial context such as that the tool operates on an existing armature, what coordinate system is used, or what the 'object' parameter refers to. While an output schema exists, the description does not clarify success conditions or return values, leaving the agent under-informed for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 clarifies head and tail as 3D positions, leaving object, name, and parent unexplained. The agent can guess that 'object' is the armature name, but the description does not confirm this, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a bone to an armature,' identifying the specific verb and resource. It distinguishes from sibling tools such as set_bone_property or get_bone_info by focusing on the act of adding a new bone. The mention of head and tail as 3D positions reinforces the specific operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to add a bone) but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. Sibling tools like create_armature or set_bone_property are not referenced, so the agent must infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action 'point a camera' without explaining side effects such as whether the camera orientation is permanently changed, whether animation keyframes are created, or whether it affects the active camera. No permissions or reversibility info is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly conveys the core purpose without unnecessary filler. It earns every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no annotations, the description is too sparse to be complete. It does not explain how to specify a target vs location, whether both can be omitted, or what happens if both are provided. The presence of an output schema helps but does not compensate for the missing behavioral and parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions). The description mentions 'target object or world location' which hints at the 'target' and 'location' parameters, but it does not explain their format (e.g., target is a string object name, location is an array of numbers) nor does it explain the 'camera' parameter. The description adds minimal interpretive value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'point' with a clear resource 'camera' and indicates two target modes: object or world location. This clearly distinguishes it from sibling tools like set_viewport_camera (which sets active camera) and setup_camera_dof (depth of field).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for aiming a camera at a target, but it gives no explicit guidance on when to use this vs alternatives, nor does it mention exclusions or prerequisites. It is clear enough for basic use but lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It merely says 'Add a node' without disclosing side effects, whether a tree must already exist, whether the node is automatically connected, or what is returned (e.g., node ID). It lacks any behavioral context beyond the basic mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary purpose. It includes a helpful list of examples without unnecessary fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a mutation tool with 5 parameters and no annotations, the description omits critical context: what 'object' and 'modifier' refer to, whether a node tree must already exist, and what the tool returns. The list of types is helpful but does not compensate for the missing operational prerequisites or parameter clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists common values for the 'type' parameter, which adds some meaning, but fails to explain 'object', 'modifier', 'location', or 'name'. The parameter semantics are largely left to the user's inference from schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a node') and the specific resource ('geometry node tree'). It lists common node types, which helps distinguish this from related tools like create_shader_node or create_comp_node. The verb and resource are specific and non-tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when adding nodes to a geometry node tree, but provides no explicit when-to-use vs alternatives, prerequisites (e.g., existing geonodes modifier), or exclusions. It gives common types but no guidance on when to choose this over create_geonodes_modifier or connect_geonodes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It states the action but does not mention side effects (e.g., whether the material is added to the scene, assigned to an object, or set as active), any prerequisites, or what the output schema contains. The base_color format is a parameter detail, not a behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the core purpose, and the base_color clarification earns its place by resolving a potential ambiguity in parameter format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool, the description is minimal but lacks essential context: it does not explain the meaning of metallic/roughness, how the material is integrated into the scene, or what to expect from the output. The presence of an output schema is acknowledged in context signals, but its contents are undisclosed, so the definition remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter descriptions, so the description must compensate. It adds base_color format ('[R, G, B, A] (0-1 range)') but leaves metallic and roughness unexplained, offering no ranges or standards beyond their default values. This incomplete compensation leaves half the parameters semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new Principled BSDF material' with a specific verb and resource, and the Principled BSDF qualifier clearly distinguishes it from generic shader node creation (create_shader_node) or other material operations (list_materials, set_material_property).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the name and description—this tool is for creating a material—but there is no explicit mention of when to prefer it over alternatives like create_shader_node or how it relates to material assignment. No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action but does not reveal side effects such as breaking connections, permanent deletion, or whether the node is simply removed from the tree or also deleted from the material system. A mutation tool like this should note irreversible 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/5Is 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 action verb and resource, making it immediately clear. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (so return values need not be explained), the description is too sparse for a destructive tool with no annotations. It lacks usage context, parameter identification details, and behavioral side effects. For a tool that removes a node, users need to know if connections are automatically handled or if other nodes are affected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two string parameters with no descriptions (coverage 0%), so the description must compensate. The sentence uses 'material' and 'node' in context, implying the parameter roles, but it does not explain how to identify them (e.g., by name, path, index) or any constraints. This adds minimal semantic value beyond what the parameter names suggest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove a node from a material's node tree.' The verb 'Remove' is specific, and the resource 'node from a material's node tree' distinguishes this tool from sibling delete tools like delete_material, delete_geonode, and delete_comp_node. It precisely describes what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context—removing a shader node from a material—but does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites (e.g., the material must exist, the node must be present). There is no exclusion or alternative guidance, so it relies on the tool name and obvious context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the selection scope and gives no insight into format behavior (e.g., default when format is null), file overwriting, or side effects. Very limited behavioral disclosure beyond what is obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, and every word earns its place. Extremely concise with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits important context: what happens when format is null, whether selected objects must exist, and whether the file is overwritten. For a 2-param tool with no annotations, this is too sparse to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain 'filepath' or 'format' semantics. It only implies 'file' as the target; no meaning is added for the nullable format or its default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Export' with resource 'selected objects' and target 'a file', distinguishing it from sibling export_file which likely exports the whole scene. The scope restriction is explicit, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for exporting only selected objects, distinguishing from full-scene export, but does not explicitly mention when not to use or alternative tools. Context is clear but without explicit 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 readOnlyHint annotation already conveys the safe read-only nature. The description adds a small amount of context by naming the returned components (nodes, links, inputs), but does not disclose modifier-related behavior, potential errors, or object requirements beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. Every word contributes to the core meaning, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and a readOnlyHint, the description is too thin for a tool with two parameters at 0% schema coverage. It does not explain the optional 'modifier' parameter, possible object states, or prerequisites, making 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/5Does 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 for the 'object' or 'modifier' parameters. It only mentions output components ('nodes, links, inputs'), leaving the meaning and expected format of the parameters entirely to the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and the resource ('geometry node tree structure'), and further specifies the content as 'nodes, links, inputs.' This distinguishes it from related tools like get_node_tree and get_geonode_input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the verb 'Get' and the resource type, but there is no explicit guidance on when to choose this tool over alternatives, nor any caveats or required setup. It stops at stating what it does.
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=true, and the description ('Get info') aligns without contradiction. The description adds a useful preview of returned content (layers, frames, stroke count) but does not disclose error behavior, object type requirements, or result formatting details, which would be valuable 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose and key data points with no redundant words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool with an output schema, the description fails to clarify the sole required parameter, leaving a significant usability gap. The absence of parameter guidance makes the tool incomplete for an agent to invoke correctly, even though the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain the 'object' parameter at all. The agent is left to guess whether 'object' refers to a name, ID, path, or some other identifier, making correct invocation highly uncertain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get grease pencil info: layers, frames, stroke count.' It specifies a concrete verb ('Get'), a resource ('grease pencil info'), and precise data items, effectively distinguishing it from sibling tools like get_object_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving grease pencil-specific data but does not explicitly state when to use this tool versus alternatives such as get_object_info or add_gp_layer. No exclusions or when-not scenarios are mentioned, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only mentions that the direction is UP or DOWN, but does not explain how the move affects the constraint order, what the optional bone parameter does, or how errors are handled. This is insufficient for an agent to anticipate the tool's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no unnecessary words. It front-loads the primary action and then specifies the direction parameter, making it easy to parse or skim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 too minimal for a tool with 4 parameters and no annotations. It does not explain the meaning of moving a constraint up/down, the role of the bone parameter, or the expected inputs for object and constraint. The agent would need more context to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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. However, the description only clarifies the 'direction' parameter (UP or DOWN) and leaves 'object', 'constraint', and 'bone' unexplained. This fails to provide necessary semantic meaning for three of four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves a constraint up or down, which is a specific verb (move) with a resource (constraint) and direction. This distinguishes it from other constraint tools like add_constraint or set_constraint_property, which affect constraints differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reordering constraints, but it does not explicitly state when to use it versus alternatives, nor does it provide exclusions. It lacks context about whether this is for the constraint stack order or other ordering, but the intent is apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
IdempotentHint is provided and not contradicted, but the description adds no behavioral context beyond the property list. It does not mention side effects, prerequisites (e.g., edit mode), or how setting properties like use_connect affects bone hierarchy. With annotations covering idempotency, the description still lacks meaningful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource, followed by a compact list of allowed properties. Every word earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 incomplete for effective use. It does not specify how to identify the object (armature) and bone, nor does it explain the expected value formats for each property. An agent would need additional knowledge to safely and correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 lists property names without explaining their value types or meanings. For example, it does not clarify that head and tail are likely 3-number vectors, roll is numeric, and use_connect is boolean. This leaves critical parameter semantics unresolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a bone property and enumerates the specific properties allowed (roll, envelope_distance, head, tail, use_connect), making the action and resource unmistakable. This distinguishes it from sibling tools like set_pose_bone_transform 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for modifying these bone properties, but provides no explicit 'when to use' or 'when not to use' guidance. It does not mention alternatives or exclusions, such as using set_pose_bone_transform for pose bones, so the usage context is only implicit.
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 idempotentHint annotation already covers repeat-safety, and the description adds context by enumerating the specific properties that can be set. However, it does not disclose any additional behavioral traits such as value constraints, error behavior, or whether setting some properties might have side effects on other properties. The property list is useful but minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that leads with the action and resource, then lists the supported properties. It contains no filler, redundant phrases, or repetition of the input schema fields. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple setter but has clear gaps. It does not specify the expected object parameter, value types, or how properties like dimensions should be structured. Since there is an output schema, return values are not a concern, but the lack of parameter usage details and the absence of context around curve objects makes it only minimally complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 bare 'string' type of the 'property' parameter. It does so by listing valid property names, which adds real meaning. However, it does not explain the 'object' parameter (which curve object) or the 'value' parameter format (e.g., dimensions likely expects an array of two floats). This partial compensation earns a middle score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Set') and resource ('curve property') and lists specific properties it can set (bevel_depth, extruded, dimensions, etc.). This differentiates it from sibling setter tools like set_material_property or set_light_property because the property list is curve-specific, though it does not explicitly mention 'curve object' in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternative setter tools. The tool name and property list imply it is for curves, but there are no prerequisites, exclusions, or mentions of alternatives. The description simply states what it does without contextual usage 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 idempotentHint annotation indicates repeated calls have no additional effect, but the description adds no behavioral context beyond that. It does not describe what happens when the property does not exist, how values are cast, or whether changes are immediate. The examples are property-name guidance, not 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences front-loaded with the primary purpose, followed by a useful example clause. It contains no redundant phrases and all sentences earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, the description covers the core function and key parameter semantics. However, it lacks details about error behavior (e.g., missing modifier/property), accepted value formats, and any return value, though an output schema exists. The lack of usage guidance also limits completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for its four parameters, so the description must compensate. It does add meaning for the 'property' parameter by stating that property names are Blender API names and providing concrete examples. However, it does not explain object/modifier references or value type handling (the 'value' parameter accepts five heterogeneous types), leaving gaps for half the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Set') and resource ('a modifier property'), immediately distinguishing it from sibling property setter tools like set_material_property or set_light_property. The supplementary examples ('levels' for SUBSURF, 'count' for ARRAY) reinforce this specific domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., adding a modifier first), nor does it differentiate itself from other property setters in the sibling list. The description merely restates the tool's function without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, prerequisites, or whether the tool creates or modifies objects. 'Set up' is vague about the operational impact on the given domain mesh or emitter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The 'Template:' prefix is minor noise, but the core instruction is immediately clear and appropriately concise for a two-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a setup tool with no annotations and 0% parameter coverage, the description omits crucial context such as what a 'domain' object must be, how the emitter is used, and any side effects. Though an output schema exists, it does not compensate for the missing behavioral and parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description merely names 'domain' and 'optional emitter' without explaining their roles, types, or requirements. It adds minimal semantics beyond the parameter names, failing 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set up fluid simulation with domain and optional emitter.' It uses a specific verb ('set up') and resource ('fluid simulation'), and the mention of 'domain' and 'optional emitter' distinguishes it from sibling tools like setup_cloth_sim or setup_rigid_body_world.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fluid simulation scenarios but provides no explicit when-to-use guidance or alternatives. There is no mention of when to prefer this over other physics setup tools, resulting in only implied 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 description discloses no behavioral traits beyond the verb 'Set', indicating a mutation. The idempotentHint annotation covers idempotency, but the description adds no further context about side effects, valid value ranges, or error behavior. With annotations present, the bar is lower, but the description still contributes minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the action verb 'Set'. It efficiently communicates the resource and example properties with no filler, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (2 required params, idempotent annotation, and an output schema exists), so the description covers the basics. However, it lacks a complete list of valid property names and value formats, which could leave an agent uncertain about non-example properties. The description is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description partially compensates by naming 'color' (likely array) and 'strength' (likely number), adding meaning to the 'value' parameter. However, it does not specify exact value formats (e.g., color range or color space) or list other possible property names, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Set' and clearly identifies the resource as 'world/environment property', with concrete examples 'color, strength'. This distinguishes it from sibling property setters like set_material_property or set_light_property. However, it does not enumerate all possible properties, slightly limiting full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for world/environment properties but provides no explicit guidance on when to use this tool vs alternatives. It does not mention exclusions, prerequisites, or alternative tools for world creation (e.g., create_hdri_world). The context is only inferred from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It only states the action and types; it does not disclose side effects, whether an existing object is replaced, how name/location defaults behave, or what is returned. For a mutation tool this is insufficient 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences with no filler. It front-loads the action and packs the type enum compactly, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, no-required-parameter creation tool with an output schema, so the description does not need to discuss return values. However, it omits behavioral context and leaves location semantics unclear, making it only marginally complete for an agent that must invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description partially compensates for the 0% schema coverage by enumerating valid values for the type parameter, but it says nothing about name or location semantics. Since location is an array of numbers with no explanation, the agent must guess its meaning from the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and a clear resource ('curve object'), and it distinguishes this tool from generic create_object by explicitly listing the supported curve types (BEZIER, NURBS, POLY). This makes the tool's purpose immediately 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description ('Create a curve object'), so an agent can infer it is for curves rather than other object types. However, there is no explicit statement of when to use this tool versus alternatives like create_object, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'Add a shader node' and lists types, but does not explain whether the node is automatically connected to the material output, what happens if the material or type is invalid, or any side effects. The presence of an output schema helps but the description alone lacks critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, with the purpose front-loaded and the common types listed in a compact enumeration. Every sentence earns its place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a straightforward node creation tool, but it leaves gaps: it does not mention that the node is added unconnected, does not explain optional parameters, and does not state error behavior. Given the existence of an output schema, some return-value details may be covered, but the description alone is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to the 'type' parameter by listing common valid values, but it does not explain 'material', 'name', or 'location' parameters. Without this, the agent has to infer semantics from parameter names and tool context, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Add a shader node to a material.' It also lists common node types, which distinguishes it from other node creation tools (e.g., create_geonode, create_comp_node) by specifying the shader node context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding shader nodes to materials in a shader node tree, and the list of common types helps identify appropriate values. However, it does not explicitly distinguish when to use this tool versus sibling tools like create_geonode or create_comp_node, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It discloses the core action and return value, but omits important details such as what happens when new_name is null, whether existing materials can be overwritten, and whether the source material's relationships 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The information is front-loaded and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, the description is adequate but has gaps. It lacks usage guidance and parameter semantics, and does not explain auto-naming behavior or potential error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. It does not explain that 'name' is the source material or that 'new_name' is an optional override, though these are weakly inferable from the parameter names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Duplicate a material') with a specific resource and even includes the key return value ('Returns the new material name'). This distinguishes it from sibling tools like duplicate_object and create_material by naming the material resource explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_material, duplicate_object, or delete_material. 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates that this is a read-only operation. The description is consistent with that and adds no additional behavioral context, such as what happens if the object has no physics settings or the exact nature of the returned data. It does not contradict 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Get physics settings on an object.' It is concise, front-loaded with the verb, and contains no fluff or redundant information. This 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter) and the presence of annotations and an output schema, the description is minimally sufficient. However, it leaves ambiguity about what 'physics settings' encompasses and does not mention edge cases like missing physics components. It could be more explicit about the scope of the returned setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter 'object' with no description (0% schema coverage). The description merely states the action occurs 'on an object', which adds minimal meaning but does not explain how to specify the object (e.g., by name, path, or ID) or what constitutes a valid object. The description fails to fully compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get physics settings on an object' clearly states the tool's function with a specific verb (get) and resource (physics settings on an object). It distinguishes itself from sibling tools like add_physics, set_physics_property, and get_object_info by focusing specifically on retrieving physics-related 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/5Does 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, common scenarios, or exclusions. The usage is only implied by the verb 'get'.
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 aligns with the readOnlyHint annotation, indicating a read-only operation. However, it adds no additional behavioral context such as whether it requires pose mode, what exactly is returned, or any side effects. Since annotations already cover safety, the description provides minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values are covered. However, the description lacks parameter semantics and usage guidance, making it only minimally complete for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions and the description does not explain the parameters 'object' and 'bone'. While the parameter names are somewhat self-explanatory, the description fails to clarify that 'object' likely refers to an armature and 'bone' to a specific bone name. With 0% schema coverage, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List constraints on a pose bone.' It uses a specific verb and resource, distinguishing it from sibling tools like list_constraints that likely operate on objects, not pose bones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 list_constraints or add_bone_constraint. The context is implied from the name, but there is no explicit mention of use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action ('remove') without mentioning irreversibility, error handling, or side effects on the object. With no additional context, the agent cannot fully anticipate the tool's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words, making it highly efficient to parse. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and schema descriptions, the description is minimal. It covers the basic action but omits usage guidance, parameter semantics, and behavioral context, making it inadequate for an agent to confidently select and invoke the tool without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by name', which clarifies that the 'modifier' parameter is a name, adding some meaning beyond the schema. However, the schema has 0% coverage, and the description does not explain the 'object' parameter or accepted formats, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('modifier'), clearly stating the action operates on an object by name. This distinguishes it from sibling tools like 'add_modifier' and 'set_modifier_property'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for removing a modifier from an object, but does not explicitly state when to use it vs alternatives like 'toggle_modifier_visibility' for temporary hiding. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the original mesh is modified, deleted, or preserved, nor does it explain prerequisites such as needing a selection for SELECTED mode. The side effects of the separation operation are entirely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core action and immediately lists the available modes. It contains zero fluff and every part contributes to understanding the tool's functionality. This is an exemplary concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and absence of annotations, the description should cover more behavioral context such as side effects, prerequisites, and error conditions. While an output schema exists to handle return values, the operational details are incomplete, making the tool difficult to use correctly without further investigation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'mode' parameter by explaining each mode option ('LOOSE (by loose parts), MATERIAL (by material), SELECTED'). However, the required 'object' parameter is not described, and with 0% schema description coverage, the description only partially compensates for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Separate mesh into multiple objects.' It also details three modes, which distinguishes it from sibling tools like join_meshes, which performs the opposite operation. This is a precise and unambiguous purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a mesh needs to be split into separate objects) but provides no explicit alternatives or exclusions. There is no mention of when not to use it or comparison to other mesh tools like join_meshes. The context is clear but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the angle limit unit and default, but does not disclose whether the operation is destructive, whether it replaces existing UV maps, or what prerequisites exist (e.g., object selection). This is a significant gap for a mutation-like 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a parenthetical, covering purpose and a key parameter nuance without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and only two parameters, the description lacks critical context about side effects (e.g., whether existing UVs are replaced), required object state, or how results are returned. For an autonomous agent, this is incomplete guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds meaning to angle_limit by specifying 'radians (default ~66 degrees)' and explaining the default's approximate value. However, it does not elaborate on the object parameter, which is self-explanatory from context but still undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Auto UV unwrap using smart project.' This specifies the verb (unwrap), resource (UV), and method (smart project), distinguishing it from sibling tools like get_uv_maps and create_uv_map, which handle UV maps but not unwrapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for automatic UV unwrapping via smart project, but it does not explicitly mention when to use it versus alternative unwrap methods or when not to use it. There are no direct sibling unwrap tools, but the guidance could be stronger.
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?
The description says 'Toggle', which implies a state switch that is not idempotent (calling twice returns to original state). However, annotations include idempotentHint: true, which directly contradicts the described behavior. This is a serious inconsistency that could mislead an agent into assuming repeated calls have no additional effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and scope. Every word earns its place; there is no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description captures the core functionality. However, the contradiction between the description and the idempotentHint annotation creates confusion, and the lack of parameter semantics leaves gaps in understanding the exact behavior. An output schema exists, but the description still fails to clarify the toggle semantics fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only mentions 'viewport' and 'render' without explaining the meaning of boolean values or null defaults. It does not clarify what true/false/null control, nor does it describe the required 'object' and 'modifier' parameters beyond their names. The description adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Toggle'), the resource ('modifier visibility'), and the scope ('in viewport and/or render'). It is specific and distinguishes itself from sibling tools like set_modifier_property, which is a broader property setter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to toggle modifier visibility in viewport or render). It does not explicitly mention alternatives or when-not-to-use, but the context is clear enough for an agent to choose this over more generic property setters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral details such as in-place modification of the object's modifier stack, error handling, or whether the modifier is added with default properties. For a mutating tool, this leaves the agent without essential safety and side-effect 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, with the primary action front-loaded and a valuable enumeration of type examples. There is zero wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and type values, but omits usage guidance relative to sibling modifier tools and behavioral context for a mutating operation. The presence of an output schema mitigates the need to describe return values, yet the description remains only moderately complete for an agent to confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions (0% coverage), so the description carries the burden. It compensates partially by listing common values for the 'type' parameter, but does not clarify the meaning of 'name' (optional, default null) or 'object'. Thus, it only partially fills the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Add' and the resource 'modifier to an object', and provides a useful list of common modifier types. This sharply distinguishes it from sibling tools like remove_modifier or set_modifier_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you want to add a modifier) but does not explicitly mention alternatives or exclusionary cases. It could be improved by noting that modifying existing modifiers is handled by set_modifier_property or similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the main behavioral trait: transforms are applied to mesh data and reset to identity. With no annotations provided, it carries the full burden, but it omits details such as irreversibility (except undo), object type requirements, or the effect of selectively disabling parameters. It is not misleading but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. It front-loads the action and immediately explains the outcome, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation operation with no annotations and sparse parameter documentation. The description provides the core function but does not mention prerequisites (e.g., object must be a mesh, object mode required), edge cases (e.g., effect on children), or the nature of the output. Given the availability of an output schema, the return format is covered, but the operational context remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 (name, scale, location, rotation). While the boolean names are somewhat self-explanatory, the description does not clarify that these flags control which transforms are applied or how defaults behave, leaving the agent to infer critical details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Apply (freeze)') and resource ('the object's transforms to mesh data'). It also explains the result ('Resets the applied transforms to identity'), which distinguishes it from sibling tools like set_transform or set_origin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Apply (freeze)' implies the use case of making transforms permanent before further editing, and 'Resets the applied transforms to identity' clarifies the outcome. However, it does not explicitly mention when to use this tool versus alternatives, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose key behavioral aspects such as whether existing lighting is overwritten, required file formats, or side effects on the scene. The phrase 'Set up' suggests configuration but leaves the operational details vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It is well-structured and front-loaded, immediately conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no annotations, this description is too thin. It omits details about the strength parameter, return value, and potential side effects, making it insufficient for an agent to invoke the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description hints at the 'filepath' parameter via 'image file' but provides no explanation for the 'strength' parameter. With 0% schema description coverage, the description adds minimal semantic value beyond the schema's type and default information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set up') with a clear resource ('HDRI environment lighting') and a source ('from an image file'). This distinguishes it from sibling tools like create_light and set_world_property, making the tool's 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool (when HDRI environment lighting is needed) and provides context about using an image file. However, it does not explicitly mention alternatives or when not to use it, stopping short of full 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?
No annotations are present, so the description carries the burden of disclosing behavior. It only states the core create/assign action but omits details like idempotency, behavior if the vertex group already exists, error handling for invalid objects, or how vertices are interpreted (e.g., zero-based indices). This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action and optional behavior with zero wasted words. It is maximally concise while still conveying essential meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the operation involves 4 parameters and no annotation safety context. The description covers optional params but lacks guidance on required params (object, name) and lacks behavioral caveats. It is minimally adequate for a simple create operation but leaves ambiguities that could cause incorrect invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must clarify parameters. It explains 'vertices' and 'weight' explicitly ('optionally assigning vertices with a weight'), but leaves 'object' and 'name' unaddressed beyond their literal names. This partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a vertex group') and the optional assignment of vertices with a weight. This distinctly differentiates it from sibling tools like get_vertex_groups (viewing groups) and assign_vertex_weights (modifying existing groups).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (creating a group) but does not explicitly contrast with alternatives like assign_vertex_weights for modifying existing groups. No when-not or prerequisite context is provided, though the name and verb make the primary use clear.
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, consistent with the read operation. The description adds specific retrieved fields, but does not disclose error behavior or handling of non-curve objects. With annotations covering the safety profile, this is acceptable 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the purpose and lists the queried properties without any filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema is present, so return values are likely documented elsewhere. For a simple info-getter, the description covers the core behavior, though it could benefit from a note that the provided object must be a curve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'object' string parameter with 0% description coverage. The tool description implies that 'object' refers to the curve to query, but does not explain how to specify it (name, path, reference), nor any validation rules. The description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'curve info', and enumerates specific attributes (spline count, point count, dimensions, bevel settings) that distinguish it from similar get_* tools like get_object_info or get_mesh_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_mesh_info or get_object_info. It only implicitly indicates curve objects via the tool name and listed fields, but does not state exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the read-only nature, and the description aligns with it. The description adds minimal behavioral context beyond the annotation—simply that it retrieves current settings, with no extra details about return shape or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and object. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with no parameters and an output schema that defines return structure. The description, while minimal, is sufficient for an agent to understand the tool's scope, but it could optionally mention that it returns world shader settings specifically.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meanings since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current world/environment shader settings', which is specific and distinct from other getter tools. However, it does not explicitly differentiate from siblings like get_scene_info or get_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/5Does 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 get_scene_info or set_world_property. There is no mention of 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 only provide idempotentHint: true, so description must disclose behavioral traits. It adds that the tool works at modifier level and affects the Group Input interface, but doesn't explain prerequisites (e.g., modifier must be Geometry Nodes), failure modes, or side effects on dependent geometry. Comparable to the get_calls calibration example, score 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single short sentence with no filler, directly states the operation. Score 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description leaves critical gaps: no parameter semantics, no usage guidance, no mention of constraints (e.g., modifier type), and potential confusion with similarly named set_geonode_input. It is incomplete for a 4-param mutation tool. Score 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 four parameters (object, modifier, input_name, value). It only gives a vague hint about 'input' referring to the Group Input, but leaves meaning of object and modifier unclear. Since description doesn't compensate for low schema coverage, score 2.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the target ('modifier-level input'), explicitly noting it's for Group Input interface values. This distinguishes it from sibling tools like set_geonode_input (node-level) and set_modifier_property (general modifier properties), earning 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The description implies it is for setting values on Geometry Nodes modifier inputs, but doesn't mention when to prefer it over set_geonode_input or set_modifier_property. This is implied usage, so score 3.
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 idempotentHint=true is not contradicted by the description. The description adds useful detail (rotation in radians, and/or indicates partial updates) but does not disclose potential side effects like overwriting existing transform values or error behavior for non-existent objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundancy. It front-loads the verb and target, and the 'and/or' phrase efficiently conveys flexibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with idempotentHint annotation, the description covers the core function adequately. However, missing usage guidelines and partial parameter semantics leave some gaps. The tool's simplicity and available annotation prevent a lower score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 names location, rotation, and scale and specifies radians for rotation, but does not explain the vector format, array order, or how null parameters are interpreted. The required 'name' parameter is not described at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: setting an object's location, rotation (in radians), and/or scale. It uses a specific verb (set) and resource (object's transform properties), which distinguishes it from sibling tools like apply_transform or set_pose_bone_transform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply states the operation without context, prerequisites, or examples of when this is the appropriate choice over other transform-related 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?
There are no annotations to rely on, so the description must disclose behavior. It only states the action and format, omitting details like whether it replaces all vertices or only given indices, requirements on the object type, coordinate space, or error behavior. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the action, and includes the essential data format. There is no redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool, it is minimally viable. It explains the core action and parameter structure, but lacks behavioral details that would help an agent avoid errors (e.g., what happens if indices are invalid). The output schema exists, so return value info is not required, but other context is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates by explaining the structure of the 'vertices' parameter with 'Each entry: {index: int, co: [x, y, z]}'. It does not describe 'object', but it is inferable from the context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Set vertex positions') and specifies the resource (vertices). It distinguishes from sibling tools like get_vertices, which reads positions. The entry format adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives, nor any prerequisites or side effects. It simply states the operation, leaving the agent without contextual cues for selection or invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add important context about preserving the world transform, which is a meaningful behavioral trait. However, it does not mention what happens if the object has no parent, whether children are affected, or any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the action and the key behavioral detail. No wasted words; every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 covers the core purpose and the main side effect (preserving world transform). However, without annotations, it lacks detail on failure modes, prerequisites, or how it relates to other parenting tools. The output schema covers return values, so that gap is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% because the 'name' parameter has no description, and the tool description does not explicitly explain that 'name' is the object whose parent shall be cleared. The phrase 'an object's parent' implies the parameter, but it does not directly map to it or provide additional details like requiredness or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Clear') with a clear resource ('an object's parent') and a distinct effect ('keeping its world transform'). It unambiguously distinguishes this from sibling tools like set_parent, which would restore or change parenting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to unparent while preserving the world transform), but it does not explicitly state alternatives or exclusion conditions. No direct comparison to set_parent or other transformation-related tools, leaving some ambiguity.
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 the safe, read-only nature of the tool, so the description does not need to repeat that. The description adds the list of returned properties, which is useful context but introduces no additional behavioral nuance such as error conditions or side effects beyond what the annotation covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Get bone info: head, tail, roll, parent, children, constraints.' Every word contributes meaning, and the list format is efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so the description does not need to describe return values. However, it lacks parameter explanations and usage guidance, leaving gaps in a 2-parameter tool. It is adequate for a simple getter but still has clear deficiencies given the zero-coverage schema and ambiguous 'object' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden for explaining the 'bone' and 'object' parameters, but it does not. 'bone' is inferable as the bone name, but 'object' is ambiguous—it is likely the armature object but the description does not state this. No additional meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with the specific verb 'Get' and identifies the resource as 'bone info', then lists the exact attributes returned: head, tail, roll, parent, children, constraints. This clearly distinguishes it from sibling tools like get_armature_info (which covers the whole armature) and set_bone_property (which modifies bone properties).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when someone needs to read bone attributes, but it does not explicitly state when to use it versus alternatives like get_armature_info or list_bone_constraints. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation declares readOnlyHint=true, and the description uses 'Get', so there is no contradiction. It adds the return detail 'member counts' which gives some behavioral context, but it doesn't discuss potential errors, required object format, or side effects. With annotations covering the safety profile, a 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence. Every word adds value—'Get vertex groups' states the action, 'on a mesh' the scope, and 'with member counts' the output. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 an output schema, so the description doesn't need to explain return structure. However, it lacks details on how to specify the object and when to use this tool. This leaves gaps, but given the context signals, it is adequate. A 3 reflects the missing usage guidance and parameter specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter 'object' with no description (0% schema description coverage). The description indicates the object should be a mesh, but it doesn't explain how to reference the object (by name, path, etc.). This minimal hint does not fully compensate for the lack of schema documentation, so a 2 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('vertex groups on a mesh') plus a key output detail ('with member counts'). This clearly distinguishes it from sibling tools like get_mesh_info or get_vertices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative tools are mentioned. The phrase 'on a mesh' implies it is for mesh objects, but there is no guidance on when to choose this over other getter tools. Usage is only implied, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It does mention format auto-detection from extension and lists supported formats, which is useful. However, it doesn't disclose potential side effects like creating objects in the current scene or whether 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, then lists formats and auto-detection. Every word contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter import tool with an output schema, the description covers the core behavior and format list adequately. It lacks some nuance about filepath requirements (e.g., absolute vs relative) but this is not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage). The description compensates by listing supported formats, giving valid values for the 'format' parameter, and explaining that format is auto-detected if not specified. Yet it doesn't elaborate on 'filepath' beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports a file into the scene and lists supported formats. It distinguishes itself from export_file but does not explicitly differentiate from the load_file sibling, which might be used for Blender files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: import external file formats into the scene. However, there is no explicit guidance on when to choose this over load_file or other file-related tools. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal an important behavior: 'Deselects others by default.' However, it does not disclose potential side effects such as clearing the current selection, what happens when no criteria match, or whether the operation is reversible. This is partial 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, each delivering key information: the selection methods and the default deselect behavior. It is front-loaded and free of filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with four optional parameters and an output schema (as per context). The description covers the primary behavior (selection and default deselect) and the input methods. It does not need to explain return values since an output schema exists. Minor gaps remain around edge cases, but for a basic selection tool, the description is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning to the parameters. It does conceptually map to the parameters: 'name list' refers to names, 'glob pattern' to pattern, 'type' to type, and 'Deselects others by default' to deselect_others. However, it does not explain details like how multiple criteria interact, precedence, or accepted formats (e.g., exact glob syntax). It provides some context but not full semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Select objects by name list, glob pattern, or type.' It uses a specific verb ('select') and defines the resource (objects) and the selection criteria. This also distinguishes it from sibling tools like list_objects (which lists) and find_objects (which searches), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when to prefer selection over listing or finding, nor does it exclude scenarios. There is no explicit mention of alternatives or context-specific recommendations, so the agent 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?
The idempotentHint annotation already covers the main non-obvious behavioral trait. The description adds no further behavioral context, such as whether the camera must exist or what happens on failure. It does not contradict 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no wasted words. It is fully appropriate for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 is minimally acceptable, especially with the idempotent annotation and output schema available. However, it lacks parameter semantics and usage differentiation from sibling tools, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'name' as a required string with no description, and the description does not explicitly clarify that this is the camera name. Although it is inferable from the tool name, the description adds little meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set the active scene camera.' uses a specific verb and resource, clearly distinguishing this from sibling tools like set_viewport_camera or list_cameras. It succinctly states exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you need to change the active scene camera, but it provides no explicit guidance on when to use it versus alternatives like set_viewport_camera. It gives no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds no extra behavioral context beyond the list of returned attributes, such as what happens if the object is not a mesh or whether it queries the active object. It is consistent but not enriching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists all relevant output fields without extraneous words. Every part adds 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so the description need not explain return values. It covers the main attributes. However, it lacks context about error cases (e.g., non-mesh object) or whether the operation is limited to the active object, leaving minor gaps for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'object' has no schema description (coverage 0%), and the description does not explain what value to pass (e.g., object name). The parameter name alone is somewhat self-explanatory, but the agent receives no explicit guidance, so the description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and resource (mesh info), and enumerates the specific data fields returned (vertex/edge/face count, UV maps, vertex groups, has_custom_normals). This distinguishes it from sibling tools like get_object_info and get_physics_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage for retrieving mesh-specific attributes, but provides no explicit guidance on when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The context signals show a clear mesh-related niche, but the guidance is only implicit.
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 read-only nature is already covered. The description adds that results are limited to avoid huge payloads and that filtering by vertex group is possible, but does not detail behavior when the limit is exceeded or whether coordinates are in object or world space.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences (12 words), front-loaded with the main action. Every word adds value, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the output schema likely covers return values. The description covers purpose, filtering, and limiting, but lacks an explicit explanation of the 'object' parameter and coordinate space, leaving some ambiguity for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains the group filter and implies the limit, but the required 'object' parameter is not described, leaving a core semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get vertex positions' with a specific verb and resource. It is immediately distinct from siblings like set_vertices (a write operation) and get_vertex_groups (which returns group names, not positions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when vertex positions are needed, and mentions optional filtering by vertex group. However, it does not explicitly state when to use this tool over alternatives such as get_mesh_info or how it differs.
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 this as a safe read operation. The description adds that the result includes modifier type and settings, but it does not disclose additional behavioral aspects like ordering of modifiers, handling of objects with no modifiers, or potential performance implications. This is comparable to the get_calls example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action ('List all modifiers') and contains no filler. Every word contributes to conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with a provided output schema, the description is nearly complete: it states what is listed and what information is returned. The main gap is the under-specified parameter, but the tool's simplicity and the existence of an output schema reduce the overall need for additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the 'object' parameter, and the description only mentions 'on an object' without specifying the expected format (e.g., object name, path, or ID). The description adds little meaning beyond the parameter name itself, leaving the agent guessing about how to supply the object identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'modifiers on an object', distinguishing it from sibling tools like add_modifier, remove_modifier, and list_lights. It also specifies the output content ('type and settings'), 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for inspecting existing modifiers on an object, but it does not explicitly state when to use this tool over alternatives such as get_object_info or set_modifier_property. There is no mention of exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the burden of behavioral disclosure. It states that images are packed 'into the blend file' implying a file modification, but does not mention whether this is permanent, increases file size, or requires external images to exist. The lack of side-effect disclosure is a significant gap for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete, and purposeful sentence with no redundant information. It is appropriately sized for a tool with no parameters and a clear action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values need not be explained. However, the description omits any behavioral caveats (e.g., effect on existing data, irreversible changes) and does not mention whether it works on the currently loaded blend file or requires saved paths. For a file-modifying operation, this is a minor completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty. According to the rubric, a baseline of 4 is appropriate since no parameter documentation is needed. The description adds no parameter info, but none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'pack' with a clear resource 'external images' and target 'into the blend file,' making the tool's purpose unambiguous. It distinguishes itself from siblings like load_image or list_images by focusing on the embedding action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: the tool is used when one wants to embed external images into the blend file. However, there is no explicit guidance on when to use this tool versus alternatives, nor any prerequisite conditions 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 provides the data format for points (Bezier vs NURBS/Poly), which is a useful behavioral detail. However, it does not disclose side effects, whether the operation replaces existing points, whether the object must be a curve, or any permissions. Given no annotations, the description under-delivers on 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, direct and front-loaded. No superfluous words. The format details are necessary and placed second. Well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a setter tool with three parameters and no annotations, the description gives essential format info but omits behavioral context such as whether the points array replaces all existing points or just the specified ones, and lacks clarity on spline_index semantics. It is serviceable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (0% coverage). The description compensates by specifying the structure of points entries, including co, handle_left/handle_right for Bezier and co with w for NURBS/Poly. It does not add meaning for object or spline_index, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Set control point positions on a spline.' This clearly differentiates from sibling tools like set_curve_property or get_curve_info. It names the exact object of action (control points) and the resource (spline).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit mention of when to use this tool versus alternatives, but the specific phrasing implies it is for control point positions, which is a distinct operation from setting other curve properties. The context is clear enough, though no exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it inserts multiple keyframes and mentions efficiency, but does not disclose important side effects such as whether existing keyframes are overwritten, what happens on invalid frames, or prerequisites like existing animation data. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the purpose. Every word earns its place: it states the action, the keyframe entry format, and the advantage over an alternative. No padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch operation with three parameters and an output schema, the description provides enough to get started but leaves out important context such as error behavior, overwrite semantics, and parameter formats for 'object' and 'data_path.' It is minimally viable but has clear gaps, aligning with a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 explicitly defines the 'keyframes' parameter structure: '{frame: int, value: float|list}' with an example. However, it provides no meaning for the 'object' and 'data_path' parameters, leaving them entirely unexplained. This partial compensation warrants a midpoint score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Batch insert multiple keyframes.' It distinguishes itself from the sibling tool 'set_keyframe' by emphasizing the batch nature, making it unambiguous what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'More efficient than calling set_keyframe repeatedly.' This directly compares to an alternative tool, but does not explicitly state when NOT to use it (e.g., for single keyframe insertion), so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The idempotentHint annotation already signals repeatability. The description adds a small behavioral cue by noting that 'size' is for area lights, implying some properties are context-dependent. It does not disclose other side effects, error conditions, or whether the target light must exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and then provides a concise list of properties. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, the description is mostly adequate, and the presence of an output schema reduces the need to explain return values. However, it omits the value format for each property and does not mention that the light must exist or that the property list is exhaustive. This leaves some important gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the burden. It lists valid values for the 'property' parameter, which is valuable. However, it does not map each property to its expected 'value' type (e.g., color likely an array, use_shadow boolean). This leaves ambiguity for correctly invoking the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('a light property'), then enumerates the specific properties supported. This distinguishes it from sibling set_* tools (e.g., set_material_property, set_world_property).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name and description—it is for modifying light properties. However, there is no explicit guidance on when to use this versus alternatives, nor any mention of prerequisites or exclusions. The context is clear enough 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?
The idempotentHint annotation is not contradicted, and the description adds the 'pose space' context and location/rotation scope. However, it does not disclose behavior when both location and rotation are null, whether this replaces or adds to existing transforms, or if the object must be an armature in pose mode. The description adds some context but lacks deeper behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Set,' and contains no fluff. Every word contributes to defining the action and scope, making it as concise as possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple setter with an output schema and idempotent annotation. The description covers the core purpose but omits important operational context such as whether the armature must be in pose mode, how the 'both null' case behaves, and any relationship to animation or keyframes. It is adequate for a basic setter but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by explaining that location and rotation are transform components in pose space. It implies the object and bone parameters from 'pose bone,' but does not specify the expected array formats (e.g., XYZ or quaternion), units, or null semantics. This provides basic meaning but not full clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Set' and clearly identifies the resource as 'a pose bone's transform,' specifying scope as 'location and/or rotation in pose space.' This distinguishes it from sibling tools like set_transform (object transform) and set_bone_property (bone properties).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'pose bone' and 'pose space' implies usage in pose mode for armature bones, but the description does not explicitly state when to use this tool versus set_transform or set_bone_property. No exclusions, prerequisites, or alternative references are provided; guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the key behavioral trait of replacing versus appending a slot, which is valuable. However, it omits other side effects, prerequisites (e.g., material must exist), or error conditions, leaving notable transparency gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action and immediately clarifying slot behavior. No wasted words or redundant restatements of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and slot behavior, and an output schema exists so return values are handled. It lacks prerequisites (e.g., material/object must exist) and error scenarios, but for a simple assign tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 'slot' parameter's behavior (replace vs append). However, it does not add meaning for 'object' or 'material' beyond their obvious roles, and multi-line schema details are not addressed. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Assign a material to an object.' It also clarifies slot behavior (replace vs append), which distinguishes it from related material tools like create_material or set_material_property. This goes beyond the tool name and provides concrete scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for assigning materials to objects, but does not explicitly state when to prefer it over alternatives or mention any exclusions. The slot behavior gives some context, but it lacks direct sibling differentiation like 'use X instead of Y.'
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 annotation destructiveHint=true already signals destructive behavior. The description adds that confirmation is required, which is not in the annotation or schema. This gives extra behavioral context about a necessary precondition, though it doesn't explain the exact failure behavior if confirm is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the verb and resource. No redundant information; every word earns its place. Excellent concision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description covers the core action and confirmation requirement. The existing output schema and destructiveHint annotation reduce the need for further details. However, it could be slightly more complete by stating that the object is permanently removed, but the annotation already implies destructive intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does clarify that 'name' is the identifier and that 'confirm' is required, but it doesn't explain the default of confirm or the effect of not setting it. This partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete an object') and the scope ('by name'), distinguishing it from sibling delete tools like delete_material and delete_collection. It also mentions the required confirmation, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention batch_delete or other deletion tools, nor does it state any conditions or exclusions. The only usage hint is 'Confirm required,' which is more of a behavioral requirement than a usage guideline.
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. The description adds context about the types of issues detected but does not clarify the return format, scope (scene-wide vs. selected objects), or whether the list of issues is exhaustive. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the verb and resource, then provides concrete examples. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only, has an output schema), the description covers the core purpose adequately. Minor ambiguity remains about whether the listed issue types are exhaustive, but this does not impair usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there are no parameter semantics to explain. Per guidelines, a baseline of 4 applies. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find objects with issues' and enumerates specific examples ('missing textures, broken modifiers, invalid references'). This distinguishes it from generic 'find_objects' by focusing on error detection, 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/5Does 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 'find_objects' or per-object inspection. The description only states what it does, not 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?
Annotations provide readOnlyHint=true, and the description's 'search' action is consistent. The addition of 'glob' clarifies the name pattern matching behavior, but no other behavioral traits (e.g., return format, pagination) are disclosed. With annotations covering safety, this adds limited 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and filter criteria, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple search tool with an output schema and read-only annotation. It covers the primary purpose and filter options, but lacks explicit guidance on optionality or relationship to sibling listing tools. The output schema likely documents return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for parameter descriptions. The tool description lists all four parameters (name_pattern, type, material, collection) and indicates the glob behavior for name_pattern, but provides no additional detail on valid values or formats for type, material, and collection. This partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a search action targeting objects, listing concrete filter criteria (name pattern with glob, type, material, collection). This distinguishes it from sibling tools like list_objects or get_object_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for filtered object search but does not explicitly state when to prefer this over list_objects or mention any exclusions. It lacks explicit alternatives or 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 declare readOnlyHint=true, so the tool is known to be safe and non-destructive. The description adds value by specifying the output content (bone hierarchy and bone count), giving the agent expectations beyond the annotation. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It delivers the core purpose and output details in minimal words, earning a perfect efficiency score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered. However, the description fails to clarify the single input parameter, and there is no mention of prerequisites or error conditions. For a tool this simple, the gap is modest, but the parameter ambiguity makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the sole 'object' parameter. The description does not explain what 'object' refers to (e.g., the armature's name or path). While the tool name implies it is the armature, the parameter semantics are not explicitly clarified, leaving room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('armature info'), and enumerates the exact data returned (bone hierarchy, bone count). This distinguishes it from the sibling get_bone_info, which targets individual bones rather than the whole armature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is only implied: the name and description suggest it is for retrieving armature-level information, as opposed to bone-specific data from get_bone_info. No explicit when-to-use or alternatives are given, so it meets the 'implied usage' criterion but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this is a safe read operation, and the description is consistent. However, the description adds no behavioral context beyond the basic purpose, such as what kind of structure is returned or any traversal specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states exactly what the tool does. Every word contributes to the purpose, with no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only getter with an output schema, the description is largely sufficient. It misses contextual guidance about when to use it relative to other node-tree tools, but the core purpose is clearly conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is effectively complete. With zero parameters, the baseline is 4, and the description does not need to add parameter-level details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get') and resource ('compositor node tree structure'). The 'compositor' qualifier clearly distinguishes it from sibling tools like get_node_tree and get_geonodes_tree, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_node_tree or get_geonodes_tree. The description gives no context for selection 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 declares this as a safe read operation, and the description aligns with that by using 'get'. The description adds the data_path filtering context but does not disclose additional behavioral traits such as return format or edge cases. With annotations present, this is acceptable but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. Every word adds value, and the example is useful without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 parameters, 1 required), has an output schema, and is annotated as read-only. The description covers the core behavior and key parameter. It could explicitly mention that omitting data_path returns all keyframes, but that is implied by 'optionally filtered'. Overall, it is sufficiently complete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 data_path with concrete examples ('location', 'rotation_euler') and implies the object parameter, but it does not fully describe the semantics of object (e.g., name/path expectations) or explicitly state that data_path is optional (though the example suggests it). It covers the essentials but leaves some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('keyframes on an object'), and the optional data_path filter adds precision. It is easily distinguishable from sibling tools like set_keyframe or delete_keyframe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (retrieve keyframes for an object, optionally filtered by data_path) but does not explicitly mention when to prefer this tool over alternatives or any exclusion criteria. It lacks the explicit when/when-not guidance seen in higher-scoring examples.
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 covers safety, but the description adds useful behavioral detail about the returned content (nodes, links, input values). It does not mention error cases or performance, but for a read-only operation this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It is concise, front-loaded, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, read-only) and has an output schema, so the description need not elaborate on return format. However, the lack of parameter documentation leaves a gap, making the description only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the 'material' parameter, leaving its format or meaning unstated. The name gives a hint, but the description adds no value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact action ('Get') and resource ('shader node tree'), and lists the contents ('nodes, links, input values'). This clearly distinguishes it from sibling tools like get_node_input or get_geonodes_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'full shader node tree' implies this is for retrieving the entire tree, and could be contrasted with get_node_input for individual inputs, but no explicit alternatives or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation covers the safety aspect. The description adds that it lists 'all actions' and specifies the scope ('in the blend file'), which is useful context beyond the annotation. However, it does not describe return format, ordering, or performance characteristics, though the output schema may cover some of this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'List all actions in the blend file.' Every word is necessary, with no redundant details or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with an output schema, the description is adequate. It specifies what is listed and the scope. It could optionally hint at potential sibling tools or performance, but given the simplicity, the description is complete enough for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema covers everything (100% coverage with an empty properties object). The description adds no parameter information, but none is needed. Baseline 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a clear resource ('actions'), and a scope ('in the blend file'). This clearly distinguishes it from sibling tools like list_lights, list_materials, etc., all of which target different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_action_info (which may provide details on a specific action). It simply states the action without indicating exclusions or when 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral effects on its own. It only states the action without detailing consequences: does the material data get deleted or just unassigned? What happens if the slot index is out of range? No side effects or error behavior are mentioned. The absence of any additional context makes this a weak 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that contains no filler. Every word adds meaning: it states the action, the target, and the key parameter. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with an output schema, the description is almost complete. It explains the core operation sufficiently for an agent to invoke it correctly. Minor gaps include not stating the return value (though an output schema exists) and not addressing edge cases like invalid slot indices, but these are not critical for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does explain both parameters implicitly: 'object' is the target object and 'slot index' refers to the slot parameter. However, it provides no constraints (e.g., valid range, behavior when slot is omitted despite the default). This is adequate but not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('material slot from an object'), clearly distinguishing it from sibling tools like delete_material (which likely deletes a material) and assign_material. It also specifies the method (by slot index), 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to remove a material slot from an object. It does not explicitly mention alternatives or exclusions, but the purpose is clear enough that an agent can infer it should be used over deleting the material itself. Lacks explicit 'use case A vs B' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the setter action and matches the idempotentHint annotation, with no contradiction. However, it doesn't disclose details like the effect of null parameters (e.g., leaving one channel unchanged) or error behavior if the collection does not exist. The idempotent annotation covers one aspect, but other behaviors remain implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action verb and resource. It contains no wasted words and conveys the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with three parameters and an output schema. The description captures the core purpose and the two visibility contexts, but omits nuances like null behavior and what the `name` refers to. Despite that, it remains complete enough for a straightforward setter in the given context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It does clarify that the boolean parameters correspond to viewport and render, but it doesn't explain the `name` parameter or the null semantics. This is partial compensation 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the resource (collection visibility) along with the specific scope (viewport and/or render). It distinguishes itself from sibling tools like set_viewport_shading or toggle_modifier_visibility by focusing on collection-level visibility rather than other visibility settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when adjusting collection visibility) but provides no explicit guidance on when not to use it or which alternative to choose. Sibling tools are not mentioned, so 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?
The annotations provide idempotentHint=true, which already communicates that repeated sets are safe. The description adds the enumeration of possible properties but does not disclose any additional behavioral traits such as how invalid property names are handled, what the return value looks like, or whether changes affect other layers. It does not contradict annotations; it simply adds minimal context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the purpose and lists examples. Every word earns its place; there is no verbosity or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple setter with four parameters and an output schema, so the description need not explain return values. Combined with the idempotentHint annotation, the description is adequate for invoking the tool correctly. It could be improved by noting that the layer must already exist or that property names are case-sensitive, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to the 'property' parameter by listing allowed values, and hints at value types (e.g., color as array, opacity/thickness as number, use_lights as boolean). However, it does not explain the 'object' and 'layer' parameters, which the agent must infer from context. Value types are already in the schema, so the description only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with the action verb 'Set' and identifies the specific resource 'GP layer property', which clearly distinguishes it from sibling tools like set_material_property or set_light_property. It also lists the exact property names (color, opacity, thickness, use_lights) that can be set, providing concrete scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the resource (GP layer), so an agent can infer this tool is for modifying grease pencil layer properties. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The guidance is only implicit through the tool 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?
The annotation idempotentHint=true is present, and the description does not contradict it. However, the description adds little beyond the annotated idempotency—no mention of error conditions, scope of properties, or simulation impact. Given the annotation coverage, the description is minimally 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with an illustrative example, front-loaded and free of filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (content unknown) and the description provides a clear, concise example. It is reasonably complete for a simple setter, though it could mention that valid properties depend on the physics type or that object must already have physics enabled. Overall, adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The example maps type, property, and value to concrete values (RIGID_BODY, mass, 5.0), which gives some semantic meaning. However, it does not explain valid ranges of property names or type variations, leaving gaps for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set a physics property') and resource (physics property), with an example that reinforces the purpose. It is distinct from sibling tools like add_physics or setup_rigid_body_world, which create/setup physics, while this tool modifies existing properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The example implies usage ('type=RIGID_BODY, property=mass, value=5.0') but does not explicitly state when to use this tool versus alternatives like setup_rigid_body_world or set_material_property. No exclusionary guidance is provided, so it is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation establishes the tool is safe, and the description adds useful context: it writes a file and returns the file path. It does not mention overwrite behavior or error cases, but the added detail about return value goes 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, target, and return value. Every word earns its place with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and a clear return value, the description is largely complete. It could mention file format or overwrite behavior, but given the simplicity and presence of annotations, it is sufficient for most uses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the 'filepath' parameter beyond implying it is the save destination. The parameter name and default value help, but the description adds no extra semantic detail, failing to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Capture') and resource ('3D viewport') and clearly states the output ('to a file. Returns the file path.'). This clearly distinguishes it from sibling tools like render_viewport or get_viewport_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need a viewport screenshot saved to a file) but does not explicitly state alternatives or when not to use it. For a simple, self-explanatory tool this is acceptable but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, so the destructive nature is known. The description adds valuable behavioral context beyond that: 'Confirm required' specifies a user confirmation step, and 'Removes from all object slots' discloses the cascading side-effect on objects using the material. This goes 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, front-loaded sentences: action, requirement, and side-effect. Every sentence carries meaningful information with no filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with a destructive annotation and output schema, the description covers the essential facts: the action, the confirmation requirement, and the cascading effect on object slots. However, missing explicit parameter semantics (beyond confirm) and lack of comparison to remove_material slightly reduce completeness, but it is still adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only addresses the confirm parameter ('Confirm required') and leaves the name parameter semantics implicit. While name is obvious from the tool name, the description does not explain the required true value for confirm or any other parameter details, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a material' with a specific verb and resource. It distinguishes from similar tools like remove_material by adding 'Removes from all object slots,' indicating this is a global deletion rather than a per-object removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this to fully delete a material, with 'Removes from all object slots' clarifying the scope. However, it does not explicitly name alternatives (e.g., remove_material for partial removal) or provide when-not-to-use guidance, so the 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.
- Behavior4/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 specific behavioral detail by listing exactly which settings are retrieved (base color, metallic, roughness) and that it returns a 'node tree summary' rather than the full tree, which clarifies the scope of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, begins with the action verb, and lists the key returned fields without extraneous information. Every word contributes to clarifying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple getter with one parameter and an output schema available. The description covers the main purpose and the key fields returned, which is sufficient given the low complexity and the existence of an output schema. It doesn't explain error cases or prerequisites, but these are less critical for a read-only getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'name' with no description (0% coverage). The tool description does not mention the parameter, so there is no explicit statement that it refers to the material's name. The connection is only implied by the tool name. 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' and clearly specifies the resource ('material settings') followed by the specific fields returned (base color, metallic, roughness, node tree summary). This distinguishes it from sibling tools like set_material_property (which sets) and get_node_tree (which returns the full node tree, not just a summary).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives or any exclusion criteria. The intended use is implied by the name and description, but no alternatives or when-not scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the readOnlyHint annotation by listing the specific settings returned. Since the annotation already indicates a safe read operation, no further behavioral disclosure is needed. It does not contradict annotations, and there are no side effects to mention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and lists the key settings in a compact, scannable format. 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless read-only tool with an output schema and readOnlyHint annotation, the description is complete. It names the essential fields and does not need to explain return format or additional behavior, as those are covered by structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. The description effectively communicates that no inputs are required, which is the key semantic here. Baseline for 0 params is 4, and the description meets this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb 'Get' and resource 'render settings', and enumerates the exact fields returned (engine, resolution, samples, output path, file format). This distinguishes it from write operations like set_render_settings and other getters for different scene aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use or when-not-to-use guidance. It does not mention that this tool is for reading current settings before rendering, nor does it contrast with set_render_settings or other siblings. The usage is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already informs the agent that this is a safe read operation. The description adds no additional behavioral context, such as output specifics, potential performance implications, or limitations, but it does not contradict 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and target clearly. It contains no wasted words and is appropriately sized for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, is read-only (as declared by annotations), and has an output schema, the description sufficiently covers the tool's purpose and scope. There are no missing prerequisites or preconditions that would make the description inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. According to the rubric, a baseline of 4 applies for zero-parameter tools, and the description cannot add parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'all cameras' and clarifies it includes 'their settings,' making the tool's function unambiguous. It clearly distinguishes from sibling tools like list_lights or list_objects by focusing solely on cameras.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool versus alternatives such as list_objects or get_scene_info. There are no explicit conditions, prerequisites, or exclusions, leaving usage only implied by the tool's 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 declare readOnlyHint=true, which the description aligns with. It adds minimal context by specifying 'in the blend file', but does not disclose potential nuances like hidden images or output formatting. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource. Every word is meaningful, and no filler or redundant detail is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with an output schema and annotations, the description fully covers its purpose. Nothing else is needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the description has no parameter semantics to clarify. The baseline of 4 applies because the schema is complete and no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('list') and resource ('images in the blend file'), clearly distinguishing it from sibling tools like list_lights and list_objects. The scope is explicit 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/5Does 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 instead of alternatives. It states what it does but gives no context for selection among image-related operations (e.g., load_image, pack_images) or any 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 establishes safe, read-only behavior, and the description does not contradict this. However, it adds no additional behavioral context beyond what the annotation provides, such as return format or relationship to other settings tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no waste. It is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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, output schema present, read-only annotation), the description is complete enough for selection and invocation. It says what it does, and the output schema will detail the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema covers everything trivially. The baseline of 4 applies, and the description does not need to explain parameter semantics since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available render engines' uses a specific verb and resource, clearly stating the tool's function. It distinguishes from sibling list tools like 'list_lights' and 'list_shader_node_types' by specifying the resource type 'render engines'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 context for its use case, and no exclusions. The usage is only implied by the tool name and action verb, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and explicitly discloses the key behavioral trait: it removes the object from current collections. However, it does not mention prerequisites (collection existence) or error behavior, so not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded action, concise with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter move operation, the description is mostly complete: it states action, side effect, and output schema exists. Missing details like whether the collection is created if absent or what happens if already a member, but these are edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and the tool description adds no additional meaning for 'object' or 'collection' beyond their names; the parenthetical clarifies behavior but not parameter format or ID types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') with a clear resource ('an object to a collection') and explicitly notes the side effect of removal from current collections, distinguishing it from collection visibility or creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like set_parent or create_collection; however, the description implies the use case of reassigning collection membership. Lacks exclusion criteria or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only lists action names without explaining their side effects, such as whether PAUSE preserves the current frame or whether STOP resets playback position. This lack of detail is a significant gap for a control command.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence, with no wasted words. It immediately conveys the tool's function and the distinct actions, achieving maximum clarity in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema (not shown), the description adequately covers the primary purpose. However, it lacks details about behavioral effects (e.g., does STOP rewind to frame 0?) and any prerequisites like a loaded scene. The presence of output schema reduces the need to describe return values, but the state-changing effects are still unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required 'action' parameter with zero description coverage and no enum. The description compensates by enumerating the likely valid values (PLAY, PAUSE, STOP), adding crucial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool controls animation playback and explicitly lists the actions PLAY, PAUSE, STOP. This distinguishes it from sibling tools like set_frame or set_playback_range, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for controlling animation playback without giving explicit when-to-use vs alternatives. It provides clear context by naming the three actions, but does not mention when to prefer this over related tools like clear_animation or set_playback_range.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It proactively reveals a key behavior: the actual name assigned may be auto-incremented, which is critical for users to understand. This goes beyond simple 'rename' semantics, though it does not cover error cases or edge conditions like invalid names or non-existent objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that delivers the core purpose and a key behavioral nuance with zero waste. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no nested objects), the description is mostly complete. It mentions the return value and auto-increment behavior, and the output schema provides additional structure. However, it omits potential error scenarios or prerequisites, which would be useful for a fully complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining the parameters. It does not explicitly define 'name' as the current name or 'new_name' as the desired name beyond what the parameter names imply. The description adds no semantic value to the schema, making the meaning ambiguous for new users.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename') and the resource ('object'), with a specific verb and object. It also mentions the return behavior, distinguishing it as a rename operation rather than create/delete. No sibling tool covers renaming, so it stands out clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used to rename objects, but it provides no explicit guidance on when to use it versus alternatives like duplicate_object or set_transform, nor any preconditions such as the object needing to exist. It offers clear context but no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It mentions save and save-as but does not state whether an existing file is overwritten, what happens to unsaved changes, or any success/failure 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. Every word adds value, and the structure is front-loaded around the core operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema, so return format is covered elsewhere. However, the destructive nature of saving (especially potential overwrite) is not disclosed, leaving a gap in safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds meaningful semantics to the filepath parameter by explaining it triggers save-as. This goes beyond the bare schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves the current scene, with explicit save-as behavior when a filepath is provided. This distinguishes it from siblings like load_file, import_file, and export_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for the optional filepath parameter and when save-as occurs. However, it does not explicitly mention when to prefer this tool over import/export or other file-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 idempotentHint already covers repeat-safety. The description adds the list of valid property names but does not disclose failure modes, value constraints, or whether only Principled BSDF materials are supported. That is a modest addition 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, one action and one list; every token is functional and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, but the description omits value format details for color/vector properties and how the material is addressed. It is adequate for basic scalar properties but less safe for complex ones.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 supplies the only enumeration of valid `property` values, but leaves `material` and `value` semantics vague—no per-property value shape or material identifier conventions. This is partial but not full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation (set) and the resource (Principled BSDF property), listing valid property names. This distinguishes it from sibling setter tools like set_light_property or set_world_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Set a Principled BSDF property' establishes the tool is for modifying material shader properties, and the property list clarifies intended scope. It does not explicitly contrast with siblings or state when not to use it, but the context is unmistakable.
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?
Annotation idempotentHint=true already indicates safe repeatability; description adds the behavioral detail that None resets to the default camera. No contradiction. It doesn't cover error behavior for invalid camera names, but given the annotation coverage 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the purpose and packs the essential input nuance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-optional-param tool with an output schema and idempotence annotation, the description is nearly sufficient. The only gap is not distinguishing from the similarly named sibling set_active_camera, which could cause selection ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description carries the full burden; it explains the only parameter as a camera object name and clarifies None means default. This adds genuine semantic value beyond the raw schema, though it doesn't specify exact string format/case sensitivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (set) and resource (active viewport camera), and explains the parameter semantics (camera name or None). However, since sibling tool 'set_active_camera' exists with overlapping wording, the description doesn't explicitly differentiate between viewport-active vs scene-active camera.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for setting the viewport camera and mentions the None default, but gives no explicit guidance on when to prefer this over sibling tools like set_active_camera or camera_look_at. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses an important behavioral trait: the returned name may differ if the requested name already exists (auto-renaming). However, it does not mention other side effects such as selecting the created object or adding it to the active collection, which would be useful for an unannotated mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, fully front-loaded with the core action and key details. Every sentence provides value: the type enum and the name-remapping behavior. No redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 required params) and has an output schema, which reduces the need to describe return values. The description covers the essential purpose, supported types, and name-remapping behavior. A minor gap is the lack of explanation for the 'location' parameter, but the overall completeness is adequate for a straightforward creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds semantic value by listing valid values for the 'type' parameter and implying 'name' is user-supplied and may be adjusted. However, the 'location' parameter is not explained at all (e.g., it expects an [x,y,z] array), leaving one of three parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'object', and enumerates the supported types (CUBE, SPHERE, etc.), distinguishing it from sibling create tools for materials, cameras, lights, and curves. This is a specific and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating primitive objects in the scene, with no explicit exclusions or alternatives. It provides clear context but does not name alternative tools for other object types (e.g., curves, cameras, lights). Good 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive intent, but the description adds valuable context: objects become orphaned and confirmation is required. This goes beyond the annotation and helps the agent understand the side effects and a necessary invocation condition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences with no wasted words. Each sentence contributes: the action, the consequence, and the prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the simplicity of a delete operation, the description covers the essential behavioral aspects: the destructive consequence and the need for confirmation. It does not explain what happens to sub-collections or the return value, but this is a fairly complete description 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It adds meaning for the 'confirm' parameter (required) and implicitly ties 'name' to the collection being deleted. However, it does not explicitly explain the name parameter or the exact format of confirm, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary action: 'Delete a collection.' It also distinguishes itself from other delete tools by noting the specific consequence for objects in the collection. This is a specific verb+resource pairing that leaves 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when deleting a collection) but does not explicitly mention alternatives or contrasting scenarios. It does provide a key usage prerequisite ('Confirm required'), which adds guidance, but falls short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the exact property change (use_nodes=True on the scene), which is transparent about its primary effect. However, it does not mention potential side effects, such as whether enabling the compositor creates a default node tree, or whether it is idempotent. The description is truthful but incomplete in terms of broader behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is 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 parenthetical implementation detail. Every word earns its place, with no superfluous content. It is an model of concise, clear tool documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no annotations, a clear single action), the description is largely complete for an agent to select and invoke it. It covers the purpose and the key behavior. The only missing contextual elements are explicit usage timing and potential side effects, but these are minor for such a straightforward operation. The presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description adds no parameter information, which is fine since there are none. It focuses on the action itself rather than parameter details, which is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: enabling the compositor, with a specific technical detail (use_nodes=True on scene). This is a unique action among sibling tools, which focus on compositor node operations rather than enabling the compositor itself. The verb 'enable' and resource 'compositor' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a prerequisite for compositor operations (since it enables the compositor), but does not explicitly state when to use it versus alternatives. There are no explicit when-to-use or when-not-to-use guidelines. The context of sibling compositor tools suggests the appropriate use case, but it is not directly 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?
With no annotations, the description carries the full burden. It discloses the action (framing viewport to selected) and adds the keyboard shortcut hint, but does not mention any prerequisites (e.g., selection required) or potential side effects. It is not misleading, yet it lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the action and scope. No unnecessary words; every part is purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, this description is sufficient. It covers what the tool does and connects to the standard Blender shortcut. It could mention that a selection is required, but that is strongly implied by 'selected objects'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is complete. The description does not need to add parameter semantics, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Frame' and clearly identifies the resource (viewport) and scope (selected objects). It also differentiates from the sibling tool 'frame_all' by indicating selection-specific behavior, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to frame selected objects, and the Numpad . hint reinforces that. However, it does not explicitly contrast with 'frame_all' or state when not to use it, so guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, lowering the burden on the description. The description adds the specific info fields returned, but it does not disclose error behavior or the exact return structure; the output schema covers the latter. This is adequate given 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Get' and the resource 'action', followed by three specific info fields. There is zero wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a readOnly annotation and an output schema present, the description does not need to explain return values. For a simple read tool with one parameter, it is reasonably complete. It could mention missing-action behavior, but that is a minor gap given the structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify the lone 'name' parameter. It does so by indicating 'an action' is the target, effectively mapping the string to an action name. It also hints at the returned data (frame range, channels, keyframe count), which helps parameter interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get info' and the resource 'an action', then lists specific details (frame range, channels, keyframe count). This distinguishes it from sibling tools like list_actions (which lists actions) and get_keyframes (which retrieves keyframe data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when action-level metadata is needed, but it does not explicitly mention alternatives or conditions for using this tool over siblings like list_actions or get_keyframes. Since the context is clear but exclusions are absent, it meets only the implied usage baseline.
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 annotation provides destructiveHint=true, and the description adds specific context by stating 'Destroys source objects' and 'The first object becomes the active/target.' This goes beyond the generic annotation by clarifying exactly what is destroyed and how the target is determined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core action, and contains no irrelevant information. Every sentence adds meaningful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one simple parameter and an output schema, so the description covers the essential behavior: joining geometry and destroying sources. It does not mention prerequisites like existing objects or type restrictions, but for a basic mesh operation this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (coverage 0%), so the description carries the burden. It implies 'objects' is a list of mesh objects and that ordering matters (the first is the target). However, it does not specify whether these are object names, IDs, or paths.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Join multiple mesh objects into one') and specifies the resource (mesh objects). It also notes the first object becomes the active/target, which is a specific behavioral detail. This distinguishes the tool from sibling operations like separate_mesh.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates what the tool does but does not provide explicit when-to-use or alternative guidance. It implies you should use it when you want to merge mesh objects, but no comparison with other tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation. The description adds no extra behavioral context, but this is acceptable for a trivial listing tool with an output schema; it does not contradict 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence: 'List available shader node types.' It is concise, front-loaded with the action and object, and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool with an output schema and read-only annotation, the description is largely sufficient. The only minor gap is lack of explicit usage guidance, but the function is simple enough that this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100% and there is nothing for the description to explain. The baseline score of 4 applies since no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and resource 'shader node types', clearly stating what the tool does. It distinguishes from sibling tools like create_shader_node or get_node_tree by focusing on listing types rather than manipulating nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this to discover available shader node types before creating them. However, there is no explicit guidance on when to use this versus alternative list tools like list_geonode_types or list_comp_node_types, though the distinct domains are evident from the names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It does disclose that it uses the scene output path when filepath is not specified, which is a useful fallback behavior. However, it does not mention potential side effects like overwriting files or output format, leaving gaps for a tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. It front-loads the action and follows with a succinct usage note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter and an output schema, so the description covers the essential context: what it renders and what happens when filepath is omitted. It does not discuss prerequisites like camera setup, but those are likely implied. Overall, sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description explains that a null/unspecified filepath falls back to the scene output path, adding meaningful semantics to the parameter. It does not detail filepath format or resolution, but given only one parameter, this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Render the current frame to an image file', using a specific verb and resource. It distinguishes from siblings like render_animation and render_viewport by specifying 'current frame'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like render_animation or render_viewport. The 'current frame' wording implies single-frame rendering, but no exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the idempotentHint annotation, the description adds meaningful behavioral context by specifying that the operation applies to 'all keyframes on a channel' and enumerates the valid interpolation types. This clarifies the scope and effect of the tool, which is useful for an agent. No contradiction with annotations; idempotency is consistent with setting a value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two short sentences that state the core action and list the allowed types. It is front-loaded, with no filler or redundant information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool and the presence of an output schema, the description covers the essential usage scenario. It states the action, the target (all keyframes on a channel), and acceptable interpolation values. It does not mention default behavior (though 'interpolation' schema has a default) or error cases, but for this type of setter tool, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 so for the 'interpolation' parameter by listing valid values (BEZIER, LINEAR, CONSTANT), but it does not explain 'object' or 'data_path.' The parameter names are somewhat self-explanatory, yet the description falls short of fully clarifying the required identifiers and how to construct data_path. It adds some value but not enough for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set keyframe interpolation for all keyframes on a channel.' It uses a specific verb and resource, and it distinguishes itself from sibling tools like set_keyframe and get_keyframes by focusing on interpolation rather than keyframe placement or retrieval. The addition of 'Types: BEZIER, LINEAR, CONSTANT' further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when needing to change keyframe interpolation) but does not explicitly mention alternatives or exclusions. It lacks guidance such as 'use this instead of set_keyframe for interpolation' or 'not applicable to objects without animation data.' This is adequate but not exemplary.
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 include destructiveHint=true, and the description adds the important warning 'Irreversible', which goes beyond the generic destructive flag. It also specifies the exact data types affected (keyframes and actions), providing context not present in the annotation. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero wasted words. The action is front-loaded ('Remove', not a vague phrase), and the additional 'Irreversible' is a single impactful word. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 the core purpose and a key behavioral trait. It does not explain what happens if the object is missing or how the output is structured, but given the simplicity and the presence of an output schema, this is acceptable at a high-but-not-perfect level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, 'object', of type string, with 0% description coverage. The description only repeats 'from an object' without explaining the expected format (e.g., name, path, or ID). Since the description does not compensate for the lack of schema documentation, parameter semantics are under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Remove'), a precise resource ('all animation data (keyframes, actions)'), and a scope ('from an object'). This clearly distinguishes it from sibling tools like delete_keyframe, which removes only a single keyframe, or get_keyframes, which retrieves data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: when you need to completely clear an object's animation data. It does not explicitly name alternatives or list when-not-to-use scenarios, but the context is evident from the tool purpose and the sibling list. Slightly more explicit guidance about preferring this over batch_delete or individual keyframe removal would boost the score.
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 readOnlyHint=true, and the description adds useful context by specifying exactly which aspects of the object are returned. This is consistent with a safe read operation and adds value 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the verb and object, then lists the key information categories. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter), has an output schema, and annotations. The description covers the scope of the returned info adequately; nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the single parameter 'name' is self-explanatory given the tool context. The description does not explicitly define the parameter, but the meaning is inferred from 'about an object'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('object info'), and enumerates the included fields (type, transforms, modifiers, materials, parent, collections). This clearly distinguishes it from sibling tools like get_mesh_info or get_material_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for general object-level information but does not explicitly say when to prefer this over specialized getters or provide exclusions. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, and the description reinforces this with 'Get.' The description adds value by specifying the metadata fields, but it does not disclose any additional behavioral nuances such as performance implications or whether the scene must be loaded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that enumerates the returned fields efficiently without redundant wording. Every phrase contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient given the tool has no parameters and an output schema is available to detail the return structure. The listed fields cover the essential scene metadata categories, and nothing appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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, so schema coverage is complete. With no parameters to explain, the description does not need to add semantic details, earning the baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves current scene metadata and enumerates specific fields (name, frame range, FPS, render engine, object/material counts). This distinguishes it from sibling tools like get_object_info or get_render_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the phrase 'current scene metadata,' suggesting it is for scene-wide info rather than object-specific or render-specific details. However, there is no explicit guidance on when to prefer this tool over alternatives such as get_object_info or get_render_settings.
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 is consistent with the readOnlyHint=true annotation, using 'List' which indicates a read-only operation. It adds no extra behavioral context beyond the annotation, such as whether the formats are returned with descriptions or how they are grouped. With the annotation already covering safety and an output schema present, the description does not contradict or add significant 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, 'List supported import and export file formats.' It is concise, front-loaded, and contains no extraneous information. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, a read-only annotation, and an output schema that likely details the return structure, the description is fully sufficient. It clearly states what the tool lists (supported import/export file formats) and nothing more is needed 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/5Does 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. According to the rubric, with 0 params, the baseline is 4. There are no parameter details to document, so the description doesn't need to compensate for any schema gaps. The schema coverage is effectively complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List supported import and export file formats' uses a specific verb ('List') and resource ('supported import and export file formats'). It clearly states the tool's purpose and distinguishes it from siblings like import_file/export_file, which actually perform file operations. This is a precise and unambiguous description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives or provide exclusions. However, the intended use is implicitly clear: to check which formats are available for import/export. There is no mention of alternative tools or when-not-to-use scenarios, but the simplicity of the tool makes the usage fairly obvious 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. It discloses that the operation is long-running, which is a useful behavioral warning. However, it does not explain output handling, whether it blocks, or if it modifies any files, leaving gaps in understanding 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences immediately state the purpose and a critical caveat. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and a clear scope, but the description omits details about how the render is configured (e.g., using current render settings, output path) and whether it writes files. The long-running warning is helpful, but the agent may need more context to fully anticipate side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, which deserves a baseline of 4. The description correctly says there is nothing to configure, and no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Render' with the resource 'animation' and clearly specifies the full frame range, distinguishing it from single-frame or viewport rendering seen in sibling tools like render_image and render_viewport. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates this tool is for rendering the entire animation sequence, not a single frame or viewport, but it does not explicitly state when to use it vs alternatives like render_image or render_viewport. The context is clear but lacks explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only annotation is idempotentHint: true, which the description does not contradict. The description adds a list of possible property values but does not disclose side effects, prerequisites (e.g., the object must have a particle system), or validation behavior. Since the description carries a moderate transparency burden with sparse annotations, this is a partial 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that lists the core resource and possible property values. Every word is informative, with no repetition or filler. It is front-loaded with the action and resource, and the property list is a useful summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but covers the essential scope. It does not explain what values the 'value' parameter should take for each property (e.g., units for lifetime, enumeration for emit_from), nor does it state that the target object must already have a particle system. The presence of an output schema covers return values, but the behavioral context and value semantics are still incomplete, leaving the agent to guess or probe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by naming five valid values for the 'property' parameter, which is the key parameter. It does not clarify object and system parameter meanings, but those are predictable from naming conventions. It also does not specify value formats, but the schema's type union (number/integer/boolean) provides some baseline. The explicit property list adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set' and the resource 'particle system property', and explicitly enumerates the specific properties (count, lifetime, emit_from, physics_type, size). This distinguishes it from other setter tools like set_material_property or set_light_property. The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for setting particle system properties, which is clear from the name and sibling context. It doesn't explicitly state when not to use it or name alternatives, but the strong resource specificity provides clear context. No exclusions are mentioned, so a score of 4 is appropriate rather than 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?
Beyond the destructiveHint annotation, the description explicitly states 'Irreversible' and uses the phrase 'baking it into the mesh' to convey that the operation permanently alters the mesh. This adds valuable context not present in the annotation alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with the action stated first, followed by a brief prerequisite and consequence. Every clause earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the existing output schema, and the annotations, the description covers the essential aspects: what it does, when it can be used, and that it is irreversible. No critical information is missing 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.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two string parameters (object, modifier) with no description coverage. The description does not elaborate on what these parameters should contain (e.g., names, paths, or indices), leaving the agent to infer from parameter names. This does not compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Apply') and resource ('a modifier'), and explains the effect ('baking it into the mesh'). This distinguishes it from sibling tools like remove_modifier or set_modifier_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite ('Requires Object Mode'), which informs when the tool can be used. It does not explicitly mention alternatives or when not to use it, but the context is sufficient for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With destructiveHint=true already indicating harm, the description adds the important behavioral note 'Confirm required', meaning the confirm parameter must be true to execute. This provides additional context beyond the annotation, though it doesn't detail what happens if confirm is false or confirm irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with no filler. Every word contributes to understanding the tool's core behavior and safety requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch operation with an output schema, the description covers the essential purpose and confirmation requirement. However, it omits explicit details about the no-op behavior when confirm is false, though this is inferable. Overall, adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only partially compensates: 'Confirm required' clarifies the confirm parameter's role, but the objects parameter is only implied via 'multiple objects' without explaining that it's an array of identifiers. The description adds some meaning but leaves key parameter semantics underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete multiple objects at once' clearly states the verb (delete), resource (objects), and batching scope ('multiple', 'at once'). This distinguishes it from sibling tools like delete_object, which handles single objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'multiple objects at once' conveys that this tool is for bulk deletion, implying use when deleting more than one object. However, it does not explicitly mention alternatives or when not to use it (e.g., for single object use delete_object), so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the safety profile, and the description reinforces it with 'Safe for read-only queries'. It adds the context that it executes inside Blender and returns a result, but offers no detail on error handling, restrictions, or side effects beyond what the annotation already implies. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core purpose in the first sentence and clarifying examples in the second. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only evaluation tool with an output schema, the description is sufficiently complete. It covers what the tool does, gives usage examples, and reinforces the safety annotation. It could mention error handling or that the expression must be a single Python expression, but the output schema and simple interface lower the burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's only parameter 'expression' has no description (0% coverage), so the description must explain its semantics. It does so by defining it as a Python expression and providing two concrete examples. This gives the agent actionable understanding of what constitutes a valid expression, though it doesn't fully explore edge cases like multi-statement or non-read-only usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Evaluate' with a clear resource ('a Python expression inside Blender') and states the return behavior ('return the result'). It also provides concrete examples ('len(bpy.data.objects)', 'bpy.context.mode') that clarify the scope and distinguish it from the more general execute_python sibling by emphasizing read-only queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Safe for read-only queries' gives clear context for when to use the tool, and the examples illustrate suitable use cases. However, it does not explicitly name alternatives (e.g., execute_python) 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates the tool is safe and non-destructive. The description adds the fact that it lists 'all' objects, but doesn't provide additional behavioral details such as handling of hidden objects or performance implications. This is consistent with 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the main function and optional filter. There is no unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with one optional parameter, the description covers the core behavior. The readOnlyHint and output schema cover safety and return format, so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a property named 'type' with no description, but the description clarifies its purpose: 'Optionally filter by type' and provides examples like MESH, CAMERA, LIGHT, EMPTY. This compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('List') and the resource ('all objects in the scene'), which clearly defines the tool's function. It also distinguishes from sibling tools like list_lights by noting the type filter, making it clear this is the general listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (general listing of all objects) but does not explicitly mention when not to use it or prefer alternatives like find_objects or list_lights. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, so the description's value lies in explaining the parameter semantics (smooth/auto_smooth/angle). It adds context about the angle unit (radians) and the relationship between modes, going beyond the schema. No contradictions 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action. Each sentence adds essential info: the action, the mode flags, and the auto_smooth behavior. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 (not shown but noted in context), the description fully covers the input semantics. It does not explain edge cases like simultaneous smooth+auto_smooth, but for a simple setter this is adequate. The required parameter is implied by the tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining 'smooth' (true/false meaning), 'auto_smooth' (angle threshold), and 'angle' (radians). The 'object' parameter is self-evident from context, so no explicit explanation is needed. This adds meaningful semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('shading mode'), clearly distinguishing it from sibling tools like set_viewport_shading. It immediately clarifies the three modes (smooth, flat, auto_smooth) with parameter mappings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you want to change object shading) but does not explicitly state alternatives or exclusions. For example, it does not mention set_viewport_shading for viewport-level shading, leaving room for ambiguity.
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 adds a specific behavioral consequence beyond the destructiveHint annotation: 'Loses curve editability' explicitly states what is destroyed. This is valuable context, and it aligns with the annotation (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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and result. Every word earns its place; no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 and destructiveHint annotation, the description is adequate. It covers the core behavior and a key consequence, though it could hint at object identification format or failure conditions for non-curve objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the 'object' parameter beyond implying it is the curve object. It lacks details about how to specify the object (name, path, etc.), leaving a significant gap for a parameter with no schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Convert a curve object to a mesh.' It names both the input type (curve) and output (mesh), distinguishing it from sibling tools like create_curve or get_mesh_info. The consequence 'Loses curve editability' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage when a mesh representation is needed from a curve, and the warning about losing editability indicates a caution against converting if curve editing is still required. However, no explicit alternatives or when-not-to-use guidance are provided, so it's not 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?
With no annotations, the description provides a clear behavioral statement: it adjusts the viewport to fit all objects. This is transparent and sufficient for a simple view operation, though it does not detail side effects or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and scope. It earns its place with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the empty input schema, and the presence of an output schema, the description fully covers the functionality. It is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no burden on the description to explain parameter meaning. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Frame') and resource ('viewport') with a clear scope ('all objects'). It naturally distinguishes from the sibling tool frame_selected by stating 'all objects' as opposed to selected ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this to view all objects in the viewport. However, it does not explicitly mention when not to use it or contrast with alternatives like frame_selected, so the guidance is minimal.
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 readOnlyHint=true, and the description adds valuable behavioral context by enumerating the specific settings returned (shading mode, overlays, camera, clip distances). It does not contradict annotations and provides insight into the tool's read-only output scope. However, it does not describe return format or edge cases, which is acceptable given the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. Every word contributes value, and it avoids redundancy with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple getter with no parameters and an output schema. The description fully captures the tool's purpose and scope by naming the primary settings returned. Given the low complexity, no further details are needed for the agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description adds semantic meaning by listing the settings that will be returned, even though no parameter explanations are needed. It does not repeat schema info since there is nothing in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource as 'viewport settings' with concrete examples (shading mode, overlays, camera, clip distances). This distinguishes it from sibling setter tools like set_viewport_shading and set_viewport_camera, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use this tool versus alternatives. The getter vs setter distinction is implied by the verb 'Get' and sibling names, but there is no explicit statement about when to choose this over get_scene_info or capture_viewport. Usage context is only implied, not directly stated.
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 a safe read operation. The description adds minimal behavioral context beyond that—only the word 'available' hints at context-dependent results. There are no side effects or prerequisites disclosed, but the tool is trivial and the annotation covers the main safety concern.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose without unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with an output schema, the description is complete. It clearly identifies the scope (compositor) and the action (list), requiring no additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty. The baseline for 0-parameter tools is 4, and there is no need for parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available compositor node types' clearly states the verb (list) and the resource (compositor node types), distinguishing it from sibling tools like list_shader_node_types and list_geonode_types by specifying 'compositor'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying 'compositor' node types, implying it should be used when compositor node types are needed. It does not explicitly mention alternatives or exclusions, but the context is sufficiently clear for a simple list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint annotation, confirming a safe read operation. It adds the behavioral detail that results include type and settings, which is useful. However, it does not mention edge cases, return format, or filtering behavior, leaving some gaps despite 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that fully communicates the tool's function without any unnecessary words. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only list operation with no parameters and an existing output schema, this description is complete. It states what the tool does and what information it returns, so the agent can invoke it correctly without further detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the rubric the baseline is 4. The description appropriately does not attempt to explain parameters, as there are none to configure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' and identifies the exact resource ('all lights in the scene') with details about the output ('type and settings'). This clearly distinguishes it from sibling tools like list_objects, which targets all objects rather than lights specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool—whenever you need an inventory of lights—and the phrase 'all lights' provides clear context. However, it does not explicitly mention alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds that it returns version info, which is useful. However, it does not disclose failure modes or latency expectations. With the annotation present, the description provides moderate additional 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that conveys the essential purpose without excess. Front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters), the presence of an output schema, and read-only annotation, the description is fully adequate. It tells the user exactly what to expect: reachability and version info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%, so the description has no need to explain parameters. Baseline for 0 params is 4, and the description appropriately focuses on behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Check') and resource ('Blender addon') and distinguishes this tool from siblings as a connectivity/version check. It uniquely identifies the tool's purpose among the many 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a preliminary health check before other operations, but does not explicitly state when to use or not use it relative to alternatives. Clear context though no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The idempotentHint annotation already signals that setting is safe to repeat, and the description adds the valid mode values, which are not present in the schema. It does not contradict the annotation. Some context about it being a display-only change is implied rather than explicit, but the added value is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the action, target, and complete value set with zero filler. Every word contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter setter with an idempotency annotation and an output schema, the description is sufficient. It does not explain subtle differences between the modes (e.g., that RENDERED may use the render engine), but for a typical Blender user these are well-understood, and the tool's simplicity keeps the omission minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description or enum for the 'mode' parameter (0% coverage), yet the description fully compensates by listing all accepted values: WIREFRAME, SOLID, MATERIAL, RENDERED. This is exactly the semantic enrichment needed for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('viewport shading mode'), immediately distinguishing it from sibling viewport tools like capture_viewport, set_viewport_camera, and get_viewport_info. It also enumerates the valid modes, making the tool's function 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool—when you need to change the viewport's shading mode. It does not explicitly state when not to use it or mention alternatives (e.g., set_smooth_shading for normals), but the specificity is enough to infer its niche.
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 provide destructiveHint=true, and the description adds valuable context: 'Dangerous patterns are blocked by default' and 'Confirm required.' This discloses safety mechanisms and the need for confirmation beyond the annotation, though it does not detail what constitutes 'dangerous patterns' or post-confirmation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the core purpose, followed by usage and safety notes. No wasted words, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic execution tool, the description covers purpose, when to use, and safety. An output schema is present, so return value details are not needed. It could mention execution limitations or environment specifics, but overall it provides a solid context for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for parameters. The description implies the 'confirm' parameter via 'Confirm required' and the 'code' parameter is self-evident from the tool's name, but it does not explicitly document parameter usage or formats. This partially compensates but leaves room for more explicit parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute Python code inside Blender' with a specific verb and resource. It distinguishes itself from the many dedicated sibling tools by explicitly framing itself as a fallback ('Use this only when no dedicated tool exists').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use this only when no dedicated tool exists for the operation.' This tells the agent exactly when to prefer this tool over alternatives. It also mentions 'Confirm required,' indicating a required confirmation step.
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 establishes safety, and the description adds value by disclosing the specific output fields (child counts, object counts, visibility). It does not describe ordering or pagination, but the output schema likely covers return structure, and for a zero-parameter read-only tool this is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the action, target, and key return data without any redundant words or filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation with a readOnlyHint and an output schema, the description provides all essential information: listing all collections and the specific data returned. There is no additional complexity that would require more explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to explain any. The schema coverage is 100% with an empty properties object, and the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('collections'), and explicitly enumerates the returned attributes (child counts, object counts, visibility). It clearly distinguishes this from sibling tools like list_objects or list_materials by focusing on collections and their metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'List all collections' clearly indicates when to use this tool—whenever a full inventory of collections with counts and visibility is needed. Although no explicit alternatives or exclusion criteria are stated, the context is unambiguous and no conflicting tool exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a safe read operation, and the description adds the context that the list depends on the current Blender version, which is useful behavioral information not provided by annotations. No contradiction 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loaded with the action and subject ('List available geometry node types'), with no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool, the description is sufficiently complete: it states what is listed (geometry node types), the version dependence, and the output schema will provide the structure. It also differentiates from sibling node type listers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description doesn't need to explain parameter meaning. With a 100% schema coverage (vacuous due to zero parameters) and no parameters to document, this is straightforward and meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and the resource 'available geometry node types', clearly distinguishing it from sibling tools like list_shader_node_types and list_comp_node_types. The scope is precise: it lists geometry node types for the current Blender version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving geometry node type listings, with the qualifier 'for the current Blender version' indicating version-dependent results. It does not explicitly state when to prefer this over list_shader_node_types or list_comp_node_types, but the resource name makes the distinction evident, providing clear context without formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety, and the description adds value by specifying the return content ('with user counts'). This provides context beyond the annotation, though it doesn't detail any other behavioral traits like ordering or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys all necessary information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, a readOnlyHint annotation, and an output schema available, the description is complete for this simple listing operation. It states the scope and the included user counts, leaving no critical gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not expected to explain parameter details. The baseline for 0 params is 4, and the description does not add conflicting or redundant information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List'), resource ('materials'), scope ('all in the blend file'), and an added detail ('with user counts'). This distinguishes it from siblings like get_material_info, which targets a specific material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is for listing all materials, not for querying a single material (as get_material_info would). However, it does not explicitly mention alternatives or exclusions, so it misses the top score for explicit guidance.
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 destructiveHint annotation, the description discloses the exact destructive effect ('replaces the current scene') and the need for confirmation ('confirm to proceed'). This adds significant behavioral context that helps the agent understand the consequences, exceeding what annotations alone 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence followed by a succinct warning. Every word earns its place, with no redundancy or filler. It is optimally concise while conveying the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive load operation, the description covers the action, the destructive consequence, and the confirmation gate. The presence of an output schema covers return values. Given the tool's modest complexity and the supporting annotations, the description is complete enough without further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds meaning for the 'confirm' parameter by explaining its role in proceeding with the destructive action, but it provides no additional detail for 'filepath' beyond the implicit path concept from the action. This is partial compensation but leaves filepath semantics to the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Load a .blend file.' It distinguishes from siblings like import_file and save_file by specifying the .blend format and action. This is unambiguous and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that loading replaces the current scene, implying a destructive operation. It doesn't explicitly mention exclusions or alternatives, but the context is sufficient for most agents to decide when to use it. The alternative tools (import_file, save_file) are not contrasted, but the .blend-specific phrasing naturally differentiates them.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/kleer001/blender-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server