blender-studio-pro-mcp

by cristoferarango

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation2/5
Several tools overlap significantly: call_operator and execute_python can perform the work of many dedicated commands, create_object overlaps with create_camera/create_light/create_curve, and frame_selected vs frame_selected_objects are nearly identical names for different operations. With 223 tools, an agent will frequently struggle to select the correct one.
Naming Consistency4/5
The overwhelming majority of tools follow a clear lower_snake_case verb_noun pattern, with create/add/set/list used fairly consistently. Minor inconsistencies like gn vs geometry_nodes, gp vs grease_pencil, and a few standalone verbs like undo/redo prevent a perfect score.
Tool Count1/5
At 223 tools, this is far beyond the heavy threshold and includes both a complete bpy.ops bridge and extensive dedicated high-level commands, creating massive redundancy. This extreme count makes the server unnecessarily difficult to navigate.
Completeness5/5
The server covers nearly every Blender domain--modeling, materials, animation, physics, rendering, geometry nodes, sequencer, and more--while also exposing call_operator, execute_python, and set_attr_path as universal escape hatches. There are no obvious dead ends in the tool surface.
Average 2.2/5 across 223 of 223 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses nothing: no mention of the mutating nature of beveling, selection requirements, or side effects. The agent is left with no understanding of what calling this tool actually does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, this is under-specification rather than conciseness. There is no meaningful content, no front-loading of key information, and no value beyond restating the tool name. Every sentence (the one sentence) fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Bevel is a mesh operation with substantial complexity (affecting geometry, requiring selection, producing new geometry). With no description, no annotations, and no parameter documentation, the tool is completely inadequate for an agent to call it correctly. The presence of an output schema does not help since its content is unknown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for the 'offset' and 'segments' parameters. The description does not compensate for the lack of schema documentation; it does not even mention the parameters exist. An agent cannot infer what values are appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just 'Blender Studio Pro MCP: bevel' which simply repeats the tool name with a prefix. It does not state what the tool does, what resource it operates on, or any distinguishing purpose. This is a tautology, failing to convey the operation of beveling in Blender.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use or avoid this tool. It does not mention context, prerequisites, or alternatives, despite many sibling tools like 'subdivide' or 'extrude_region' that might be related. The description is entirely silent on usage conditions.
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 information. It does not disclose side effects (e.g., whether original objects are deleted), the nature of the conversion, required permissions, or any error conditions. The description is effectively empty in this dimension.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, this is under-specification rather than concise writing. It lacks any useful content and does not front-load any actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, no details are provided about what the tool returns or how it behaves. For a conversion tool, the description fails to mention what object types can be converted, what happens to the original, or any other context needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and one required parameter, object_name, the description adds no meaning. It does not explain what object_name refers to (e.g., name of an existing curve, text, or other object) or what constraints apply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Blender Studio Pro MCP: convert_to_mesh' is a tautology that merely restates the tool name. It does not specify what object type is being converted, what 'mesh' means in this context, or how this differs from other conversion/creation operations in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description offers no context about prerequisites, situations where conversion is appropriate, or which sibling tools might be more suitable for specific conversion needs.
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 of behavioral disclosure. It offers none—no mention of what the tool does, what it returns, side effects, or any preconditions in Blender. The description is merely the name, giving zero behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not conciseness. The single sentence merely restates the tool name and provides no value. It does not earn its place; it could be removed without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool creates a text object with multiple parameters and has an output schema (contents unknown), the description is wholly inadequate. It provides no context about the effect, usage, or returned data. An agent would be completely in the dark.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema does not explain parameters. The description also provides no explanation for the five parameters (body, name, size, extrude, location). An agent cannot infer what these parameters mean or how they affect the text object from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: create_text', which is essentially a restatement of the tool name with a prefix. It does not state what the tool does—no verb, no resource, no action beyond the implied 'create text' in the name. This is a tautology and fails to distinguish it from siblings like set_text_body or create_curve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of scenarios where creating a text object is appropriate, or when to use set_text_body instead. The description provides 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses nothing about side effects, read-only behavior, potential errors, or return format. The description is entirely devoid of 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.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is not conciseness – it is under-specification. A useful description would at least state the tool's function. This text is just a label and provides no useful structure or front-loaded information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the tool name and the context of many sibling tools, this description is completely inadequate. An agent cannot infer the tool's purpose, inputs, outputs, or behavior, and the output schema is not provided in the visible definition. Nothing about the tool's role is conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While there are zero parameters (so the schema is trivially complete), the description adds no semantic value. It does not explain what the tool does, what data it returns, or how it relates to the world context. Since the description is the only source of guidance beyond the empty schema, its failure makes it inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is merely 'Blender Studio Pro MCP: get_world_info', which is a prefixed tool name rather than a statement of purpose. It does not specify a verb, resource, or what information about the world is retrieved, and it fails to distinguish itself from sibling tools like set_world_background or get_scene_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no context about typical use cases, and no mention of prerequisites or constraints. The description gives an agent no basis for deciding between get_world_info and other world-related 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 provided, the description carries the full burden of behavioral disclosure. It hides whether the operation is read-only, what side effects it might have, and what the return value is. The description adds zero behavioral information beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the text is short, it is under-specified rather than concise. The single sentence 'Blender Studio Pro MCP: list_gp_layers' carries no meaningful content and wastes the opportunity to provide any useful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has one parameter, a non-trivial function (listing grease pencil layers), and no annotations. The description provides nothing to help an agent understand what the tool does, when to call it, or what it returns. It is completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'object_name' is undocumented in the schema and not mentioned in the description. With schema description coverage at 0%, the description provides no clue about the expected format, meaning, or purpose of this parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a repetition of the tool name with a prefix. It does not state what is being listed, what 'GP' stands for (grease pencil), or what the tool accomplishes. There is no verb or resource specificity—it is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While sibling tools like add_gp_layer and set_gp_stroke_settings exist, the description does not mention any 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 provided, the description carries the full burden of behavioral disclosure. It does not indicate that this is a mutation operation, whether it requires existing nodes, side effects (e.g., overwriting values), or error conditions. The name suggests setting an input, but no behavioral specifics are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that repeats the tool name. This is severe under-specification, not conciseness. No valuable content is present to earn its place; it conveys no information beyond the identifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that sets a compositor node input, an agent needs to know how to identify the node, what input names are allowed, and what value formats are valid. None of this is provided. The lack of any operational context makes this tool nearly uncallable without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters (node_name, input_name, value) with 0% description coverage. The description adds no meaning to these parameters. It fails to explain what node_name references, what input names are valid, what value types are accepted, or how they relate. The description provides zero assistance in understanding the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: set_compositor_node_input', which is merely the tool name prefixed with 'Blender Studio Pro MCP:'. It states no verb, resource, or scope beyond what the name implies. This is a tautology and provides no additional clarity for distinguishing it from siblings like get_compositor_tree or add_compositor_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., an existing compositor node), interactions with get_compositor_tree or connect_compositor_nodes, or condition exclusions. The description offers no usage context whatsoever.
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 carries zero behavioral disclosure. The tool name suggests setting text body text, but there is no mention of side effects, permissions, undo behavior, or return values. The description does not contradict annotations (none exist), but it adds nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the text is short, it is not concise—it is under-specified. The description is just a prefixed name with no explanatory content. This does not qualify as effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters and no schema descriptions, annotations, or output schema information, the definition is completely inadequate. The agent cannot determine what the tool does, how to call it correctly, or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the parameters 'body' and 'object_name' have no descriptions. The tool description itself does not explain these parameters, so the agent gets no semantic guidance beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is exactly 'Blender Studio Pro MCP: set_text_body', which merely restates the tool name with a prefix. It provides no verb, resource, or action detail, so the agent cannot infer what the tool does. This is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is given about when to use this tool versus any of the many siblings (like set_attr_path, set_shape_key_value, etc.). 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.
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 provides zero information about what the tool does, any side effects, required context, or return behavior. Nothing is revealed beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which keeps it concise, but it is under-specified rather than concisely informative. It is a single line that repeats the name, providing no useful content. This is not effective conciseness but rather a placeholder.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no annotations or schema descriptions, the description is completely inadequate. An agent cannot determine the tool's purpose, how to use it, or what the object_name parameter refers to. Even with an output schema existing, the description fails to provide essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines one required parameter 'object_name' with no type or description, and schema description coverage is 0%. The description adds no meaning to this parameter; it does not indicate that it names the target object or any expected format. The description fails to compensate for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: add_cloth' which merely repeats the tool name with a prefix. It does not state what the tool does, such as adding a cloth simulation to an object. It is a tautology and does not distinguish from sibling tools like add_soft_body or add_rigid_body.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description gives no context about typical use cases, prerequisites, or conditions for selecting this tool over other physics simulation 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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. However, the description provides no information about side effects, required Blender state, return values, or whether it mutates the scene. The agent is left with no behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not good conciseness. It is a single fragment that repeats the tool name. Every sentence should earn its place, but here there is not even a full sentence; no valuable information is conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema present, the description is entirely inadequate. For a tool with one required parameter and no annotations, the definition fails to explain the tool's purpose, usage, or parameter semantics. The agent has no idea what 'add_collision' does, how to invoke it, or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists a single required parameter 'object_name' with no description, and schema description coverage is 0%. The description adds nothing about the parameter—what it refers to, its format, or its role. The agent has no way to construct a valid invocation beyond guessing the parameter is the name of a Blender object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: add_collision' which is essentially the tool name with a prefix, a tautology. It does not state any verb, resource, or scope beyond the name. There is no indication what 'collision' refers to in Blender (e.g., physics collision objects, collision shapes). It fails to distinguish the tool from any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or when not to. No alternatives are mentioned, and no context or prerequisites are provided. The description gives the agent zero basis to decide between this and any related tool.
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 does not mention whether the tool creates, modifies, or deletes anything, what side effects occur, or what the output schema contains. The description is essentially empty of behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It contains only a parameter name and two values, with no structure or elaboration. While it is brief, it does not earn its place because it provides almost no useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters (one required) and an output schema, this description is grossly inadequate. It does not explain the tool's function, the expected input values, or the output. An agent cannot safely or correctly invoke this tool based on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It does mention 'domain_type: GAS, LIQUID.' which hints at possible values, but it doesn't explain what domain_type means, what object_name is, or how they relate. The description adds only a fragment of parameter meaning and fails to make the tool callable correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'domain_type: GAS, LIQUID.' does not state what the tool does. It only lists possible values for a parameter. There is no verb, no resource, and no indication that this adds a fluid domain to an object. It fails to convey the tool's purpose entirely, making it a pure fragment rather than a description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool or how it relates to alternatives. No context, no exclusions, no mention of prerequisites or conditions. An agent has no basis for selecting this tool over its siblings.
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 of disclosing behavior. It fails to mention what the tool does (e.g., adds a fluid flow to an object), what side effects occur, or what the output represents. The description is entirely non-behavioral, consisting only of enum-like values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which technically is concise, but it is under-specified rather than efficiently structured. It fails to front-load any purpose or context. A concise description should still convey meaning; this is a fragment that reads like an unfinished thought.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description is fundamentally incomplete for a tool that presumably performs an action in a 3D scene. It does not explain what the tool does, what the object_name parameter is for, or how flow_type affects the result. An agent cannot correctly invoke this tool based on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides partial semantics for flow_type by listing example values, but it completely omits object_name, which is the required parameter. The description does not explain what 'object_name' refers to or how it interacts with flow_type, leaving a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a single line listing possible values for flow_type ('SMOKE, FIRE, LIQUID, etc.'). It does not state a verb or resource, nor what 'add_fluid_flow' accomplishes. It reads as a truncated parameter hint rather than a description of the tool's purpose, making it nearly a tautology of the parameter name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about scenarios, prerequisites, or comparisons with sibling tools like add_fluid_domain or add_force_field. The agent is left completely without direction on 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 must carry the full burden of disclosing side effects, required permissions, or state changes. It offers nothing—just the name—so the agent cannot infer whether this tool mutates data, requires specific object types, or has any safety implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It consists solely of the tool name and a prefix, which is useless to an agent. Slight credit for not being verbose, but it lacks any substantive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description provides no context about what the tool does, its inputs, or its expected behavior. For a tool that likely adds a layer to a grease pencil object, the description is entirely inadequate for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% and the two parameters (layer_name and object_name) are not explained in the description. The description adds no meaning beyond the parameter names, failing to specify what these parameters do, their expected formats, or how they relate to each other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Blender Studio Pro MCP: add_gp_layer' is essentially the tool name with a generic prefix, providing no verb, resource, or action detail. It is a tautology that fails to state what the tool does, making it indistinguishable from other similar tools like list_gp_layers or set_gp_stroke_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus its siblings. The description does not mention prerequisites, alternatives, or any context that would help an agent decide between add_gp_layer and related grease pencil commands.
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 reveals nothing about side effects, permissions, return values, or how the operation affects the Blender scene. The text adds no behavioral detail beyond the name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the text is extremely short, this is under-specification rather than conciseness. The single sentence is just a label and does not earn its place by adding value. It is not structured or front-loaded with useful content; it is essentially a redundant prefix attached to the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no annotations, and no schema descriptions, the description is grossly inadequate. An agent has no way to know how to call it correctly, what an image strip is in this context, or what the output schema will contain. The description fails to provide any of the necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter information. The five parameters (name, channel, filepath, frame_start, frame_duration) are left entirely to the agent to interpret from names, with no explanation of expected formats or meanings. The description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: 'Blender Studio Pro MCP: add_image_strip' merely restates the tool name with a category prefix. It does not explain what adding an image strip does, nor does it distinguish it from sibling tools like add_movie_strip or add_sound_strip. An agent would have no clue from this text what the tool actually accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description contains no context, no prerequisites, no mention of sequencer usage, and no exclusions. It is impossible to infer appropriate usage scenarios from this definition.
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 reveals nothing about side effects, required permissions, or behavior (e.g., whether it adds a marker to the current frame, requires an active scene, etc.). The description is entirely uninformative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It provides no useful information, so its brevity does not help. It earns a 2 because it is technically concise but fails to convey anything meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema details, and incomplete parameter information, the description is completely inadequate for an agent to successfully call this tool. An agent would have no idea what 'add_marker' does or how to fill in the required 'name' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the input schema shows parameters 'name' and 'frame' with no explanations. The description does not add any meaning to these parameters, leaving the agent with no idea what values to provide or their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is simply 'Blender Studio Pro MCP: add_marker', which restates the tool name without any verb or resource detail. It fails to state what the tool actually does, such as adding a marker in Blender, and does not distinguish it from sibling tools like list_markers or remove_marker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no context about prerequisites, and no mention of related operations like removing or listing markers. The description provides zero usage direction.
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 of behavioral disclosure. It discloses nothing about side effects, required context (e.g., a sequencer must exist), or return behavior. The tool likely modifies the scene but no such information 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is extremely short, but this is under-specification rather than conciseness. There is no useful content; the single sentence merely restates the tool name. It could be considered inefficient because it wastes the opportunity to convey actual information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that likely modifies the scene by adding a strip, with no annotations, no parameter descriptions, and no indication of return values, the description is completely inadequate. Even with an output schema present, the agent lacks the essential input semantics and behavioral expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% – none of the parameters (name, channel, filepath, frame_start) have descriptions in the schema. The description does not compensate by explaining what these parameters mean or how they relate to adding a movie strip. An agent cannot correctly construct a call without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: add_movie_strip' – essentially repeating the tool name with a product prefix. It fails to state what the tool does. An agent cannot determine that this adds a movie strip to the VSE (Video Sequence Editor) or how it differs from siblings like add_image_strip or add_sound_strip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description provides no context about typical use cases, prerequisites, or conditions that would differentiate it from similar sequencing tools like add_image_strip or add_sound_strip.
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 (readOnlyHint, destructiveHint, etc.), so the description carries the full burden of disclosing behavioral traits. It reveals nothing: no hint that this creates/modifies shape keys, no information on side effects, permissions, or reversibility. The word 'add' implies creation but no specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line), but this is under-specification, not conciseness. It does not front-load any useful information; it simply repeats the tool name. While not verbose, it fails to earn its place by providing any actionable content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no annotations, the description provides virtually nothing an agent needs to invoke it correctly. There is no mention of the required parameter 'object_name', default behaviors, or return format, making the description completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%—neither the description nor the property definitions explain the meaning of 'name', 'from_mix', or 'object_name'. The description adds zero value beyond the schema field names, and with no parameter explanations, an agent cannot infer semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: add_shape_key', which is merely the tool name prefixed with a product label. It does not state a verb, resource, or any action semantics. It is a tautology—restating the name without explaining what the operation does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus any of the sibling tools (e.g., list_shape_keys, set_shape_key_value, remove_shape_key). No context, prerequisites, or alternative selection criteria 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 behavioral traits. It says nothing about side effects, required context, or what happens when called. The name implies adding a soft body, but the description does not confirm or elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It contains only the tool name, which is not a useful definition. No meaningful content is provided beyond the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no annotations, the description still fails to provide essential context. It does not explain what a soft body is, when to add one, or what the tool's effect is. The completely bare description is inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter, object_name, and schema description coverage is 0%. The description does not explain what object_name refers to, what values it accepts, or how it should be used. No semantic context is added beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: add_soft_body', which simply repeats the tool name with a prefix. It does not state the verb, resource, or effect of the tool. This is a pure tautology, providing zero information about 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 Guidelines1/5
Does 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 any alternative. There is no mention of context, prerequisites, or exclusions. The description offers no decision support for the agent.
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 must carry the full burden of behavioral disclosure. It discloses nothing – no side effects, required permissions, or operational details. This is completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but not effectively concise – the single sentence adds zero informational value. It is under-specification rather than deliberate conciseness, so it fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that adds a sound strip in a sequencer context, the agent needs to know file types, channel behavior, and how it differs from movie/image strips. None of that is provided. The description is entirely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of filepath, name, channel, or frame_start. The parameters remain entirely undocumented beyond their names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology – 'Blender Studio Pro MCP: add_sound_strip' merely restates the tool name and product prefix. It does not state a verb, resource, or any functional content, so an agent cannot infer 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like add_movie_strip or add_image_strip. There is no context about usage scenarios, 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 exist, so the description must carry the burden of behavioral disclosure. It says nothing about side effects, required state (e.g., compositor must exist), or what happens on execution. The agent has no idea what 'connect_compositor_nodes' does 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but it is under-specified rather than appropriately concise. It lacks any substance that would earn its place. No structure or front-loading of useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a node-connection operation with four required parameters, no annotations, and no output schema documentation, this description is woefully incomplete. It does not explain the return value, node/socket syntax, or any operational requirements. The agent cannot reliably call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description provides no parameter information. The parameter names are self-explanatory (from_node, from_socket, etc.), but the description adds zero semantics about their types, formats, or relationships. The agent cannot infer how to specify sockets or nodes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is exactly the tool name prefixed with 'Blender Studio Pro MCP:', which is a tautology. It restates the name without explaining the action or resource, and fails to differentiate from sibling connect tools like connect_shader_nodes or connect_gn_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like connect_shader_nodes or connect_gn_nodes. No context, prerequisites, or exclusions 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 carries the full burden of behavioral disclosure. It fails to mention that this is a destructive operation, whether it unlinks objects, or any other behavioral details. The description is empty of any behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. The single phrase contains no useful information and fails to leverage available space for semantic content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with an output schema and two parameters, the description is completely inadequate. It provides no context about the operation's effects, parameter usage, or return value, making it impossible for an agent to call it correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description adds no meaning to the parameters 'name' or 'do_unlink_objects'. It doesn't explain what these parameters do, their impact, or their defaults, leaving the agent completely in the dark.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just 'Blender Studio Pro MCP: delete_collection' which restates the tool name with a product prefix. It provides no verb, resource, or scope information, making it a tautology that fails to convey what the tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like list_collections, set_collection_visibility, or move_to_collection. The description offers zero context about appropriate usage 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?
The description offers no insight into what 'ensure_compositor' does—whether it creates, validates, or modifies something. With no annotations provided, the description carries the full burden of behavioral disclosure and fails entirely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but it is a case of under-specification rather than efficiency. A single line repeating the tool name is not useful to an agent; it fails to convey any operational detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, annotations, or behavioral description, the description is completely inadequate. An agent cannot infer when or how to invoke this tool correctly, especially given the large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the tool has zero parameters, the description adds no value about the operation or what 'ensuring' means. It does not clarify what happens when called, so the parameter-free schema remains unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology—it merely repeats the tool name with a namespace prefix ('Blender Studio Pro MCP: ensure_compositor'). It does not state a clear verb, resource, or intended action, nor does it distinguish this tool from the many compositor-related siblings (e.g., get_compositor_tree, add_compositor_node).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, what triggers its need, or how it relates to similar compositor operations. There is no mention of prerequisites, alternatives, or expected conditions.
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 reveals nothing about behavior, side effects, or internal semantics. The agent has zero knowledge of what 'ensure' does (e.g., whether it creates a world if missing, modifies existing, or returns a reference).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but this is under-specification rather than conciseness. It fails to provide any meaningful content, so brevity here is not a virtue — it is an absence of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter and no schema descriptions, the description is entirely inadequate. An agent cannot determine what the tool does, when to invoke it, or what parameters to pass correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds nothing about the 'name' parameter. Even the default 'World' is not explained. The agent cannot infer what the parameter controls or its allowed formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is simply 'Blender Studio Pro MCP: ensure_world' — a prefix plus the tool name, with no verb or resource stated. It is a tautology that restates the name and conveys no actual purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like create_world or get_world_info. No context, prerequisites, or conditions for selection 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, and the description provides no behavioral information. An agent has no idea what entering sculpt mode entails, whether it requires a mesh selection, or what side effects occur (e.g., mode change). The description carries the full burden and fails completely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than good conciseness. It has no front-loaded substance and every word is recycled from the tool name, so it fails to earn its presence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no annotations, the description should explain the purpose and parameter semantics. It provides none. Although an output schema exists, that does not compensate for the missing description of the tool's action and prerequisites. The overall definition is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines one required parameter 'object_name' with no description or type. Schema description coverage is 0%, and the tool description adds nothing beyond the parameter name. The agent gets no help understanding what object_name should be or how it is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: enter_sculpt_mode', which merely restates the tool name with a product prefix. It contains no verb, resource, or differentiation from sibling tools like enter_edit_mode or set_mode. This is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as enter_edit_mode or set_mode. The description offers zero contextual hints about intended scenarios.
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 annotations absent, the description bears the full responsibility for disclosing behavioral traits. It offers none — no mention of what happens when entering texture paint mode, any state changes, side effects, or requirements. The description is a bare name and provides zero transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. The single sentence merely restates the tool name and offers no operational value. It is not that every sentence earns its place; it is that no useful sentence exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that switches an object's mode, the description should explain the effect, any prerequisites, and the expected result. Even though an output schema exists, it is not described, and the description gives the agent nothing to work with. The complete absence of contextual guidance makes the tool impossible to invoke correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single required parameter object_name with no description, and schema description coverage is 0%. The description adds no information about what object_name represents, its format, or its meaning. For a required parameter, this is a complete failure to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Blender Studio Pro MCP: enter_texture_paint' is nothing more than a label that repeats the tool name. It does not state what the tool does, what resource it affects, or how it differs from sibling mode tools like enter_vertex_paint or set_mode. There is no verb, no object, and no scope — the agent must guess the function entirely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description contains no context about when entering texture paint mode is appropriate, nor does it mention any preconditions or competing tools such as set_mode or enter_vertex_paint. An agent has no basis for choosing this tool.
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 of behavioral disclosure. It says nothing about entering vertex paint mode, whether it requires a mesh object, how it affects the current mode, or what happens on failure. The description provides no useful behavioral information beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is technically short, but this is under-specification rather than conciseness. It consists of a single tautological phrase that carries no informational value, so it fails to earn even the minimal score for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, suggesting it returns some result, but the description says nothing about the return value or the actual operation. For a one-parameter mode-switching tool, the description is completely inadequate – an agent has no clue what invoking it does or what response to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, object_name, with no description (0% coverage). The tool description adds nothing about that parameter – no indication of what object_name should be (e.g., a mesh object? name vs. data name?) or how it is used. The agent is left without any semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: 'Blender Studio Pro MCP: enter_vertex_paint' merely restates the tool name with a prefix. It does not state what the tool does (enter vertex paint mode on an object) or distinguish it from sibling tools like enter_edit_mode, enter_weight_paint, or enter_texture_paint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The sibling list includes several mode-entering tools (enter_edit_mode, enter_sculpt_mode, enter_weight_paint, enter_texture_paint), but the description provides no context to help an agent choose among them.
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 present, so the description must disclose all behavioral traits. It says nothing about side effects, required object state, mode switching, or any other effects. The tool name implies a mode change, but no details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is not concise in a meaningful way—it is under-specified. While it is 'brief', it fails to convey any useful information beyond the tool name, so it does not earn credit for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no documentation, this description is completely inadequate. There is no mention of return values, error conditions, or any operational context. An agent cannot confidently call this tool based on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'object_name' has no type or description in the schema, and schema coverage is 0%. The description provides no explanation of what this parameter represents or how it should be used, leaving the agent entirely without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely repeats the tool name ('Blender Studio Pro MCP: enter_weight_paint') with no verb or resource indicating what the tool does. It is a pure tautology and does not state that it enters weight paint mode or any other function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like enter_edit_mode, enter_sculpt_mode, enter_vertex_paint, etc. There is no mention of prerequisites, context, or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 gives no indication that this operation likely modifies a mesh (e.g., extrudes faces or edges), what happens to existing geometry, whether it is destructive, or what the output will be. The description is essentially empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. There is no useful structure or front-loaded information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mesh-editing operation in a complex 3D tool, this description is completely inadequate. It lacks any explanation of prerequisites, effect, parameter meaning, or return value, and no annotations or rich output schema compensate for the absence of information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single 'value' parameter with a default but no description, and schema description coverage is 0%. The description does not explain what 'value' means (e.g., extrusion amount, offset, distance). The tool is severely under-documented for its only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Blender Studio Pro MCP: extrude_region' merely restates the tool name without specifying what the operation does, what geometry it operates on, or how it differs from sibling tools. It is a pure tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many other mesh manipulation tools (e.g., subdivide, bevel, inset_faces). There is no mention of prerequisites, selection requirements, or when alternatives are more appropriate.
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 supplied, the description carries the full burden of behavioral disclosure. It discloses nothing: not whether the operation is read-only, what it returns, how it handles errors, or any side effects. The description simply names the operation without any behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than concise writing. It consists solely of a prefix and the tool name, which adds no informational value. While it is brief, it fails to earn its place by providing any actionable detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely purpose of retrieving custom properties for an object, the description is wholly incomplete. It lacks any explanation of the return value, output schema, expected input format, or relationship to sibling property operations. For a single-parameter tool with no annotation support, this is critically inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, object_name, but with zero schema description coverage. The tool description adds no meaning to the parameter—it does not explain what object_name refers to, its expected format, or its role. The parameter is entirely undocumented semantically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a bare restatement of the tool name, 'Blender Studio Pro MCP: get_custom_properties'. It contains no verb, resource, or action, and offers no differentiation from sibling tools. It fails to indicate whether this retrieves or lists custom properties, making it impossible for an agent to infer the function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives. Sibling tools like set_custom_property and delete_custom_property exist, but the description does not mention them, nor does it explain any prerequisites or scenarios for use. The agent is left with no contextual direction.
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 gives zero behavioral information: no mention of side effects, required Blender state, or what the returned stats represent. An agent cannot infer what this tool does from the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specified rather than concise. It contains only the tool name, adding no actionable information. This is a failure of specification, not efficient brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description is completely inadequate for a tool with a parameter and no behavioral disclosure. It does not explain what the tool does, what the output represents, or any preconditions. An agent cannot correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes a single required parameter 'object_name' with no type or description, and schema description coverage is 0%. The description does not clarify what object_name refers to, how to specify it, or any expected format. No compensation is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: get_mesh_stats' — essentially a prefix plus the tool name. It restates the title without explaining what 'mesh stats' means, what statistics are returned, or how this differs from siblings like get_object_info or get_scene_info. This is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_object_info or get_scene_info. No context about typical use cases or when it would be appropriate.
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 is a bare name that reveals no behavioral traits. It doesn't explain side effects (e.g., whether it creates new geometry in-place), prerequisites (e.g., active selection), or what kind of result to expect. The description carries zero informational burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is technically short, this is under-specification rather than conciseness. The single phrase 'Blender Studio Pro MCP: inset_faces' contributes nothing beyond the tool name, so it doesn't earn its place. It could be removed entirely without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mesh-editing tool with two parameters, no annotations, and no parameter documentation, the description is grossly inadequate. An agent cannot safely or correctly invoke this tool without additional context about preconditions, effect, or expected input values. The presence of an output schema does not compensate for the total lack of guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds nothing about 'depth' or 'thickness' – their semantics, units, allowed ranges, or how they affect the inset operation. Since the parameters have defaults but no descriptions and no enums, the description was the only way to convey meaning, and it completely fails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology – 'Blender Studio Pro MCP: inset_faces' merely restates the tool name with a prefix. It provides no verb, resource, or scope that would help an agent understand what the tool does, and it fails to distinguish it from dozens of other geometry manipulation siblings like 'bevel', 'subdivide', or 'merge_by_distance'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool vs alternatives. No context about whether it operates on faces in edit mode, whether it requires a selection, or what the typical workflow should be. An agent has no way to decide when to call inset_faces over other mesh-editing 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?
Annotations are absent, so the description bears full responsibility for disclosing behavior (e.g., side effects, permissions, return types). It provides none. There is no mention of what 'instance_collection' does, what it affects, or what the output schema contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the text is extremely short, this is under-specification rather than conciseness. It is a single fragment that does not earn its place; it merely labels the tool without adding information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, a required one, and an output schema), the description is completely inadequate. It lacks all necessary context: what the tool does, when to use it, how parameters are used, and what the output represents. The presence of an output schema does not compensate for the total absence of semantic content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the three parameters (name, location, collection_name), and the description does not elaborate on any of them. Required parameter collection_name is undefined, and optional parameters have no meaning explained. The description adds zero semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is only 'Blender Studio Pro MCP: instance_collection', which repeats the tool name without any verb or resource explanation. It does not state what action the tool performs, so an agent cannot infer its purpose from the text alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings (e.g., create_collection, move_to_collection). The description gives no context, prerequisites, or examples, leaving the agent without any decision-making basis.
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 of behavioral disclosure. The description offers no insight into what linking does, whether it is destructive, requires permissions, or has side effects. An agent has no way 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but brevity without content is under-specification, not conciseness. It is not front-loaded with any useful information, and every word is wasted on restating the tool name. The structure offers no logical flow or prioritization of key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters and no description, the tool is severely incomplete. The agent cannot determine the expected file format, the relationship between the parameters, or what success looks like. Even with an output schema present, the absence of any explanation of the operation makes this inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lists three required parameters (filepath, directory, filename) but provides no descriptions or types. Schema description coverage is 0%, and the description adds no meaning to these parameter names. The agent cannot infer what values are expected or how they relate to the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is "Blender Studio Pro MCP: link_from_blend", which merely restates the tool name with a prefix. It does not specify what the tool does, what resource it operates on, or how it differs from siblings. This is a tautology that provides zero functional information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Notably, the sibling list includes 'append_from_blend', which is semantically similar, but the description does not distinguish when to link versus append. No context, prerequisites, or exclusions 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 carries the full burden of behavioral disclosure. It discloses nothing about what the tool returns, whether it reflects currently-applied constraints, stale data, or any side effects. With a prefix-only description, the agent gets no behavioral context at all.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than genuine conciseness. There is no informative content to be concise about.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 1-parameter tool with an output schema that is not described anywhere, this description is completely inadequate. The agent cannot determine what it lists, what format the results take, or prerequisites for the object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single required object_name parameter, and the description does not compensate. The agent cannot tell whether object_name needs a Blender data path, a display name, or an index, and whether the object must already exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Blender Studio Pro MCP: list_constraints' merely restates the tool name with a prefix. It does not state what is listed, on which object, or what a constraint is in this context. This is a tautology that adds zero semantic content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Siblings like add_constraint, remove_constraint, set_constraint_param, and add_bone_constraint exist, but the description offers no routing information.
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 of behavioral disclosure. It discloses none: it does not mention side effects, permissions, output format, or any constraints. An agent has zero behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one line, but it is under-specification rather than conciseness. It adds no value and does not structure information for the agent. It is essentially empty.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with one parameter, but the description is entirely inadequate. It does not explain what the tool returns (even though an output schema exists), what input is expected, or how it relates to the broader shape key workflow. An agent cannot call it correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (object_name) with 0% description coverage, and the description does not add any meaning to it. The agent cannot infer what object_name should be (e.g., a mesh object with shape keys) or how it is used. The description fails to compensate for the schema's lack of information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: list_shape_keys' which is just a prefix plus the tool name. It does not state what the tool does or what it lists. This is a tautology, providing no information beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Sibling tools like add_shape_key, set_shape_key_value, and remove_shape_key exist, but the description does not mention any of them or explain conditions for using list_shape_keys.
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 does not describe what the tool does (e.g., merges vertices within a threshold distance), effects on selection, or side effects. There is no behavioral information 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise. Each word is wasted, as it only repeats the tool name. There is no front-loaded useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mesh operation that affects geometry, the description is completely inadequate. It provides no information about behavior, parameter semantics, output, or prerequisites. The output schema exists but cannot compensate for the missing description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'threshold' parameter with no description, and schema description coverage is 0%. The description does not explain the meaning of 'threshold' (e.g., distance in Blender units, default 0.0001). With zero coverage, the description must compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: merge_by_distance', which merely restates the tool name. It does not state a specific verb or resource beyond the name itself, nor does it differentiate from sibling tools like delete_geometry or apply_bmesh_op. This is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of the intended context (e.g., mesh editing, vertex merging) or exclusions. The description offers zero usage direction.
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 disclosing behavior. It offers nothing about side effects, required permissions, state changes, or return values. An agent cannot predict whether this tool is destructive, read-only, or requires a specific Blender state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not genuine conciseness. It is a redundant restatement of the name, with no useful content. A concise description would still convey purpose; this one conveys nothing beyond the identifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a tool with just one optional parameter and an output schema, the description is entirely inadequate. It does not explain the tool's function, when to call it, what it returns, or any prerequisites. The agent is left with no actionable knowledge to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes one parameter, 'reset_ui', with a default but no description (schema coverage 0%). The tool description does not mention or explain this parameter at all. Since the schema provides no meaning and the description fails to compensate, the agent cannot interpret what 'reset_ui' does or when to set it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Blender Studio Pro MCP: new_blend' is a pure tautology, restating the tool name with a prefix. It gives no verb, resource, or action, so an agent cannot infer what the tool does or how it differs from siblings like create_object or save_blend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool, what scenarios it applies to, or exclusions/alternatives. The description contains no contextual cues at all, leaving the agent without any basis for selecting this over other 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 present, the description carries full responsibility for behavioral disclosure. It provides zero information about effects on the current Blender state, whether changes are destructive, or what the output schema contains. The description is silent on all behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is short because it omits essential information, not because it is efficiently written. A single useless sentence is not concise in a meaningful sense; it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no annotations, the description must at least state the action and expected input. It does neither. Even though an output schema is reported, the description does not explain what the tool returns or how it affects the document, leaving agents without enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'filepath', has no type or description in the schema, and schema coverage is 0%. The description does not mention this parameter at all, nor clarify that it expects a path to a .blend file. No semantic meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: open_blend', which merely restates the tool name with a product prefix. It does not state what the tool does (e.g., opens a .blend file into the current scene). This is a tautology with no actionable meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool relative to siblings like new_blend, import_file, or append_from_blend. There is no mention of prerequisites, file types, or scenarios that call for this tool.
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 at all, the description carries the full burden of behavioral disclosure, but it states nothing about side effects, permissions, reversibility, errors, or return values. It merely names the operation without explaining its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It contains no substantive content to structure or front-load. A single short string that adds no value is not concise; it is incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a simple two-parameter operation, the description fails to provide minimal context such as what a constraint is, what object it applies to, or how the removal is performed. With no annotations, no parameter details, and no behavioral explanation, the definition is wholly inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the two parameters (object_name and constraint_name). It provides no additional meaning beyond the parameter titles, which themselves lack types or descriptions. The agent is left with no semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially just a prefix plus the tool name ('Blender Studio Pro MCP: remove_constraint'). It restates the name without adding any verb or resource detail, making it a tautology. An agent cannot infer what the tool does or how it differs from siblings like add_constraint or 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or comparisons to related constraint tools. There is no context to help an agent decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It says nothing about what 'remove_driver' actually does—whether it mutates data, whether it affects only the specified object or broader scope, any side effects, or whether it requires specific conditions. The complete lack of behavioral information makes this tool risky for an agent to invoke.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It contains no substantive information—just a namespace and tool name. While brevity is good, this is not effective conciseness; it is a placeholder that fails to communicate any purpose or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (removing a driver in Blender), the description is completely inadequate. There is no information about what a driver is, how removal works, what the index parameter does, or what the output schema represents. An agent cannot correctly call this tool based on the description alone, especially with zero annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter explanations. The schema lists object_name, data_path, and index, but the description does not clarify what these mean, how they relate, or what values are expected. There is no semantic help beyond the parameter names themselves, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is exactly 'Blender Studio Pro MCP: remove_driver' which merely prefixes the namespace and repeats the tool name. It does not state what the tool does, what action it performs, or what resource it targets. This is a tautology—the name itself is the only meaning conveyed, and the description adds no verb+resource clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers zero guidance on when to use this tool versus alternatives. There is no mention of conditions, prerequisites, or comparisons to sibling tools like add_driver or remove_strip. An agent is left to infer usage entirely from the tool name, which is insufficient.
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 of disclosing behavior. It discloses nothing: no mention of side effects, reversibility, permissions, or return values. The agent knows only that something called 'marker' is removed, with no detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not conciseness. It does not front-load useful information; it simply repeats the tool name. The single sentence earns no space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no parameter descriptions, and no output schema details, this description is entirely inadequate. An agent cannot correctly invoke it without external help. It needs at least a definition of markers and the parameter's meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter 'name' with no description in the schema (0% coverage). The description does not compensate, leaving the agent to guess what 'name' refers to (marker name? object name? etc.) and whether it's a string, exact match, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: remove_marker', which merely restates the tool name with a prefix. It adds no information about what a marker is, what removal entails, or how it differs from siblings like add_marker or list_markers. This is a classic tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, what alternatives exist, or any prerequisites. The description provides zero context for an agent to decide between remove_marker and other marker-related or deletion 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?
There are no annotations to rely on, and the description provides no behavioral disclosure. It does not mention side effects, prerequisites, or what happens when removing a particle system. The description is silent on any operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. No meaningful content is provided, so the brevity fails to serve the agent. A 2 reflects that while the length is minimal, it lacks any informative structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema but the description provides no context about return values or any aspect of the operation. For a tool with two parameters and no annotations, this description is entirely inadequate for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. Both 'object_name' and 'system_name' are entirely undocumented in both the schema and description, leaving the agent without guidance on what values to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: 'Blender Studio Pro MCP: remove_particle_system' simply restates the tool name with a prefix. It provides no verb, resource, or scope details that would help an agent understand what the tool does beyond its name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool or how it differs from siblings like 'add_particle_system' or 'list_particle_systems'. The description offers zero contextual information about appropriate usage scenarios.
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 of behavioral disclosure. It reveals nothing about side effects, reversibility, required permissions, or return behavior. For a mutating operation like removing a rigid body, this is a critical omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is due to under-specification, not effective conciseness. It contains no substantive information and does not earn its single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no behavioral details, no parameter semantics, no output schema explanation, and no usage context, the description is completely inadequate for an agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the only parameter (object_name) has no description in the schema. The description also fails to explain the parameter's purpose, format, or constraints, leaving the agent entirely without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: 'Blender Studio Pro MCP: remove_rigid_body' merely restates the tool name with a prefix. It does not state what the tool does, what resource it acts on, or how it differs from siblings like add_rigid_body or remove_strip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description says nothing about context, prerequisites, or when not to use it, leaving the agent to guess.
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 behavioral information is disclosed. The description carries no details about side effects, permissions, safety, or return behavior. With no annotations to rely on, this is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but does not meet the threshold of conciseness—it is under-specification. While there is no waste, the lack of any meaningful content makes it inadequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters and zero annotations, the description provides no context. An agent cannot determine how to call it correctly, what results to expect, or how it relates to sibling tools like add_shape_key or set_shape_key_value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the two required parameters (object_name, key_name). An agent has no clue what these parameters expect, formats, or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is only "Blender Studio Pro MCP: remove_shape_key", which is a direct restatement of the tool name. It provides no verb, resource description, or differentiation from siblings. It is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context, no exclusions, no mention of prerequisites. The description offers zero situational direction.
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 provided, so description carries full burden of behavioral disclosure. It says nothing about side effects, whether the operation is destructive, prerequisites, or error conditions. Totally opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short, but this is under-specification, not conciseness. The single sentence adds no value beyond the tool name. While it is front-loaded, it fails to convey any usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with one required parameter and no output schema details, the description is entirely inadequate. An agent cannot determine what strip to remove, what happens, or any side effects. Completely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no information about the 'strip_name' parameter. The schema itself lacks type or description, so the agent has zero guidance on what to pass. No compensation from description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is merely 'Blender Studio Pro MCP: remove_strip', which restates the tool name without stating what it does. It fails to specify that it likely removes a sequencer strip or any resource. This is a tautology with no verb or resource clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Sibling tools like add_movie_strip, add_image_strip, add_sound_strip exist but no mention of when removal is appropriate or any prerequisites. Completely absent.
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 gives no behavioral details—such as whether this toggles visibility, what the hide_render and hide_viewport defaults mean, side effects on the scene, or return values. The agent has no idea what operation is performed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is very short, this is not conciseness—it is absence of content. It simply restates the tool name as a label, which is under-specification rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters (one required) and an output schema, a minimal description is insufficient. An agent has no guidance on correct invocation, parameter meaning, or expected behavior, making this completely inadequate for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds nothing about the parameters. The schema itself only lists names without types or descriptions, so parameters remain completely opaque. The description fails to compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description repeats the tool name with a prefix, 'Blender Studio Pro MCP: set_collection_visibility', and provides no verb, resource, or effect. It is a tautology that offers no insight into what the tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many collection-related siblings like list_collections, create_collection_hierarchy, delete_collection, or move_to_collection. The agent cannot infer appropriate usage 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 gives no indication of behavior such as side effects, required permissions, or effects on the scene. The full burden falls on the description, which is empty of any 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It contains only the name, providing no structured content or useful information for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no annotations, and no output schema details, the description is completely inadequate. An agent cannot infer the tool's purpose, parameters, or expected behavior from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the schema parameters (look, gamma, exposure, display_device, view_transform) have only titles and defaults, no descriptions. The tool description adds zero clarification about what these parameters mean or how they should be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is simply 'Blender Studio Pro MCP: set_color_management', which restates the tool name and adds no information about what the tool actually does. It is a tautology with no verb or resource specification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent completely without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden of disclosing behavioral traits such as side effects, scene mutation, mode requirements, or reversibility. The description is silent on all of these, providing no behavioral transparency whatsoever.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that merely restates the tool name and prefix. It is not concise in the sense of conveying useful information efficiently; it is severely under-specified. While it does not waste words, it also provides no content that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of setting a constraint parameter and zero annotation or schema coverage, the description is completely inadequate. It omits essential context such as which object or constraint is affected, how the param/value pair works, and what the output schema represents. An agent cannot call this tool correctly based on the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for all four parameters, and the description adds no meaning to param, value, object_name, or constraint_name. The agent is given no information about what values are valid, what the parameters represent, or how they relate to each other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just a prefixed tool name ('Blender Studio Pro MCP: set_constraint_param') and provides no statement of what the tool does. It does not mention the action (setting a parameter on a constraint), the resource, or how it differs from similar tools like add_constraint or set_modifier_param. This is essentially a tautology of the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus any of the many sibling tools. No mention of prerequisites, context, or alternatives. An agent has no information about the typical use case or when it should be selected over other constraint or modifier 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 provided, the description must disclose behavior. It says nothing about what changes are made, whether it modifies existing curves, if it requires a specific object type, or what side effects occur. The description offers zero behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. A single sentence that only repeats the tool name wastes the opportunity to convey essential information. While there is no clutter, the lack of substantive content makes it inadequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 5-parameter tool with only one required parameter, an output schema, and no annotation coverage. The description must provide context about what the tool operates on, how parameters interrelate, and possible outcomes, but it offers none. The definition is completely inadequate for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter meaning. It does not. Parameter names like 'extrude' and 'bevel_depth' are not elaborated, leaving the agent guessing about units, defaults, or valid ranges. The description adds no value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is exactly the tool name with a prefix ('Blender Studio Pro MCP: set_curve_geometry'). It states no verb, no resource, and no effect. This is a tautology and provides no information about what the tool does, let alone how it differs from sibling tools like create_curve or set_text_body.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, target object types, or conditions that would select it over similar curve-related tools. An agent cannot infer usage context from the description alone.
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 does not mention side effects (e.g., overwriting existing custom properties), permissions, return values, or performance considerations. The description is entirely silent, providing no behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is minimal, but it carries no useful information. This is under-specification rather than conciseness; the sentence does not earn its place as it adds zero value beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% parameter documentation, no annotations, and moderate operational complexity (setting a property on an object), the description is completely inadequate. Although an output schema exists, it does not compensate for the total lack of guidance on invocation or expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 parameters with no descriptions and 0% schema_description_coverage. The description adds nothing about the meaning or relationship of object_name, prop_name, and value. An agent has only the parameter names to infer semantics, which is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: set_custom_property' which merely restates the tool name with the server prefix. It provides no verb-resource clarity beyond the name itself and fails to differentiate from siblings like get_custom_properties or delete_custom_property. This is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention prerequisites, expected workflow, or exclusions. An agent cannot infer when to choose this over get_custom_properties or delete_custom_property.
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 behavioral traits. It reveals nothing about side effects, prerequisites, or output. The agent cannot infer whether this is a read, write, or state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It does not front-load any useful information; it merely repeats the tool name. A concise description should pack in meaning, not just be brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no annotations, and no output schema details, the description is grossly incomplete. Sibling tools like 'set_frame_range' and 'set_pivot_point' give hints that this is a Blender operation, but the description provides no context for correct invocation. An agent cannot safely call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers no parameter explanation. The schema only shows names like 'start', 'end', and 'enabled' without types or meaning. The description fails to add any semantic insight, leaving the agent to guess what these parameters represent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just the tool name prefixed with 'Blender Studio Pro MCP:'. It restates the name without adding any information about what 'set_preview_range' actually does. It is a tautology that fails to convey the operation, resource, or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other similar tools such as 'set_frame_range' or 'set_frame'. The description provides no context about the intended workflow or alternatives.
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 carries no behavioral information at all. It does not disclose side effects, prerequisites (e.g., whether a shape key must exist), or return behavior. The description entirely fails to inform the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. A single phrase that repeats the tool name provides no value. It is not structured or front-loaded with any actionable content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three required parameters, no parameter descriptions, no annotations, and a content-free description, the tool is completely inadequate for correct invocation. Even the existence of an output schema does not help because the agent cannot reason about inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It does nothing. The parameter names (object_name, key_name, value) hint at meaning, but the description adds no types, formats, or constraints, leaving the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a literal restatement of the tool name: 'Blender Studio Pro MCP: set_shape_key_value'. It provides no verb, resource, or scope, and offers no differentiation from siblings like add_shape_key, list_shape_keys, or remove_shape_key. This is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many related shape key tools. No context, no alternatives, no exclusions. The agent has no way to determine the intended use case.
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 present, so the description carries the full burden of behavioral disclosure. The description is silent on side effects, what gets modified, whether an offset affects placement, or any required selection state. It does not disclose the tool's behavior beyond the name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than conciseness. A single sentence could adequately explain the tool, but this description provides no useful information. It does not earn its placement; it is simply a wrapper around the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool mutates object positions and has a parameter with unclear semantics, the description is completely inadequate. Without any explanation of the operation or the offset, an agent cannot safely invoke it. The output schema exists but does not compensate for the missing behavioral and parameter information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter 'offset' with no type or description, and schema description coverage is 0%. The description does not explain the parameter at all. Since the description adds nothing about what 'offset' meaningfully does, the parameter remains completely opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is exactly the tool name with a prefix 'Blender Studio Pro MCP:', providing zero semantic content beyond the name. It does not state what action is performed, on what objects, or what 'snap to cursor' means. This is a tautology – the description restates the tool name without adding any clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use this tool versus alternatives like snap_cursor_to_selected or set_3d_cursor. There is no mention of prerequisites, context, or conditions that would select this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, and it discloses nothing. Subdividing is a mutating operation, yet the description does not say whether it operates on selected geometry, whether it is destructive/reversible, or what the response contains. Completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but this is under-specification rather than conciseness. A single restatement of the tool's name does not earn credit for efficient writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists and there are only two parameters with sensible defaults, the absence of any annotations, any schema descriptions, and any descriptive text leaves the agent without even a basic understanding of the operation. An output schema does not compensate for zero behavioral and parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no parameter meaning whatsoever. Smoothness (likely a 0-1 range) and number_cuts (count of cuts per face) are only inferable from their names and defaults; the description does not help the agent understand valid ranges, defaults, or how they affect the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Blender Studio Pro MCP: subdivide' is a pure tautology that restates the tool name without a verb, resource, or outcome. It does not state that the tool splits faces or edges of a mesh, and nothing distinguishes it from sibling mesh-editing 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many similar sibling operations (bevel, loop_cut, inset_faces, delete_geometry). No preconditions such as requiring an object selection, edit mode, or mesh selection are mentioned. Zero usage direction.
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 offers zero behavioral information. It does not disclose side effects, prerequisites, return behavior, or anything about how the tool operates. The description is a bare label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but this is under-specification rather than conciseness. A single sentence that merely repeats the tool name adds no value and does not earn its place. It is not appropriately structured for agent use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool likely involves unpacking resources in Blender (a complex operation), the description is completely inadequate. Even with an output schema present, the lack of any behavioral or usage context leaves agents unable to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'method' with default 'USE_LOCAL', but the description gives no explanation of what this parameter means, what values are accepted, or how it affects the operation. Schema coverage is 0%, and the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: unpack_resources', which simply repeats the tool name with a product prefix. It does not state any verb, resource, or action the tool performs. It is a tautology and provides no distinction from sibling tools like pack_resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are provided. An agent cannot infer when unpack_resources is appropriate.
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 full responsibility for behavioral disclosure. It only says 'Create a force field' without mentioning side effects, required scene state, or what kind of object is created. There is no mention of how the force field integrates into the scene or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but brevity here is not conciseness—it's under-specification. The sentence is structurally unclear ('force field empty' reads as a fragment) and fails to organize information logically. It could be improved by clearly stating the resource and parameters, but as is, it lacks structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no annotations, and a large sibling set, the description is grossly incomplete. It does not explain what the tool does, when to use it, or how parameters work. Even with an output schema present, the description fails to provide any guidance for an agent to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter explanations. However, it only lists possible type values (FORCE, WIND, VORTEX, MAGNET) without explaining what 'type' means or what the other parameters (name, location, strength) do. This is far from adequate for the four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a force field empty' which is awkward and unclear—'empty' is ambiguous (possibly meaning an empty object, but it's not explained). It does name a concrete resource ('force field') and a verb ('Create'), but it lacks specificity about what a force field is or does, making it hard to distinguish from other creation tools like create_camera or create_light without further context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, any prerequisites, or alternatives. The description provides zero context about the intended scenario, and with over 250 sibling tools, an agent cannot infer when this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It fails to mention that this tool adds a new particle system, what happens to the object, or whether it requires an existing object. The agent is given no information about side effects, return behavior, or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It lacks any structure, such as a purpose statement or parameter overview, and the single sentence provides minimal information. It is not a well-crafted efficient description but a bare fragment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool adds a particle system and has four parameters plus an output schema, the description is severely incomplete. It omits essential context like the required object, default behaviors, and what the output represents. The agent cannot rely on this description to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It offers a hint about valid values for 'type', but it does not explain the meaning of other parameters like 'name', 'count', or 'object_name'. This is far short of necessary parameter documentation, leaving most arguments ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'type: EMITTER or HAIR.' does not state what the tool does. It only mentions possible values for the 'type' parameter, leaving the tool's core function (adding a particle system to an object) entirely implied. There is no verb describing the action, and it is impossible to distinguish this from siblings like 'set_particle_settings' or 'remove_particle_system' without guessing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'list_particle_systems' or 'set_particle_settings'. There is no mention of prerequisites, target objects, or comparison with related tools, leaving the agent without any contextual direction.
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 of behavioral disclosure. It does not mention side effects, required prerequisites (e.g., having an active scene), what happens to existing objects, return values, or any limitations. The list of types gives no insight into 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the text is extremely short, it is under-specified rather than concise. It lacks any structural elements like an imperative verb, example, or lead statement about the tool's purpose. The minimalism is not effective because it omits essential information, similar to the 'process' example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a curve creation tool with three parameters and an output schema, the description is grossly incomplete. It does not explain what a curve is, how to define its geometry (e.g., control points), what the different types mean for the resulting object, or how the tool interacts with the current scene. None of the information an agent needs to call this correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per the metrics, and the description's only parameter mention is the 'type' values, which merely repeats the schema's default and enum-like possibilities. It does not explain what each curve type means, how they differ, or how 'name' and 'location' influence the result. The description adds no meaningful semantics beyond the bare parameter list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'type: BEZIER, NURBS, PATH' merely lists possible values for the 'type' parameter without stating that the tool creates a curve. It does not communicate the tool's primary action or resource, relying on the name to imply purpose. It is close to a tautology since it only restates parameter options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling creation tools or how it fits into a workflow. No context is provided about scenarios where creating a curve is appropriate or about alternatives like create_object or convert_to_mesh. The description offers zero usage direction.
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 of behavioral disclosure. It fails to mention that this tool is destructive (deletes geometry), what happens to the geometry, or any side effects. It does not even confirm the deletion behavior implied by 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but that is due to under-specification rather than conciseness. It provides no structural benefit; the single line is essentially a parameter value list with no introduction or context. It fails to earn its place as a description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive mutation tool with no annotations, no output schema explanation (output schema exists but is not referenced), and a parameter that requires interpretation, the description is wholly inadequate. An agent cannot correctly call this tool without guessing what the types mean and what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'type' with a default but no enum, and 0% schema description coverage. The description lists five possible values (VERT, EDGE, FACE, ONLY_FACE, EDGE_FACE) which provides the distinct enum values. However, it does not explain what each type means or how they affect the deletion, so it adds only minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'type: VERT, EDGE, FACE, ONLY_FACE, EDGE_FACE' only lists possible values for a parameter. It does not state what the tool does, what resource it acts on, or how it differs from any sibling tool. This is a tautology that restates the parameter values without explaining the action 'delete_geometry'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, what prerequisites exist, or when to prefer alternatives. The description offers no context for selecting this tool over the many sibling tools like 'delete_object' or 'delete_material'.
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 carry the full burden of behavioral disclosure. It fails to state what entering edit mode does to the object, whether it requires the object to be selected or exist, whether it's reversible, or what the effect is on the scene. There is zero information beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but grossly under-specified. This is not effective conciseness; it's an absence of content. There is no structure, no emphasis, and the single line provides no useful information that the tool name doesn't already convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description provides no context about the tool's operation, side effects, or requirements. For a mode-changing tool, an agent would need to know what 'edit mode' entails (e.g., it affects the active mesh object), or at least that the object must be a mesh. The complete lack of context makes this tool unsafe to invoke reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'object_name' but provides no description for it (0% coverage). The description does not mention the parameter at all, leaving the agent to guess whether object_name refers to the object to enter edit mode on, whether it must be a mesh, etc. No value is added over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially the tool name itself ('Blender Studio Pro MCP: enter_edit_mode'), providing no additional clarity beyond the verb and resource implied in the title. It doesn't specify what object or context the edit mode applies to, and it doesn't differentiate from sibling tools like set_mode or enter_sculpt_mode. This is close to a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as set_mode or enter_sculpt_mode. The description does not mention prerequisites, object selection, or any conditions that would influence the choice. An agent has no idea whether to call this or set_mode.
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 of behavioral disclosure. It reveals nothing about side effects, return values, permissions, or state changes. A getter is typically expected to be read-only, but the description does not confirm this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is short because it is under-specified, not because it is concise. A single sentence that merely repeats the name is not efficient; it wastes the opportunity to inform the agent. Proper conciseness would convey meaning in minimal words, which this does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool (no parameters, likely just returns the 3D cursor location), but the description provides no information about its purpose or return value. With a provided output schema it might be partially covered, but the description itself is completely inadequate for an agent to understand when or why to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 because the schema carries nothing to explain. However, the description still fails to clarify what the tool returns or how it behaves. It doesn't compensate for the lack of parameter detail nor state the return format. Since it adds nothing, I lower from baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a verbatim repeat of the tool name prefixed by 'Blender Studio Pro MCP:'. It provides no actual information about what the tool does, what resource it acts on, or what it returns. It is a tautology with zero explanatory value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like set_3d_cursor or snap_cursor_to_selected. The description does not mention any context, conditions, 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 discloses zero behavioral traits. It doesn't indicate whether the tool is read-only, destructive, or what side effects it might have. The agent has no insight into the tool's operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concise. It contains one empty sentence that adds no value. A good description should front-load useful information; this one provides none.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a required parameter and an output schema, but the description explains nothing about them. Given the complexity of Blender objects and the need to list particle systems, this is totally inadequate for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the parameter object_name, and the description adds no meaning to it. The agent receives no information about what object_name refers to, its format, or why it's required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: list_particle_systems' which merely restates the tool name. It does not state a specific verb, resource, or any functional detail. This is a tautology, as it repeats the title without explaining 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about typical use cases, prerequisites, or differentiation from sibling tools like add_particle_system or remove_particle_system.
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 supplied, and the description provides no behavioral information whatsoever. The agent learns nothing about side effects, prerequisites, or return behavior from the description alone, which carries the full burden here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It contains no front-loaded useful information—only a repetition of the tool name with a prefix.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a file-saving tool with one parameter, no annotations, and a rich set of siblings, the description is completely inadequate. It fails to explain what the filepath refers to, whether it's required, or any constraints on file format or location.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it provides no explanation of the 'filepath' parameter. The schema itself offers no type or description, leaving the agent entirely without information about how to use the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only repeats the tool name with a prefix ('Blender Studio Pro MCP: save_blend') without stating what the tool does. While 'save_blend' suggests saving a Blender file, the description does not explicitly clarify the action or resource, nor does it distinguish the tool from similar file-operation siblings like open_blend or new_blend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool or how it differs from alternatives. The description gives no context about file paths, required steps, or relationships with other 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 available, the description carries the full burden of disclosing behavior. 'set_3d_cursor' implies a mutation, but the description does not state that it modifies Blender's 3D cursor location and rotation, nor any side effects, prerequisites, or consequences. It adds no behavioral information beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is extremely short, but this is under-specification rather than conciseness. A single branding string with no explanatory content does not earn credit for efficiency; it fails to convey essential information an agent needs to use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks any meaningful elaboration. For a tool with two parameters, no annotations, and no parameter descriptions, this definition leaves an agent with no understanding of how to set the 3D cursor. It is fundamentally incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain what the 'location' and 'rotation' parameters mean and how they should be formatted. The description does not mention either parameter; it provides no value beyond the raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Blender Studio Pro MCP: set_3d_cursor' is a tautology that merely restates the tool name with a branding prefix. It does not explain what operation is performed, on what object/resource, or how it differs from sibling tools like get_3d_cursor or snap_cursor_to_selected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description is purely nominal and gives no context on intended 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.
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 of behavioral disclosure. It says nothing about whether the operation is destructive, read-only, or requires specific context (e.g., a selection must exist). The agent gets no behavioral hints at all.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not conciseness. It consists of a single line that repeats the tool name. No useful information is front-loaded because there is none.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is part of a large library with many cursor-related commands (snap_selected_to_cursor, get_3d_cursor, set_3d_cursor). Even with no parameters and an output schema, the description must clarify the tool's purpose and any prerequisites (e.g., a selection). It provides none, leaving an agent unable to call it correctly or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (vacuously, since there is nothing to document). Baseline for 0 params is 4, but the description adds no meaning about what the cursor snaps to or how it uses the selection. It fails to compensate for the absence of schema detail the way a good description could.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is purely a restatement of the tool name with a prefix ('Blender Studio Pro MCP: snap_cursor_to_selected'). It does not state what action the tool performs or what resource it affects. This is a tautology, offering no clarification beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Sibling tools like snap_selected_to_cursor and set_3d_cursor exist, but no conditions or exclusions are mentioned. An agent has no idea how to choose between them.
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 of behavioral disclosure. It reveals nothing about the operation — e.g., whether missing properties raise errors, whether deletion is irreversible, or what the return value indicates. The only hint is the word 'delete' in the name, which implies mutation but adds no detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but its brevity is a result of under-specification rather than efficient communication. It contains no usable information beyond the tool name, so it fails to earn its place as a substantive description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete tool, the name and parameter labels give some surface-level context, but the description omits any behavioral or error-handling details. An agent cannot infer what happens on failure, whether the property must exist, or what the output schema returns — gaps that a brief description could easily fill even without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter (object_name, prop_name). While the parameter names are somewhat self-explanatory, the description adds no value beyond what the raw schema field names already imply, leaving the agent to guess at types, formats, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: delete_custom_property' — a direct restatement of the tool name with a prefix. It does not state what the tool does (e.g., 'Deletes a custom property from an object'), so it fails to add any clarifying meaning beyond the name 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Sibling tools like set_custom_property and get_custom_properties exist, but the description doesn't mention them or any conditions that would select delete over them. The omission is a neutral lack of guidance rather than active misinformation.
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 of behavioral disclosure. It reveals nothing about side effects, required context, or what happens on execution. An agent has no idea if this mutates state, requires specific Blender objects, or has any prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not conciseness. It provides no useful information and fails to earn its place; a single word repeated with a prefix is not effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema details (though output schema exists, it's not used), the description is entirely inadequate. It doesn't explain what 'pack' means, what resources are affected, or what the tool does. An agent cannot infer correct usage from the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% (since there are none). Per the rubric, high schema coverage gives a baseline of 3 even with no parameter info in the description. The description adds no parameter meaning, but there is nothing to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: pack_resources' which is essentially the tool name with a prefix. It restates the name without any verb, resource, or action. There is no indication of what packing resources entails, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or how it differs from any of its many siblings (e.g., unpack_resources, import_file, etc.). No context, triggers, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 reveals nothing about side effects, whether it requires an existing tree, how it handles node placement, or what the return value is. Essentially no behavioral information beyond a parameter example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but in this case brevity is a sign of under-specification rather than conciseness. It is a raw fragment, not a complete sentence, and it fails to front-load any purposeful content beyond a parameter hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool likely requires existing compositor context and has sibling tools for setup and connection, the description is grossly insufficient. It doesn't explain prerequisites, expected effects, or return behavior, so an agent has no reliable way to invoke it correctly without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds examples for node_type, which is helpful but incomplete. It covers only one of three parameters (node_type), leaving name and location entirely undocumented. Schema coverage is 0%, so the description must compensate but does so only marginally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a fragment that only gives examples for node_type, not a statement of the tool's purpose. It doesn't explicitly say it adds a compositor node; the function can only be inferred from the tool name and sibling tools. This is vague and fails to differentiate from tools like connect_compositor_nodes or set_compositor_node_input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool, what prerequisites exist (e.g., needing an existing compositor tree via ensure_compositor), or which alternatives are appropriate. The description gives no context for selection among the many compositor-related siblings.
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 disclosing behavior, but it provides nothing. It does not state whether the operation is destructive, requires special permissions, affects existing hierarchies, or what side effects occur. The name implies a creation action, but no behavioral details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concisely informative. It consists of a single line that repeats the tool name, providing no structure or front-loaded information. This is not effective conciseness; it is a placeholder.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creating a hierarchy with a parent-child relationship) and the absence of both annotations and parameter descriptions, the description is completely inadequate. Although an output schema exists, it is not shown, and the description gives no clue about return values, error conditions, or how the hierarchy is structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description itself offers no parameter explanations. The parameters 'name' and 'parent' are listed in the schema but without types, defaults (except parent defaulting to null), or any semantic guidance. The description fails to compensate for the lack of structured parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is merely the tool name prefixed by 'Blender Studio Pro MCP:', which is a tautology. It restates the name without explaining what a 'collection hierarchy' is or how it differs from sibling tools like create_collection. The verb and resource are present but without any elaboration, making the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as create_collection, move_to_collection, or instance_collection. There is no mention of the intended scenario, prerequisites, or conditions under which hierarchy creation is appropriate.
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 of disclosing behavioral traits. It states nothing about what happens when the tool is called, whether it modifies state, its side effects, or any requirements. With zero description, the agent has no information about runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the text is extremely short, it is under-specified rather than appropriately concise. It provides no substance or structure, so it fails to earn its place as a useful description. A placeholder like 'Blender Studio Pro MCP: frame_all' is not effective communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent simplicity (no parameters) and the existence of many sibling tools with similar names, a complete description should at least clarify its scope and differentiate it from alternatives. The description offers nothing, leaving the agent unable to determine when to invoke it or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain. Schema coverage is effectively 100% because the schema is empty. The baseline for 0 parameters is 4, and the description adds no conflicting or misleading information, though it also adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is exactly the tool name with a prefix ('Blender Studio Pro MCP: frame_all'), providing no information about what the tool does. It is a tautology that restates the name without any verb, resource, or effect. The agent cannot distinguish it from similar siblings like frame_selected or frame_selected_objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Sibling tools like frame_selected and frame_selected_objects exist, but the description does not mention them or any conditions for selection. The agent is left to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 vaguely mentions 'best effort' and 'may need viewport context', hinting at possible failure or environmental dependencies, but it does not describe the effect on the mesh, reversibility, or side effects. This is minimal but non-zero transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is extremely brief, but it is under-specification rather than effective conciseness. It lacks any structured breakdown or essential operational detail. The few words used do not earn their place because they add minimal practical value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mesh-editing operation with two parameters and no annotation coverage, this description is critically incomplete. The agent cannot determine how to invoke the tool, what inputs mean, or what outcome to expect. The existence of an output schema does not compensate for the missing behavioral and semantic context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the parameters 'edge_index' or 'number_cuts'. Nothing indicates their types, meanings, or how they affect the operation. The agent has no help in filling these fields correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Loop cut' essentially restates the tool name without explaining what the operation does. The added note about 'best effort' and 'viewport context' provides no clarity on the tool's purpose or how it differs from mesh-editing siblings like 'subdivide' or 'bevel'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as 'subdivide' or 'extrude_region'. There is no mention of prerequisites, context, or conditions under which it should be chosen.
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 does not state what is selected, whether the selection replaces or extends the current selection, any side effects, or the return value. There is zero behavioral detail beyond the action list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It consists only of a list of action keywords with no explanatory context. It fails to convey the tool's core function, making it unusable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description provides almost no context. It lacks any mention of what objects are affected, how selection changes, what the response contains, or any prerequisites. An agent would not know when or how to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no enum, so the description is the only place listing possible values for 'action'. However, it merely lists the words without explaining what each action means (e.g., what TOGGLE does versus INVERT). The default value is not discussed. It adds minimal value over the schema's property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists possible action values (SELECT, DESELECT, TOGGLE, INVERT) but never states what the tool actually does. The tool name suggests selecting all mesh elements, but the description does not explicitly convey that it performs a selection operation on all meshes. It is vague and relies on the name for meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools like get_selection, set_selection, and frame_selected exist, but there is no mention of differentiating factors, prerequisites, or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden, but it provides none. It does not indicate whether this is a mutation, whether it affects selected objects, requires a specific mode, or returns any state. The agent is left completely blind to side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it is unstructured and not front-loaded with purpose. It reads like a raw data dump rather than a coherent sentence, and every word is simply the accepted types, so it fails to communicate the tool's function. It is under-specified rather than efficiently written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema (which we don't see), the description should at least explain what the tool accomplishes and when to use it. Instead it provides only a parameter value list, leaving the agent without essential context about the operation's effect, prerequisites, or relationship to other tools. This is inadequate for even a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself has zero description coverage (no parameter descriptions), and the only clue is the default value 'MEDIAN_POINT'. The description lists the five possible values, which adds meaning by informing the agent of valid inputs. However, it does not explain what each value means or how they affect behavior, so it only partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just a list of enum-like values ('ACTIVE_ELEMENT, MEDIAN_POINT, INDIVIDUAL_ORIGINS, CURSOR, BOUNDING_BOX_CENTER') and does not state what the tool does or that it sets the pivot point. It lacks a verb and resource, and does not differentiate from any sibling tools, making it effectively a tautology of parameter options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, what prerequisites exist, or how it contrasts with alternatives. The description offers no context for selection, leaving agents without any basis to decide among the many sibling 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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention side effects (e.g., replacing existing materials), ordering, whether it operates on the current selection, or any limitations. This is entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief—a single sentence—which is under-specification rather than conciseness. It lacks structure and does not front-load essential constraints or usage notes. While it avoids fluff, it fails to provide needed detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no annotations, and an output schema that is not described, this description is grossly incomplete. It omits how objects are selected, what happens when object_names is null, and any return or error behavior. An agent cannot call this tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters with 0% description coverage, and the description adds no explanation of object_names (a possibly optional list) or material_name. Without any elaboration, an agent cannot infer how to populate these parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('apply') and resource ('material to objects'), but it does not specify which objects are affected (e.g., selected, all, or a list). The tool name implies 'to all', but the description leaves this ambiguous, and it does not distinguish from the sibling assign_material, which likely handles per-object assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like assign_material or set_material_slot. No context is provided about selection requirements, object scope, or when this approach is preferred.
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 of behavioral disclosure. It reveals nothing about side effects, what state is read, whether it depends on an open file, or what it returns. A getter likely has no side effects, but the agent cannot confirm this from the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one line but that shortness is under-specification, not conciseness. It communicates exactly zero information beyond the tool's own name, wasting the space it occupies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists which may document the return shape, the fundamental subject of the tool is undefined — filepath of what? For a trivial getter the description should at least name the subject (e.g., 'returns the path of the currently open .blend file'). It does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes 0 parameters, so the description needs to add no parameter semantics. The baseline of 4 applies since there are simply no arguments to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Blender Studio Pro MCP: get_filepath' is a pure tautology that merely prefixes the tool name with the product name. It never states what entity's filepath is returned (current .blend file, import path, etc.), leaving the agent to guess the tool's actual function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever on when to use this tool versus any of the roughly 200 siblings. No context, no exclusions, no alternative tools named. The agent receives zero navigation help.
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 and a description that only repeats the name, the tool's behavior is completely undisclosed. There is no mention of what it returns, side effects, or any restrictions. The description fails its role as the primary source of behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It adds no value beyond the tool name, so it does not earn its place. The structure provides no front-loaded information that helps an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description gives no indication of what the tool returns or how it fits into the broader workflow. For a tool that lists collections, the agent has no idea what to expect or how to use the result. The description is functionally blank.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and there is nothing for the description to clarify. The baseline of 4 applies since no parameter explanations are required, though the description also fails to provide any contextual meaning. Given the absence of parameters, this is the most generous score justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Blender Studio Pro MCP: list_collections' merely restates the tool name with a product prefix. It does not state that the tool lists collections in Blender or specify any action, making it a tautology that offers no functional clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'create_collection_hierarchy' or 'list_data_items'. No context, prerequisites, or selection criteria 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 exist, so the description carries the full burden of behavioral disclosure. It says nothing about side effects, read-only status, return format, or any operational constraints. The agent receives zero behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but entirely uninformative. It is under-specified rather than genuinely concise, since it conveys no useful information. Similar to the 'process' example, conciseness without substance merits a low score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to explain what markers are, what the tool returns, or how it integrates with other marker-related tools like add_marker and remove_marker. For a simple list operation, this is inadequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema already reflects this with 100% coverage. Per the baseline rule, a score of 4 is appropriate since there are no parameters to document and the description need not add anything. However, it adds nothing about the absence of parameters either, but that's not required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is simply 'Blender Studio Pro MCP: list_markers', which merely restates the tool name. It provides no verb or resource to indicate what is being listed, nor does it distinguish from siblings like list_cameras or list_actions. This is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without any decision support.
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 of behavioral disclosure, and it discloses nothing. It does not state whether playback is started in the viewport, whether the call blocks until the animation ends, what state is mutated (e.g., current frame position, playback toggle), or whether it is safe/idempotent. For a tool with zero annotation coverage, this is a total failure of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entry is short, but this is under-specification rather than conciseness. The single sentence contributes zero information beyond what the tool name already conveys, so it does not earn its place. A minimal viable description would at minimum state the verb and object, e.g., 'Starts playback of the active animation in the viewport.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and no parameters, the description leaves the tool's entire behavior undefined. An agent has no way to know what side effects occur, what the expected sequence is relative to stop_animation or set_frame, or what the response will contain. Given the large sibling set around animation control, this description is completely inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which per baseline earns a 4 regardless of description content. There is nothing for the description to document here, so no points are lost on this dimension. However, the description also fails to add any referential context that might clarify what 'animation' means in scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: play_animation' — a namespace prefix followed by the tool name itself. This is a pure tautology that restates the identifier without stating a verb, resource, or effect. An agent cannot tell whether this starts viewport playback, steps through frames, or launches an animation render; a sibling named stop_animation implies it is the inverse, but that inference exists in the sibling list, not in this description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to invoke this tool versus any of its roughly 250 siblings. There is no mention of prerequisites (e.g., an open scene), no mention of how it relates to stop_animation, set_frame, or render_turntable, and no exclusion criteria. The agent is left without any decision context.
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 of behavioral disclosure. It simply says 'Search Poly Haven assets' with no mention of whether it is a read-only operation, whether it requires network access, what it returns, or any side effects. For a tool with zero annotation coverage, this is a complete failure to disclose behavior beyond the act of searching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in word count, but it is under-specified rather than appropriately sized. It is not front-loaded with the most critical information beyond the resource name. For a tool with three parameters and no other documentation, this brevity is a deficiency, not a strength, as it omits essential guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (though not shown), but the description does not explain what the search returns or how results are structured. With three undocumented parameters and no annotations, the description is grossly incomplete for an agent to call this correctly and interpret the output. It fails to address any of the contextual needs that the structured data does not cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the meaning of the parameters (query, asset_type, categories). It does not mention any of them, leaving agents to guess what values are valid or how they affect the search. The description adds no semantic value over the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('Search') and a resource ('Poly Haven assets'), identifying the subject matter and loosely distinguishing it from the sibling 'search_sketchfab_models'. However, it lacks any detail about the scope, result format, or how it relates to other Poly Haven tools like 'download_polyhaven_asset', making it only minimally clear. It is not a tautology, but it is barely more than a label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides zero guidance on when to use this tool versus alternatives such as search_sketchfab_models, get_polyhaven_categories, or download_polyhaven_asset. There is no mention of prerequisites, when to choose this over siblings, or any exclusion criteria. An agent is left to infer everything from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Best-effort' hints at possible failure but does not specify what happens on failure, whether the operation is destructive, or what effects it has on the scene. No side effects or error behavior are disclosed, which is unacceptable for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), which is efficient but borders on under-specification. It does not front-load any critical information beyond a vague purpose. Unlike a truly concise description that packs meaning into few words, this lacks substance, so it scores below adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, 0% schema coverage, no annotations, and a specific target of GP stroke settings), the description is severely incomplete. It does not mention prerequisites (e.g., object must be a GP object), expected input formats, or what the output means. Even with an output schema, an agent cannot infer correct usage from this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the three parameters (color, strength, object_name). The description mentions 'material/color' which loosely maps to the color parameter, but it does not explain strength or object_name at all. It adds no meaningful semantic value beyond what a user might infer from the names, failing to compensate for the poor schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('setup') and a resource ('material/color for GP'), making the core purpose somewhat clear. However, it is vague: 'best-effort' and 'material/color' do not explicitly mention stroke settings, and it does not differentiate from sibling tools like set_principled_bsdf or assign_material. The name gives more specificity than the description, which only loosely paraphrases it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., an existing Grease Pencil object), no exclusions, and no alternatives named. 'Best-effort' implies a caveat but does not explain the conditions under which it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 says nothing about side effects, read-only nature, output contents, or any operational details. The description is completely silent on behavior, leaving the agent with no information 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is extremely short, but this is under-specification, not conciseness. It contains only the tool name with a static prefix, offering no useful information. There is no front-loading of key facts; it is essentially empty content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool is simple (no parameters), it has an output schema and presumably returns sequencer data. The description provides no indication of what is returned or what 'sequencer' refers to. An agent cannot infer the tool's purpose or expected output from this definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema already fully documents them (vacuously). The description does not need to add parameter details. Since there are no parameters, no additional meaning is required, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Blender Studio Pro MCP: get_sequencer_info' merely restates the tool name and does not specify what 'sequencer info' refers to or what the tool does. It fails to convey the verb and resource beyond the name itself, essentially a tautology. No distinction is made from sibling tools like get_camera_info or get_world_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or scenarios where it is appropriate. The description provides no clues about when an agent should call it.
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 does not state what effect setting the shading type has on the viewport, whether it affects rendering output, whether it is reversible, or what the return value signifies. The description adds no behavioral context beyond the parameter list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It is not a well-structured sentence; it is just a parameter hint. There is no front-loading of purpose or action. The brevity does not serve the agent's needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description still fails to state the basic action the tool performs. With no output schema details available to the agent (though it exists, it is not provided), the description is wholly inadequate to invoke the tool correctly. An agent would have to infer intent from the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no enum or description for the 'shading_type' parameter, and schema description coverage is 0%. The description compensates partially by explicitly listing the allowed values (WIREFRAME, SOLID, MATERIAL, RENDERED), which tells the agent what inputs are valid. However, it does not explain what each value represents or any other semantic details, so it is only marginally helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a parameter definition listing 'shading_type: WIREFRAME, SOLID, MATERIAL, RENDERED' rather than a sentence explaining what the tool does. It restates the action implied by the name without explicitly stating 'Set the viewport shading mode to one of these values.' The verb and resource are only implied by the tool name, not 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like set_render_engine or get_viewport_screenshot. No context, prerequisites, or exclusions are mentioned. The agent has no idea when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only repeats the name, giving no information about side effects, state changes, or confirmations. An agent cannot infer what happens when this is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It lacks even a minimal sentence explaining the operation, so the structure provides no useful information to the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and a simple purpose, the description gives no clue about the effect, return values, or relationship to sibling tools like 'play_animation'. An agent cannot reliably predict the tool's behavior or output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per calibration guidance the baseline is 4. There is no schema to document, and the description adds nothing (and has nothing to add) about parameter behavior. This dimension is trivially satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Blender Studio Pro MCP: stop_animation', which merely restates the tool name with a provider prefix. It fails to state what the tool actually does (e.g., 'Stops the current animation playback in the viewport'), so it is a tautology with no functional meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'play_animation' or other animation controls. No context, prerequisites, or exclusions 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?
There are no annotations, so the description must disclose behavioral traits on its own. It fails to state whether this operation is read-only, what the return structure looks like, whether it may throw errors, or any side effects. The description provides zero behavioral information 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than appropriately concise. It is a single phrase with no structure, no front-loading of useful information, and no attempt to guide the agent. It reads as a placeholder rather than a deliberate, minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description gives no context about the compositor tree's structure, its relationship to other compositor tools, or any caveats. For a tool with significant implications (understanding a node graph), the description is woefully inadequate. It does not help an agent know what to expect or how the result should be interpreted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so there is nothing to explain. Per the rubric, a 0-parameter tool receives a baseline of 4. The description does not need to add parameter detail, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Blender Studio Pro MCP: get_compositor_tree' essentially restates the tool name with a context prefix. It identifies the resource ('compositor_tree') and the verb 'get' implies retrieval, but it adds no additional clarification about what the tree represents or what exactly is returned. It is slightly more than a pure tautology but still does almost nothing to differentiate the tool from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools like ensure_compositor, add_compositor_node, and set_compositor_node_input relate to compositor operations, but the description offers no hint about when get_compositor_tree is the right choice or any prerequisites.
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 of behavioral disclosure. It does not mention any side effects (e.g., file overwriting), required permissions, supported formats, directory creation behavior, or failure modes. The description is purely a high-level action with no behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single short sentence, which is efficient in wording. However, it is under-specified to the point of being minimally useful, lacking any structure or additional context. While there is no redundancy, the brevity is not 'appropriate' given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 4 parameters and 0% schema coverage, plus its position among many sibling export tools, the description is severely incomplete. It does not explain required parameters, formatting options, or how the tool behaves. An agent has virtually no context to decide if this tool is appropriate or how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for parameters, and the description does not mention any of the parameters (format, directory, individual, object_names). Without any explanation of what these parameters mean, how they interact, or their defaults, an agent cannot construct a valid call. The description adds no value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the core action ('Export objects to files') with a clear verb and resource. It is unambiguous but does not differentiate from sibling export tools like export_object or export_scene, relying on the 'batch' prefix to imply multiple objects. The purpose is clear but lacks explicit distinction from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its siblings. The description does not mention any conditions, prerequisites, or alternatives, and with many export-related tools in the sibling list, an agent cannot determine when batch_export is the appropriate choice over export_object or export_scene.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Report live Blender coverage' without stating what the report contains, whether it is read-only, the nature of 'live' data, or any side effects. This is insufficient for a tool with zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is deceptively short—one sentence with no wasted words—but this is under-specification rather than effective conciseness. It omits critical context and fails to front-load useful information. The brevity harms clarity rather than enhancing it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's zero-parameter simplicity and the existence of an output schema (which we cannot see), the description still fails to define what 'coverage' means or how the output should be interpreted. Without annotations, it is incomplete for an agent to use correctly. The description provides minimal context beyond the tool's name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter documentation to compensate for. Per the rubric, a baseline of 4 is appropriate when there are no parameters to explain. The description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Report live Blender coverage' with a clear verb and resource, but 'coverage' is ambiguous and undefined. It does not distinguish this tool from siblings like 'ping_blender' or status checkers. The name and description essentially restate each other with minimal added meaning, making the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context, no exclusions, and no mention of related tools. The description offers nothing to help an agent decide when to call this function.
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 of behavioral disclosure. It gives no information about what the tool does, side effects, requirements, or return behavior. For a tool that frames selected objects in the viewport, there is no mention of selection state or viewport changes. This is completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but contains no substantive content. It repeats the tool name with a product prefix, which does not earn its place. This is under-specification rather than effective conciseness; a single unhelpful sentence is not appropriately structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and an output schema, but the description gives no hint about the operation's effect or its return value. Framing selected objects in a viewport involves context like current selection and camera, none of which is mentioned. An agent cannot safely infer what happens when this tool is called, making the description severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter information to convey. Per the rubric, a zero-parameter tool receives a baseline of 4. The schema coverage is effectively 100% (vacuously), and no additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Blender Studio Pro MCP: frame_selected' merely restates the tool name with a product prefix, providing no verb or resource. It does not explain what the tool does or how it differs from sibling tools like frame_selected_objects or frame_all. This is a tautology, only marginally better than a missing 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context about typical scenarios, prerequisites, or exclusions is given. The description contains zero usage information, leaving the agent to infer intent purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral details. It does not disclose side effects, error conditions, return values, or requirements like the existence of the light. For a mutating operation with zero annotation coverage, the description fails to convey any behavioral transparency beyond the fact that it sets a property.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single sentence that states the core action. It is front-loaded and free of fluff, but it is under-specified. The brevity does not serve the agent because critical information about parameters and usage is omitted. It is not wasteful, but it sacrifices completeness for conciseness, earning a mid-range score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% schema coverage, no annotations, and a mutation tool with three required parameters, the description is grossly incomplete. It does not explain valid property names, how to specify the light, what values are acceptable, or what the output schema contains. An agent cannot reliably call this tool without additional context. The description provides almost no value toward correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema has no descriptions for name, property, or value. The description does not compensate by explaining these parameters. It does not clarify what valid property names are, how the light is identified, or what value format is expected. With no additional context, the agent must infer all parameter semantics from the property names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'a light's data block', indicating it modifies a light property. It is specific enough to distinguish from many other set_* tools, though it doesn't name the exact property types or the light identifier. It is a clear, single-purpose statement but lacks differentiation from other light-related setters like set_light_intensity (not present), which is mitigated by the general wording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or fallback tools. With many sibling tools like create_light, delete_light, and set_bone_property, the agent is left without context on when this specific setter is appropriate, making the description unhelpful for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Configure render output settings,' which implies a mutation but gives no detail on what exactly changes, whether settings persist, what side effects occur, or how the tool behaves. This is a significant gap for a setter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, so it is concise in length, but it under-specifies the tool. The sentence is generic and could apply to any configuration tool, failing to earn its place by adding useful information. Effective conciseness requires that every sentence adds value; this does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters with no schema descriptions, many render-related siblings, and an output schema (though not described in the description), the description is extremely incomplete. An agent cannot correctly invoke this tool without substantial additional information about parameter semantics and tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 parameters with 0% description coverage, and the description mentions none of them. It provides zero meaning beyond the parameter names, offering no guidance on valid values, defaults, or interactions. The description completely 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Configure') and resource ('render output settings'), indicating the tool sets output options. However, it does not differentiate from closely related siblings like set_render_settings or set_render_engine, which could cause confusion for an agent selecting among many render-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer when 'render output settings' are relevant.
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 must fully disclose behavior. It only states 'Call' which implies execution, but doesn't mention side effects, mutation, error conditions, context requirements, or that operators may fail if prerequisites aren't met. The execution_context parameter is not explained, and there's no indication of what happens upon success or failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but not appropriately sized. For a generic tool with four undocumented parameters, it omits critical information. While there are no wasted words, the terse style leaves the agent guessing. It's under-specified rather than concisely complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple params, no schema descriptions, no annotations, and an output schema that isn't referenced), the description is woefully incomplete. It lacks usage examples, parameter explanations, error handling, and return value info. An agent cannot reliably call this tool correctly based on the provided text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate by explaining parameters. It says nothing about idname, params, execution_context, or use_view3d_override. The agent has no idea what these mean or how to format them, making correct usage impossible without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: 'Call any Blender operator.' This is specific and distinguishes it from siblings that handle specific operators or batch calls, though it doesn't explicitly name alternatives. The phrase '100% bpy.ops surface' adds context about coverage but isn't necessary. It's better than a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many specialized operator tools (e.g., subdivide, bevel) or call_operators_batch. No conditions or exclusions are mentioned. The agent must infer that this is a catch-all for unsupported operators, which is not stated.
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 of behavioral disclosure. 'Export specific objects to a file' is essentially a restatement of the tool name and provides no information about side effects, file formats, error behavior, or requirements. It adds minimal value beyond the tautology.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is far too short to be 'appropriately sized' for a tool with three parameters and no annotation support. Conciseness is achieved at the expense of necessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a basic export operation but has an output schema and three parameters. The description omits all behavioral context, parameter details, and usage boundaries, making it inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (object_names, filepath, format). The agent gets no guidance on how to fill these fields, so the description adds zero value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (export) and resource (specific objects) to a file, which clearly conveys the core purpose. It implicitly distinguishes from export_scene by saying 'specific objects,' but it does not explicitly name alternatives or edge cases, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs. siblings like export_scene or batch_export. There is no mention of context or prerequisites, 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.
Behavior1/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 merely states 'Import a file' without mentioning side effects (e.g., what objects are added, whether existing data is modified), success/failure behavior, or required permissions. This 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one clause), which qualifies as under-specification rather than concise effectiveness. It does not front-load any scoping or behavioral detail that an agent needs, so the brevity is not earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no output schema explanation, and no annotations, the description is grossly incomplete. It does not address supported formats, import behavior, or any post-import consequences, making it inadequate for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers no explanation of the 'filepath' or 'format' parameters. It adds zero semantic value beyond the input schema, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Import') and resource ('a file into Blender'), making the tool's purpose unambiguous. However, it does not differentiate from siblings like import_image_as_plane or batch_import beyond being the generic version, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as import_image_as_plane or batch_import. No context is provided about appropriate scenarios, prerequisites, or exclusions, leaving the agent without direction.
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 must disclose behavioral traits. It merely says 'High-level dedicated category map + pointer to 100% bpy.ops bridge', which gives a hint about the output (a map and a pointer) but does not explain whether the tool queries live Blender state, returns static data, or has any side effects. It also does not clarify what '100% bpy.ops bridge' means operationally. The description is too abstract to convey meaningful behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using one sentence with two fragments. It is not verbose or padded. However, the terminology is not front-loaded with the most critical information (what the tool actually does); instead, it leads with abstract jargon. While it is short, the lack of clarity reduces its effectiveness as a structured summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and a presumed simple output (a list of categories), the description should at least state what the output is and how it relates to the other command-listing tools. It fails to explain what 'dedicated category map' means, what 'bpy.ops bridge' implies, or how this differs from sibling tools. The presence of an output schema helps, but the description does not provide enough context for an agent to correctly invoke it without confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (trivially, since no properties exist). The description adds no parameter information because there are none to describe. With 0 params, the baseline is 4, and the description does not need to compensate for any undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'High-level dedicated category map + pointer to 100% bpy.ops bridge' is vague. It implies the tool returns a category map and a link to bpy.ops, but does not clearly state that its primary function is to list tool categories. The name suggests listing categories, and the description hints at a 'map', but it fails to specify what categories are covered or what the output structure is. It is not a tautology, but it lacks a concrete verb-resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus siblings like list_operator_categories, list_dedicated_commands, or list_blender_commands. The description mentions a 'pointer to 100% bpy.ops bridge', but does not explain when a user should choose this over other listing tools. No alternatives, exclusions, or context for selection are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'configure active sculpt brush,' implying modification of brush properties but not disclosing whether it changes the active brush selection, requires an active brush, or has side effects. It does not mention error conditions or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but this is under-specification rather than conciseness. It lacks necessary details about parameters and constraints, so the brevity does not serve the agent's needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no structural information about them, the description is incomplete. It does not cover what the parameters control, what the output schema returns, or any setup steps. The agent cannot confidently invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description mentions none of the parameters. 'Configure' gives no indication what size, strength, and brush_name do. The agent must guess at semantics from the parameter names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Configure') and resource ('active sculpt brush'), distinguishing it from other sculpt-related tools like enter_sculpt_mode or list_brushes. However, it is vague about what 'configure' entails, leaving the exact operation unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., entering sculpt mode), nor does it contrast with other brush-setting methods. The agent must 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.
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 only says 'Add', which implies a mutation, but it does not mention side effects, whether the node group must exist, handling of duplicate names, idempotency, or error behavior. This is a significant gap for a tool that modifies state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded with the core action. However, it is so sparse that it omits critical details, making it under-specified. While there is no fluff, the conciseness comes at the cost of completeness, so it only partially earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters with no schema descriptions, no annotations, and only a minimal output schema hint, the description is grossly incomplete. An agent cannot correctly call this tool without knowing what values to provide for output_type, what qualifies as a node group, or what constitutes a valid output socket. The description fails to provide any of this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage—parameters are only named (output_name, output_type, node_group_name) with no types or descriptions. The description does not explain any of these parameters, their formats, expected values (e.g., valid output types), or how they relate to the operation. The description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Add a group-level output socket to a geometry node group.' This is a precise verb and resource, making the tool's purpose unmistakable. However, it does not explicitly differentiate from the sibling tool 'add_gn_group_input', though the name and context imply the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, when not to use it, or any prerequisite conditions. It simply states what the tool does, leaving the agent without context for selection among similar tools like 'add_gn_group_input' or 'add_geometry_node'.
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 of behavioral disclosure. 'Create a new action' reveals only the basic mutation but omits crucial details: whether it overwrites existing actions, whether it requires an object, what it returns, or any 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one short sentence, which is appropriate for a simple tool, but it sacrifices essential information. It does not bloat or mislead, so it earns a middle score for not being verbose, but it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool mutates state, has no annotations, and provides no parameter or behavioral detail, the description is inadequate for an agent to call it safely. It doesn't explain the action data block, prerequisites, or return value, making it incomplete for even basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single parameter `name` with no description, and schema description coverage is 0%. The tool description adds nothing about what `name` refers to (e.g., the action's name, format, uniqueness). Parameter semantics are entirely missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Create') and resource ('new action'), matching the tool's name and purpose. It doesn't explicitly differentiate from siblings like `assign_action` or `list_actions`, but the action of creating is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as `assign_action`, `list_actions`, or `push_action_to_nla`. The description gives no context about required preconditions (e.g., active object, mode) or intended workflow, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 does mention that if camera_name is not given, the scene's active camera is used, which is a useful default. However, it does not disclose what happens to existing UV maps, whether it overwrites them, if there are any mode requirements, or what the return value is. This is minimal disclosure for a tool that modifies UVs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is structurally simple. It is appropriately brief, but it is an under-specification rather than a concise summary of a complete definition. The lack of structured details (e.g., parameters, behavior) means it is not well-developed; however, for the length it is, it is efficient. Given the context, a 3 is reasonable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is not trivial: it has two parameters, requires an object and optionally a camera, and modifies UVs. With no annotations and an output schema that is present but not described, the one-sentence description is grossly incomplete. It does not mention prerequisites (e.g., object must have UVs), how the UV projection is computed, or what the result looks like. An agent cannot reliably use this tool based on the given information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (object_name required, camera_name optional), and schema description coverage is 0%. The description does not explain what object_name refers to (presumably the mesh object) or clarify camera_name beyond the default behavior. It adds no meaning beyond the parameter names, which is especially harmful given the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Project' and the resource 'UVs', along with the source ('from a camera or the scene's active camera'). This provides a clear purpose but does not explicitly differentiate from sibling tools like unwrap_uv or create_uv_map, which could also project UVs. The purpose is apparent, though not fully distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions. With many UV-related sibling tools (e.g., unwrap_uv, create_uv_map), the lack of usage guidance is a significant omission. An agent has no basis to select this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects (e.g., permanent mesh changes, requirement for modifier to exist, or failure behavior). This is nearly a restatement of the name, lacking any deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no waste. It is front-loaded with the core action, making it easy to scan. However, its brevity comes at the cost of critical detail, which is a separate concern; as a concise statement, it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters and no annotation or schema descriptions, the description is grossly incomplete. It does not explain what 'apply' means in Blender (e.g., baking the modifier into geometry), the need for an existing modifier, or potential errors. Even though an output schema exists, the operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions (0% schema coverage), and the tool description adds no meaning to 'object_name' or 'modifier_name'. It does not specify expected formats, valid values, or how the modifier is identified. The description 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('apply') and the resource ('a modifier to an object'). It distinguishes from siblings like add_modifier or remove_modifier by implying a specific operation (finalizing the modifier). However, it does not explicitly mention sibling alternatives or the exact effect, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., modifier must already exist), nor does it contrast with add_modifier or set_modifier_param. The agent is left to guess the appropriate 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 of disclosing behavior. It only says 'Render from multiple cameras sequentially,' but doesn't mention that it writes files to output_dir, may take a long time, overwrites existing files, or blocks. An agent cannot anticipate side effects or system impact from this description alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, which is concise, but it is far too sparse for a tool with six parameters. It front-loads the basic action but omits necessary detail, making it under-specified rather than appropriately concise. The structure is not aligned with the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, 0% schema coverage), the description is severely incomplete. It lacks instructions on camera name format, output directory requirements, accepted formats, sample ranges, and resolution constraints. Even though an output schema exists, the input parameters are undocumented, leaving an agent unable to construct valid calls. This is far below the minimum viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters, but it doesn't mention a single parameter. camera_names, output_dir, format, samples, and resolution dimensions remain completely unexplained. The description adds zero value beyond the raw schema, which itself lacks descriptions. This is a critical failure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Render') and resource ('multiple cameras') and adds the sequential aspect, which distinguishes it from single-render tools. However, it doesn't explicitly differentiate from sibling tools like render_image or render_turntable beyond that, so it's clear but not fully discriminating. A 4 is appropriate given the moderate specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as render_image, render_turntable, or batch_export. The description doesn't mention any context, prerequisites, or exclusions, leaving the agent to infer usage. This is a significant gap for a tool with multiple siblings that could overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 for behavioral disclosure. It only states that an object is created, but does not mention side effects like whether the new object becomes active, whether it appears in the scene, or if any selection changes occur. For a creation operation, these details are important but omitted. The description adds minimal value beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is under-specified rather than appropriately sized. It only states the obvious purpose and does not use the space to provide any additional useful information. This is more a case of under-specification than effective conciseness, as it fails to earn its place by adding value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters (1 required) and no schema description coverage or annotations, so the description must compensate. It does not explain valid types, transformation semantics, or any prerequisites. Although an output schema exists, the description lacks all context needed to call the tool correctly. This is completely inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the schema provides no explanation of parameters. The description only implicitly references the 'type' parameter but does not explain any of the five parameters (name, type, scale, location, rotation). It fails entirely to compensate for the schema's lack of detail, leaving the agent without any guidance on how to set these values or their meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Create' and resource 'object', and mentions 'specified type' which clarifies that the type parameter determines the object kind. However, it does not differentiate from numerous sibling tools like create_camera, create_curve, or create_light, which also create specific objects. It is clear in purpose but lacks distinction from alternatives, fitting the 'clear but no sibling differentiation' tier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many other creation tools (e.g., create_camera, create_light). No conditions, alternatives, or exclusions are mentioned. The description leaves the agent to infer the appropriate context, which is inadequate for a tool with such broad scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'push an action to the NLA editor as a strip,' implying a mutation but not stating side effects, reversibility, or what happens to existing strips. It also does not describe the return value despite an output schema being present. This is a significant gap for a potentially state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in length but fails to convey enough information to be useful. It is under-specified rather than appropriately concise; there is no front-loading of critical details, and the brevity detracts from usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool has four parameters, no annotations, and a non-trivial domain (NLA editor in a 3D application), the description is grossly insufficient. It does not explain the meaning of 'action', the relationship to the NLA system, or any required setup. An agent would be unable to correctly invoke this tool without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither the schema nor the description explains the four parameters (track_name, action_name, object_name, start_frame). The description adds no parameter information whatsoever, leaving the agent with zero semantic guidance for filling in these fields. This is a critical deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('push an action') and target ('NLA editor as a strip'), which is specific and distinguishable from vague operations. It does not explicitly contrast with similar tools like assign_action, but the phrasing itself makes the NLA focus evident. It lacks any mention of prerequisites or conditions, but the core 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like assign_action or list_actions. The description merely states what it does without contextual cues about typical use cases, prerequisites, or scenarios where it should be avoided. 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description must disclose side effects, preconditions, and return behavior. It only says 'Set the handle type' without mentioning whether the keyframe must already exist, whether it modifies in place, what happens if index is -1, or any error conditions. This is a serious omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, which is efficient. However, it is so terse that it under-delivers on the information needed, balancing conciseness against completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, four required, and no schema documentation or annotations, this description is wholly inadequate. It doesn't explain the data path format, valid handle type values, or how the frame is specified, leaving the agent without essential information to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage and the description provides no help with parameter meanings. It mentions 'handle type' and 'specific keyframe' but fails to explain the roles of object_name, data_path, frame, or index. An agent cannot infer what values are expected or how they combine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set handle type) and the target (a specific keyframe), which is distinct from setting interpolation. However, it does not explicitly differentiate from siblings like set_keyframe_interpolation, and it doesn't mention the need to identify the keyframe via object and data path, so it's clear but not maximally specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like insert_keyframe or set_keyframe_interpolation. The description gives no context on the appropriate scenario, prerequisites, or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 ('set') without revealing consequences (e.g., whether it overrides existing settings, requires specific permissions, or has side effects). The lack of detail about the operation's effects makes it inadequate 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is conducive to conciseness, but it is so under-specified that it provides virtually no useful information. While it is front-loaded and free of fluff, the brevity works against clarity. It earns a mid-range score because it avoids verbosity but fails to deliver substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and an output schema exists, but the description still omits essential context: valid engine values, effects on the scene, or any relationship to sibling tools. Without annotations or parameter explanations, an agent cannot reliably invoke this tool correctly. The completeness is poor given the lack of supporting detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'engine' with no type, description, or enums, and schema description coverage is 0%. The description does not compensate at all—it fails to explain what values 'engine' accepts (e.g., 'CYCLES', 'BLENDER_EEVEE') or the expected format. This is a critical gap for a parameter-driven tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set the render engine' uses a specific verb (set) and a clear resource (render engine), stating the core action unambiguously. However, it does not distinguish itself from similar siblings like set_render_settings or set_viewport_shading, so it falls slightly short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternative tools. No mention of context, prerequisites, or situations where a different command would be more appropriate. The description is a bare statement with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'add a constraint', but does not mention side effects (e.g., modifying the armature), requirements (e.g., being in pose mode, armature existing), error conditions, or return behavior. This leaves the agent without critical behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words, which is desirable. However, it is so terse that it omits essential context. It is not poorly structured, but it lacks the detail that would make it genuinely helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters including a nested extra_params object, and no annotations or parameter documentation. Even though an output schema exists, the description does not satisfy the need for usage context (e.g., required pose mode, constraint types available). The description is far too minimal for a tool that adds a constraint to a bone, leaving the agent to guess at crucial details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description provides no explanation for any of the four parameters (armature_name, bone_name, constraint_type, extra_params). The description does not compensate for the schema's lack of detail; it adds nothing about what constraint types are valid, what extra_params contains, or how names should be formatted. The agent must infer everything from the parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the target resource ('a pose bone'), which distinguishes it from the sibling tool 'add_constraint' (likely for objects). However, it doesn't specify the type of constraint or the required armature context, so while the core purpose is clear, it lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'add_constraint' or 'set_constraint_param'. There is no mention of prerequisites (e.g., selection state, pose mode) or typical use cases. The description gives no context for choosing this tool over similar ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior fully. It simply says 'Add an object constraint' which implies a mutation but does not state permissions, side effects, reversibility, or response format. The reference to CONSTRAINT_TYPES is ambiguous and does not clarify tool behavior. This is insufficient for a mutation tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two sentences), which is concise, but it is under-specified. It front-loads the main action but fails to provide any structure for parameters or usage. For a tool with five parameters, this is not appropriately sized; conciseness is undermined by lack of essential detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, no schema descriptions, no annotations) and the existence of related tools like list_constraints and remove_constraint, the description is incomplete. It lacks information about constraint types, parameter semantics, and any behavioral caveats. The output schema exists but is not described, so agents cannot know what to expect, further limiting completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must explain parameters. The description does not mention any of the five parameters (object_name, type, name, target, extra_params) or their meanings. It only alludes to constraint types but does not specify how to use them in the parameters. This is a critical gap that leaves the agent unable to form correct arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add an object constraint,' which is a specific verb (add) and resource (object constraint). It clearly indicates the operation, but does not explicitly differentiate it from sibling tools like add_bone_constraint or set_constraint_param. However, the name and action are sufficiently distinct to convey the primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It only says 'See CONSTRAINT_TYPES,' which is a reference to a list but does not explain when this tool is appropriate. No mention of when not to use it or alternatives, leaving the agent without decision 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 disclosing behavior. It only says 'add a node,' which implies a mutation but provides no detail on side effects (e.g., whether the group must exist, what happens on invalid node_type, whether existing nodes are affected). The description adds no behavioral information beyond the obvious intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action. However, it is too sparse—it does not leverage its brevity to convey additional necessary constraints or context. It is appropriately sized for the action but insufficient in content, making it only average.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 4-parameter tool with no schema descriptions and an output schema (not visible), the description is severely incomplete. It omits crucial information such as available node types, default behaviors, requirements for the node group, and error conditions. An agent would not be able to reliably invoke this tool without consulting other sources or guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and no parameter descriptions, and the tool description says nothing about the parameters (node_group_name, node_type, name, location). The agent is left without any explanation of what these parameters mean, what valid node types exist, or how to format location. The description completely 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: adding a node of a given type to a geometry node group. This distinguishes it from compositor, shader, and constraint node tools by specifying the context (geometry node group). However, it does not explicitly differentiate itself from similar 'add' tools like add_gn_group_input or add_compositor_node, so it lacks explicit sibling discrimination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many other node-adding or geometry-node tools (e.g., connect_gn_nodes, set_gn_node_input, add_gn_group_input). The tool name implies it is for adding a node to a geometry node group, but no explicit conditions, prerequisites, or alternatives are given. An agent must 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 must carry the full burden of behavioral disclosure. It does not mention side effects, requirements (e.g., whether the modifier must exist), or consequences (e.g., whether the modifier is removed after applying). The description simply restates the action without revealing operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words, which is concise. However, it achieves brevity by omitting essential details, so it is structurally simple but under-informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, an output schema, and a 0% descriptor coverage in the schema. The description is critically incomplete: it fails to clarify object targeting, modifier existence, expected output, or error conditions. Given the many related geometry nodes operations, the description is inadequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. object_name and modifier_name are not explained; the default null for modifier_name is left ambiguous. The description fails to compensate for the sparse schema, leaving agents without necessary semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Apply a Geometry Nodes modifier on an object.' It is distinct from the generic apply_modifier sibling by specifying geometry nodes, so an agent can identify the tool's purpose. However, it does not elaborate on what 'apply' entails (e.g., finalizing vs. baking), which slightly limits clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like apply_modifier or create_geometry_nodes_modifier. No context, prerequisites, or exclusions are provided, leaving the agent to infer usage without supporting 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?
There are no annotations, so the description carries full responsibility for disclosing side effects. It only says 'assign' without indicating whether the operation is reversible, whether it requires existing action and object, what happens if either is missing, or what the return value is. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is technically concise, but it under-specifies the tool's behavior. It is not front-loaded with the most important constraints or any usage context. The brevity is harmless but insufficient; a more informative description would need more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 required params) and presence of an output schema (which might hint at return type, but the description doesn't explain it), the description is still incomplete. It omits prerequisites (e.g., object and action must exist), expected side effects, and errors. Without this context, an agent may call it incorrectly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the tool description adds no value about the parameters. The names 'action_name' and 'object_name' are self-explanatory but the semantics of assignment (e.g., how the action is linked to the object, constraints on inputs) are entirely undocumented. Baseline for zero coverage is low, and the description does nothing to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('assign') and the two involved objects ('an action', 'an object'). It is unambiguous as a basic action, but it does not differentiate among sibling tools like create_action or push_action_to_nla, and lacks any detail on the nature of assignment (e.g., active, NLA, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not mention alternatives, prerequisites, or scenarios where this tool should be preferred over list_actions, create_action, or push_action_to_nla. An agent gets no help deciding between these 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?
No annotations are provided, so the description carries the full burden. It says 'assign' but does not disclose whether this replaces the existing material, affects the active material slot, or requires specific object types. The outcome and side effects are unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded with the action, but it lacks any structure such as usage notes or caveats. It is appropriately short but offers no additional organized information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and no annotations, the description is minimal but still leaves significant gaps: no mention of output, side effects, or preconditions. An agent calling this would likely need to guess whether it assigns by name to a specific object or works on the current selection. It is incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only repeats the parameter names implicitly. It adds no meaning about the expected format or semantics of object_name and material_name, such as whether they are names, paths, or IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('assign') and resource ('material to an object'), making the core purpose clear. However, it does not differentiate from sibling tools like set_material_slot or apply_material_to_all, which could also assign materials, so it misses an opportunity to disambiguate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as set_material_slot or apply_material_to_all. An agent has no indication of selection criteria or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It says 'bake' but does not explain side effects (e.g., modification of simulation caches), what happens if baking is not possible, or any performance/irreversibility implications. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified rather than concise. It lacks critical context and clarity, making it insufficient for proper tool selection and use. The brevity does not serve the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema but the description does not hint at what is returned. It also fails to explain the baking context (e.g., which objects, what caches), leaving the agent without adequate information to call it correctly, especially given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, object_name, has no description in the schema (0% coverage) and the tool description does not clarify its meaning, expected format, or whether it is optional. The agent is left completely in the dark about this parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Bake') on specific resources ('rigid body / point cache'), which distinguishes it from unrelated siblings like bake_texture. However, the phrase 'where possible' introduces ambiguity about conditions and scope, so it is not fully precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent cannot determine whether it should be used before rendering or after setting up physics. This is a clear 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 carries the full burden of behavioral disclosure. Arbitrary code execution is a high-risk operation with genuine destructive potential, yet the description says nothing about error behavior, execution context (bpy availability), synchronicity, side effects on the scene, or return value semantics. Even though an output schema exists, the agent is left blind to the risks of running arbitrary code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient and front-loaded, with no wasted words. However, it is under-specified rather than appropriately concise for a tool of this power—conciseness earned through brevity, not through dense, high-information packing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity and risk of arbitrary code execution, paired with absent annotations and 0% schema coverage, this is critically incomplete. An agent has no way to know the execution environment, safety implications, or how to interpret results. For one of the most powerful tools in the set, the description provides almost no operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds nothing about the `code` parameter. The agent gets no information about whether it should pass a full script, an expression, what modules/variables are in scope, or how to structure output. For a single-parameter tool with zero schema coverage, the description must fully compensate and it does not at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair ('Execute arbitrary Python code') and the 'arbitrary' keyword explicitly marks this as the general-purpose escape hatch, distinguishing it from the 150+ specialized sibling tools. It avoids tautology, though it could more explicitly frame itself as the fallback for operations no dedicated tool covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus the many specialized siblings. With tools like set_transform, create_object, and add_modifier available, an agent needs to know this should be a last resort for uncovered cases, not a first choice. No conditions, no exclusions, no alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that it returns information, implying a read-only operation, but does not explicitly confirm no side effects, permissions needed, or any limitations. For a get/info tool, more transparency about what 'detailed information' includes would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, a single sentence with no waste. However, it is under-specified; conciseness should not come at the cost of essential information. It earns a midpoint because it is short but leaves out important context that could be added without much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (so return format is covered), the description lacks context about the scope of 'detailed information' and the behavior for missing cameras. It does not mention whether the camera name is required or how it is resolved. For a simple info-getter, more context about usage would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to the only parameter, camera_name. It does not mention the parameter at all, leaving the agent to assume it is a string identifier. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (return) and the resource (detailed information about a camera). It is distinct from sibling tools like list_cameras (which lists all) and set_camera_lens (which modifies). However, it could be more specific by naming the required camera_name parameter to explicitly indicate which camera is targeted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool over alternatives, nor does it mention any preconditions or edge cases (e.g., what happens if the camera does not exist). The agent must infer that this is for fetching details about a named camera from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 says 'Return detailed information' without disclosing what 'detailed' entails, whether the operation is read-only beyond the implied 'get', or what happens if the object doesn't exist. The minimal verb phrase offers little behavioral context beyond the tool's basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is efficient and appropriately sized for a getter tool, though it sacrifices semantic depth. Structure is clean and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description is incomplete for effective use. It fails to clarify what kind of object 'name' refers to, what 'detailed information' includes, or how this differs from other get_*_info tools. The agent would likely need to inspect the output schema or guess the parameter semantics, making this inadequate for a tool among many similar siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'name' with no description, and schema description coverage is 0%. The description does not explain what 'name' refers to (e.g., object name as a string), its format, or any constraints. With zero coverage and no compensation from the description, the parameter semantics are completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Return') and resource ('detailed information about a specific object'). It is distinct from sibling tools like get_world_info or get_scene_info, but the term 'object' is generic and doesn't specify which kind of object (mesh, camera, light, etc.), leaving some ambiguity. It is functional but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling get_*_info tools (get_camera_info, get_material_info, get_mesh_stats, etc.). The description does not mention context, alternatives, or exclusions, leaving the agent to guess which 'object' type this 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 provided, the description must fully disclose behavioral traits. It only states the high-level action (import as textured plane) but does not mention side effects, whether it modifies existing objects, whether it requires specific file formats, or what happens on failure. It does not describe any state changes or call requirements, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a single sentence that is front-loaded with the core action. However, it is under-specified, missing essential operational details. While it does not waste words, it sacrifices completeness for brevity, making it less useful than a slightly longer but more informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters), the description is incomplete. It lacks any information about the location parameter, the filepath requirements, what the tool returns (despite having an output schema), and any preconditions. The absence of guidance on parameter semantics and behavioral expectations leaves the tool under-documented for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no information about the parameters 'filepath' or 'location'. The filepath's expected format, supported image types, or default behavior of location are entirely unexplained. The description fails to compensate for the lack of schema details, making it impossible for an agent to correctly populate the parameters without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Import' and the resource 'an image file as a textured plane', which is a specific and understandable purpose. It distinguishes itself from the generic sibling 'import_file' by specifying the result is a textured plane. However, it does not elaborate on what 'textured plane' implies (e.g., does it create a new object, apply a material?), so it is not fully explicit about its exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'import_file' or other import-related tools. There is no mention of prerequisites, restrictions, or situations where this tool is preferred. An agent would have to infer the intended use case from the tool name alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states 'Join multiple objects into one' but does not mention side effects (e.g., whether original objects are removed, whether selection is required, whether the join is destructive). This is insufficient for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is concise, but it omits essential information. It is under-specified rather than efficiently structured; the brevity comes at the cost of clarity and usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no annotations, and no useful schema, the description is far from complete. It does not explain what the tool returns, how the join is performed, or any constraints. This is inadequate for an agent to call it correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'object_names' has no schema description (0% coverage), and the description adds no meaning beyond the parameter name. It does not specify whether it expects a list, comma-separated string, or the exact object identifiers. The description fails to compensate for the lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('join') and resource ('multiple objects into one'), which adequately conveys the core action. It is not a tautology and is distinguishable from siblings like create_object or delete_object. However, it does not explicitly contrast with related tools or elaborate on the scope of 'objects'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites (e.g., objects must be mesh or selected), and no exclusions. The description leaves the agent to infer context, which is problematic in a large toolset.
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 bears full responsibility for disclosing behavior. It only says 'Remesh mesh' without mentioning that it modifies the mesh's topology, whether the operation is destructive, or what the output looks like. This fails to convey essential behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the action, which is good, but it is so under-specified that it reads like a stub rather than a deliberate concise description. The list of modes is useful but not structured with any context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has three parameters, no schema descriptions, and no annotations, the description is far from complete. It omits explanations of mode behavior, voxel_size semantics, and any side effects, leaving an agent unable to use it correctly without extra context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It enumerates the 'mode' values but doesn't explain what each does, and 'voxel_size' is not mentioned at all. The description adds minimal meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remesh mesh') and lists specific modes, so an agent knows it reshapes a mesh. However, it doesn't differentiate from other mesh operations like subdivide or bevel, nor does it specify that it acts on the selected object or the 'object_name' parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other mesh-editing tools, nor any mention of prerequisites or context. The modes are listed but without any explanation of appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Search' without noting rate limits, authentication, pagination, or whether results are returned in a specific format. It doesn't contradict any annotations (none exist), but it provides minimal behavioral context beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, but it is under-specified rather than appropriately sized. A single sentence is acceptable for a simple tool, but given the four parameters and lack of parameter explanations, it omits necessary information, making it insufficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which reduces the need to describe return values), the tool has four parameters with no explanations, no annotations, and no usage context. The description is too sparse to allow correct invocation without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not mention 'query', 'count', 'categories', or 'downloadable' at all, leaving the agent to rely on defaults and types. This adds no semantic value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Search') and resource ('Sketchfab for 3D models'), effectively distinguishing it from siblings like 'download_sketchfab_model' and 'get_sketchfab_status'. However, it doesn't hint at any filtering or scoping capabilities, so it's clear but not deeply 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when to search vs. download or check status, nor any exclusions. The agent must infer usage 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 must disclose behavioral traits itself. It reveals that it is a mutation ('Set') and requires edit mode, which are useful constraints. However, it does not mention side effects, error conditions (e.g., what happens if not in edit mode), whether the bone must be selected, or the nature of the return value. This is minimal disclosure 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words, which is concise. However, it is under-specified to the point of being terse; the brevity is not earned because it omits essential information. While structure is clean, the content is insufficiently elaborated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 required parameters, no enum definitions, and zero schema description coverage, this description is severely incomplete. It does not provide a way to know valid property names, value formats, or any related resources like a list of properties. The existence of an output schema is not mentioned, and the tool appears to require background knowledge that an agent would lack. This is far from enough to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the parameters. It does not explain what values 'property' can take, what types 'value' accepts, how to specify armature_name and bone_name, or any relationships between parameters. The agent has no guidance beyond parameter names, which are generic and ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('a property on a bone') with a contextual constraint ('in edit mode'). It distinguishes from sibling bone tools like add_bone or add_bone_constraint, though it does not explicitly name alternatives. The purpose is specific enough to not be confused with other operations, but lacks detail on what 'property' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor are any prerequisites beyond 'edit mode' mentioned. There is no mention of what situations would make this inappropriate or what other tools might be better suited (e.g., set_custom_property for custom properties). 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.
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 says 'Set various render settings' which implies mutation but gives no details on side effects, persistence, error behavior, or whether settings apply immediately. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no unnecessary words, so it is concise. However, it is also severely under-specified; it is concise at the expense of substance. The sentence is front-loaded with the verb, but it lacks any detail that would aid an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 undocumented parameters and no annotations, the description is grossly insufficient. An agent would not know which settings can be changed, what values are valid, or what the tool actually does beyond the bare claim. The output schema exists but does not compensate for the lack of input guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions no parameters by name or meaning. All 7 properties (samples, denoiser, use_bloom, etc.) are completely undocumented in both the schema and the description. The description offers zero help in understanding what values are expected or how they map to render settings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Set') and resource ('render settings for the active scene'), making the tool's purpose unambiguous. It does not name sibling tools like set_render_engine or set_render_output, but the phrase 'render settings' generally covers them, so an agent can infer the scope without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus siblings such as set_render_engine, set_render_output, or set_color_management. It does not mention any context, prerequisites, or exclusions. The agent is left to guess whether this tool handles all render settings or only a specific subset.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 should carry the full burden of disclosing side effects and behavioral traits. It only states the action ('Unwrap UVs') without mentioning that this modifies the mesh's UV data, whether it is destructive to existing UVs, or whether any services are called. The lack of any behavioral detail beyond the bare operation makes it inadequate 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff, which is structurally concise. However, it is under-specified rather than appropriately concise; it lacks essential details while being short. It does not front-load critical information like parameter guidance or usage context beyond the core action, so it barely meets the minimum for this dimension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no annotation coverage, and no parameter descriptions in the schema, the description must compensate substantially. It does not explain what the method is, what angle_limit or island_margin do, or whether correct_aspect has any effect. The presence of an output schema does not mitigate the missing parameter semantics. This leaves the tool underdocumented for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has five parameters with zero description coverage, yet the description adds no meaning to any of them. It mentions 'specified method' but does not explain method values or any of the other parameters (angle_limit, island_margin, correct_aspect). An agent has no idea what these parameters control or how to set them appropriately, making the tool effectively unusable without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool unwraps UVs for a mesh object with a specified method, which distinguishes it from siblings like create_uv_map (creating a new UV map) and project_from_view. The verb 'unwrap' is explicit and the target resource 'UVs' is clear. However, it does not name alternatives or explicitly contrast with sibling tools, so it falls 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as project_from_view or create_uv_map. It does not mention prerequisites, like whether the object must be in edit mode or have an existing UV map, nor does it suggest typical use cases. The agent is left to infer appropriate usage from the action description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states that it adds a driver, implying mutation, but does not explain side effects (e.g., overwriting existing drivers, dependencies, or required context). The minimal description is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and front-loaded with the core action, which is good for conciseness. However, it is too short to convey necessary usage and parameter context, making it under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no annotations, and a potentially complex effect (drivers in Blender), the description is grossly incomplete. It fails to cover parameter semantics, usage context, or behavioral nuances, leaving the agent without adequate information to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (coverage 0%), so the description must compensate. It only gives an example for data_path, leaving object_name, index, and expression unexplained. This is a notable gap for a multi-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a driver to an object property.' It identifies a specific verb and resource, and the example 'data_path e.g. 'location'' helps convey intent. However, it does not distinguish this from similar tools like set_custom_property or remove_driver beyond the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like remove_driver or set_custom_property. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'Append a datablock' without explaining side effects, whether existing datablocks are overwritten, what happens on failure, or any permissions required. It does not mention the source blend file or that it loads from an external file. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the action, which is efficient. However, it uses only one line and under-specifies, making it more under-specified than appropriately concise. The examples are useful but the brevity sacrifices critical details. It reads more like a placeholder than a finalized description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 3 required parameters, no annotations, and no schema descriptions, so the description must carry the full burden of contextual explanation. It fails to explain the purpose of filepath, the format of the directory and filename beyond examples, or any behavioral context (e.g., does it work only with .blend files? Does it require the directory to be inside a blend? What happens if a datablock already exists?). It is far from complete for an agent to reliably invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description coverage (no types, no descriptions, just titles), so the description must compensate. It gives examples for 'directory' and 'filename' but completely omits 'filepath', which is a required parameter. The agent is left to infer what filepath means. Partial coverage, but the most ambiguous parameter is undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action 'Append a datablock' and distinguishes it from the sibling link_from_blend by using 'append' rather than 'link'. It also provides concrete examples for directory and filename, giving some sense of the expected input format. However, it does not explicitly mention filepath, which is a required parameter, so the overall purpose is clear but the scope is incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives format examples but no guidance on when to use append_from_blend versus alternatives like link_from_blend. It does not state any conditions or contexts where this tool is preferred. The only hint is the word 'append' implying a copy vs. link, but that is not articulated, leaving the agent without explicit routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that operators are run 'in order', but does not disclose whether execution is atomic, what happens on failure, whether results are returned, or if there are side effects beyond the operators themselves. The presence of an output schema (though its content is unseen) does not compensate for the lack of behavioral context in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence, which is not appropriately sized for a tool with a non-trivial parameter structure and no other documentation. It is under-specified rather than concisely complete. While it is front-loaded with the main action, it omits critical details, so it earns a low score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—one required parameter, no parameter description, no annotations, and no explanation of expected return values—the description is severely incomplete. An agent cannot determine how to format the 'calls' argument, whether operators are invoked sequentially with dependency handling, or how errors are reported. The description does not suffice for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single required parameter 'calls' with no description and 0% schema coverage. The tool description says 'run multiple operators' but does not explain the structure of the 'calls' parameter—e.g., is it an array of operator call objects, and what fields do they contain? An agent cannot construct a valid call without additional information, so the description adds minimal value beyond the schema's bare name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'run' and resource 'multiple operators', and specifies ordering with 'in order'. This clearly conveys the core function and differentiates it from the singular 'call_operator' sibling. However, it does not explicitly name that sibling or elaborate on what constitutes an 'operator' in this context, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Sibling tools include 'call_operator' for single operations and various batch tools (e.g., 'batch_render', 'batch_import'), but the description offers no exclusions, prerequisites, or criteria for choosing this over them. An agent cannot infer when batching is appropriate or how it differs from repeated 'call_operator' invocations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states that it sets properties. It does not indicate whether the material or node must exist, whether it creates them if absent, what happens if a property is not applicable, or whether it overwrites or merges values. The side effects and error behavior remain 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is syntactically concise, but it is under-specified for a tool with 16 parameters and no other context. It is not front-loaded with critical information—it merely restates the tool's core action without enriching it. The brevity does not compensate for the missing guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (16 parameters, no annotations, no output schema details), the description is woefully incomplete. An agent cannot determine when to use it, what prerequisites exist, what each parameter does, or what the expected result or errors are. The description fails to provide enough context for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meaning, but it does not mention any of the 15 properties (e.g., ior, alpha, metallic). The parameter names are self-explanatory to those familiar with the Principled BSDF node, but the description adds no value beyond what the schema already provides, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('set') on a specific resource ('Principled BSDF node properties on a material'), which clearly distinguishes it from generic material creation or assignment tools. However, it does not explicitly differentiate from overlapping siblings like set_shader_node_property or set_shader_node_value, so it misses some sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., an existing material with a Principled BSDF node) or scenarios where another tool like set_shader_node_property would be more appropriate. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 without any detail on side effects, return values, constraints, or what happens on conflict (e.g., whether the modifier is appended or replaces an existing one). This is insufficient for an agent to predict consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero filler, front-loaded with the verb and resource. It is appropriately concise, though so brief that it borders on under-specification. For conciseness alone, it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of modifier-related tools and the complete lack of parameter documentation, this description is inadequate. It does not specify the modifier types, whether the object must already exist, or the purpose of extra_params. Even though an output schema may exist, the agent still lacks the essential context to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter. The properties (name, type, object_name, extra_params) are bare in the schema, and the description adds nothing about what 'type' means (presumably modifier type), what 'object_name' targets, or how 'extra_params' should be structured. The agent has no semantic guidance beyond the field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add a modifier to an object.' which clearly identifies the verb (add) and the resource (modifier on an object). It is direct and unambiguous, though it does not explicitly differentiate from similar modifier tools like set_modifier_param or apply_modifier, but the verb 'add' is distinct enough. Lacks specificity about which modifier types are supported, so not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus sibling tools such as set_modifier_param, remove_modifier, apply_modifier, or list_modifiers. There is no context about prerequisites, conditions, or alternatives, leaving the agent without 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?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, requirements (e.g., existing nodes or materials), or failure behaviors. The phrase 'via their sockets' adds minimal insight, and no other behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the core action and resource, making it easy to scan. However, its brevity borders on under-specification, though it is not redundant or verbose, so it merits a 4 for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five required parameters and no parameter descriptions, this description is severely inadequate. It provides no information on how to reference nodes or sockets, whether they are names or indices, or any context about the shader node tree. Even with an output schema, the input semantics are completely undocumented, making it nearly impossible for an agent to call correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with no descriptions (0% coverage), and the description does not explain any of them. The parameter names (material_name, from_node, from_socket, to_node, to_socket) give some hint of their intent, but there is no format, type, or reference information. The description adds almost no value beyond the schema's titles, leaving the agent to guess at valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Connect two shader nodes via their sockets' clearly states a specific verb and resource, and it distinguishes itself from the sibling tool 'disconnect_shader_nodes'. However, it lacks any additional context about the types of shader nodes or constraints, so it is clear but not detailed enough for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like connect_gn_nodes or connect_compositor_nodes. It does not mention any prerequisites, exclusions, or situations where this tool is preferred. Without this, the agent cannot reliably select it from the many similar connection 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 provided, the description carries the full burden of behavioral disclosure. It states the core side effect of adding the camera to the scene, but it does not mention whether the camera becomes active, how names are handled, or any implications for existing cameras. This is minimal and leaves important behavior undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It is efficiently worded and front-loaded with the core action, though it omits necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are 4 parameters with no descriptions and no annotations, the description is far from complete. It provides no explanation of parameter defaults, naming behavior, or whether the camera is made active. The output schema exists but does not compensate for the missing parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for lens, name, location, or rotation, only titles and defaults. The description does not compensate by explaining any of these parameters, so an agent has no way to understand what values to supply or their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (camera) and that it is added to the scene. It is distinct from sibling tools like set_camera_lens (modifies an existing camera) and list_cameras (queries cameras), so an agent can tell it apart from those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as set_camera_lens or set_active_camera. There is no mention of prerequisites, ordering, or when a new camera is needed instead of modifying an existing one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the action without mentioning side effects, failure conditions, permissions, or whether the collection name must be unique. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that efficiently communicates the core action, with no unnecessary words. It is front-loaded and easy to parse, though its brevity contributes to the lack of context that penalizes other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one required parameter and no annotations, so the description should provide sufficient context for correct invocation. It fails to mention prerequisites like an active scene, error conditions, or how this differs from similar collection tools. The presence of an output schema reduces the need for return-value explanation, but the overall usability guidance is still lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the 'name' parameter. It does not: it adds no information beyond the schema's title 'Name', leaving naming conventions, restrictions, or meaning undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'a new collection', and adds the linkage to the active scene, which conveys the core action. However, it does not explicitly differentiate from sibling tools like create_collection_hierarchy or instance_collection, so it stops short of a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as create_collection_hierarchy, instance_collection, or move_to_collection. The description gives no context on prerequisites, scenarios, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavioral traits. It only states 'Create' implying object creation, but does not mention side effects (e.g., whether the new object becomes active, coordinate system used, or return value). Critical behavior is left unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action. It is not verbose and includes an extra version hint, making it efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with two parameters and no annotations, the description is insufficient. It lacks usage context, parameter semantics, and behavioral disclosure. While an output schema exists (per context signals), it does not cover these gaps, 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter information. The schema only includes titles and default values (name, location), which are minimal. The description does not explain what these parameters mean in the context of grease pencil, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Create' and the resource 'grease pencil object', making the tool's purpose clear. It adds a version compatibility note (Blender 4+/5) which is useful, but it does not explicitly distinguish from generic creation tools like create_object, though the name alone provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as create_object or other object-creation tools. No prerequisites, scenarios, or exclusions are mentioned, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states the act of creating and adding a light, but gives no detail on side effects, selection behavior, failure modes, or whether existing lights are affected. The minimal wording does not adequately disclose 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the verb and resource. It contains no filler words or repetition. However, its structure is minimal—a single sentence with no sub-clauses or additional explanation—which limits its usefulness despite the brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters with zero schema coverage, no annotations, and an output schema whose content is unknown, the description is severely incomplete. It does not explain return values, scene impact, default behaviors, or how the tool interacts with the broader scene. This is well below what an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It only mentions 'type' without explaining the meaning of the other five parameters (color, energy, location, rotation, name). The schema itself lacks types and descriptions, so the agent has no way to infer parameter semantics from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Create') and resource ('light'), and mentions the 'type' parameter, which is a key differentiator. However, it does not distinguish from sibling tools like create_three_point_lighting or set_light_property, so the agent must infer context from the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_three_point_lighting or set_light_property. There is no mention of prerequisites, target scene state, or which type values are acceptable. The agent is left to guess the appropriate 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 of behavioral disclosure. It only says 'Delete an object by name' without stating that the operation is destructive, irreversible, or what happens if the object does not exist. It also does not mention potential side effects (e.g., removal of related data). The description is minimal and does not adequately disclose behavior 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is immediately readable and front-loaded with the verb. However, it is underspecified; while conciseness is good, it sacrifices necessary context. It earns a mid score because it is compact but lacks important usage and behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that output schema exists, return values are covered. However, the description does not explain the scope of 'object' (e.g., mesh, light, camera), whether it requires the object to be selected or named exactly, or any consequences of deletion. For a delete operation, the description is incomplete and would leave an agent unsure about what constitutes a valid target.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not elaborate on the 'name' parameter. It does not specify what kind of name (e.g., object name, unique identifier), any format or validation, or how to reference the object. The parameter is left entirely ambiguous, and the description adds almost nothing beyond the schema property label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Delete') and resource ('an object') with the manner ('by name'). It is clear what the tool does. However, it does not differentiate itself from sibling deletion tools like delete_collection or delete_material beyond the generic term 'object'; the name itself provides that distinction. The purpose is clear, but it leaves the exact type of object 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not state the context (e.g., object must exist in the scene), any prerequisites, or when to prefer other deletion tools. There is no mention of exclusions or alternatives, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the action but does not clarify whether it removes all links to the input, what happens if no links exist, whether the operation is reversible, or any side effects. This is a mutation tool with minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that directly conveys the core function. It is appropriately concise and not verbose, though it could include additional details without significant overhead. It earns its place by stating the primary action clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values may be documented externally, but the description does not mention any error conditions, required valid inputs, or the scope of the removal (all links vs. one). For a 3-parameter mutation tool in a shader context, the description is insufficiently complete for an agent to use it reliably without external examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for all three parameters (material_name, node_name, input_name). The description does not explain the role of any parameter or their relationships (e.g., that material_name locates the shader node tree). The agent cannot infer what values are expected or how they map to the action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('remove') and resource ('links connected to a specific input on a node'), and implicitly distinguishes it from the sibling connect_shader_nodes. It is unambiguous about the core action, though it could explicitly mention shader nodes, but the tool name and siblings make that context clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as connect_shader_nodes or set_shader_node_value. There is no mention of prerequisites, typical scenarios, or exclusions. The agent is left to infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It states it imports into the current scene (implying mutation), but doesn't disclose network requirements, potential overwriting, link vs append behavior, or what happens to existing objects. For a download tool that modifies the scene, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is extremely short and front-loaded with the core purpose, which is positive. However, it is under-specified rather than efficiently concise, as it omits all parameter and behavioral detail that the tool requires. It earns its place for purpose but not for guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters (two required), no annotations, and an output schema that is not described, the description is incomplete for an agent to call this tool correctly. It fails to explain what values asset_type accepts, what resolution options exist, or what the import result is. The tool is complex enough that such minimal text is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters, but it doesn't mention any. asset_id, asset_type, and resolution are left undefined; even the meaning of asset_type (e.g., hdri, texture, model) is not hinted at. The description adds no value beyond the schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase ('download and import') with a clear resource ('Poly Haven asset') and target ('current Blender scene'). It distinguishes from siblings like search_polyhaven_assets (search) and download_sketchfab_model (different source) by naming the exact asset source and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It doesn't mention that this is the step after searching Poly Haven assets, nor contrasts with downloading Sketchfab models. Usage context must be inferred from the tool name and sibling list, which is not dependable.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 says 'check' and 'return their info' but does not state whether the operation is read-only, what happens if the object doesn't exist (error vs empty result), or the structure of the returned info. This leaves significant ambiguity for a safety-conscious agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is appropriately concise for a simple tool. However, it lacks any structural cues (e.g., emphasizing the required parameter or potential return shape) and is so brief that it sacrifices clarity, making it merely minimum-viable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no annotations, and no schema descriptions, the description is incomplete. It does not address edge cases (missing object), output format beyond 'info', or any prerequisites. An agent cannot confidently call this tool without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (only a title 'Object Name' is given). The description does not mention object_name or its format/requiredness beyond the schema itself. The parameter name is self-explanatory, but with zero coverage the description should add context, which it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Check') and resource ('Geometry Nodes modifiers') and implies a status-checking role distinct from siblings like get_gn_node_tree (tree inspection) or list_modifiers (all modifiers). However, it does not explicitly name alternatives or scope out what 'info' entails, so it's clear but not perfectly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs the many Geometry Nodes-related siblings (e.g., get_gn_node_tree, apply_geometry_nodes). The purpose itself suggests a use case, but there are no explicit when-to-use/when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 says 'Return' which implies a read-only operation, but it does not explicitly state there are no side effects, what happens if the material doesn't exist, or whether the full tree includes hidden or disabled nodes. The behavior beyond the return content is undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, correctly front-loaded sentence with no wasted words. It is appropriately concise, though it could include more informative details without becoming verbose. The structure is clean and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need not be detailed, but the description is incomplete in essential aspects: it omits the meaning of the single required parameter, does not state any prerequisites (e.g., material must exist), and gives no usage context among the many node-related sibling tools. For a tool that returns a complex tree, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'material_name' parameter at all. The agent has no explanation of what material_name refers to, how to specify it, or any format requirements. The description adds zero value for parameter understanding, leaving the parameter completely undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the full node tree with nodes, inputs, and links. The verb 'Return' and resource 'shader node tree' are specific. It implicitly differentiates from sibling tools like 'get_gn_node_tree' (geometry nodes) and 'get_compositor_tree' by the word 'shader', but does not explicitly name the alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With many sibling tools for different node trees (geometry, compositor, shader), the description does not state to use this for material shader trees or mention any exclusions. The agent is left to infer 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?
No annotations are provided, so the description must carry behavioral transparency. It only says 'List item names' with no details about side effects, error handling, return format, or performance implications. It does not contradict any annotations (none exist) but provides 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler words, making it structurally concise. However, it is too sparse for the tool's complexity, as critical parameter details are absent. It is not verbose, so it scores well on conciseness, but the failure to include necessary information reduces its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a required parameter and an output schema, but the description neither explains the valid 'data_type' values nor the effect of 'limit'. An agent cannot determine what input to provide or what output to expect beyond the bare name listing. Incomplete even for a simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description gives no explanation of the two parameters ('data_type' and 'limit'). Without any description of what values are valid or how they affect the result, an agent cannot correctly call the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('item names in a bpy.data collection'), but does not clarify which collection corresponds to 'data_type'. It is distinguishable from sibling 'list_data_types' (which lists type names, not item names), though not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool, what arguments to pass, or how it differs from alternatives. Only a bare statement of function, with no context about typical 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?
With no annotations provided, the description carries the full burden of disclosing behavior, yet it only states the basic action. It does not mention potential side effects (e.g., overwriting files, blocking the UI), asynchronous nature, or return value expectations. For a tool that performs a potentially long-running render, this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no extraneous words. It is appropriately front-loaded with the core action and resource, achieving maximum conciseness without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no annotations, and no parameter documentation, yet the description offers no additional context about how to prepare the scene, choose an engine, or interpret output. The existence of an output schema does not compensate for the missing guidance on parameters and workflow, making this description severely incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero coverage (no descriptions for any of the 5 parameters), and the description does not explain any of them. Parameters like 'engine' and 'samples' are left entirely cryptic, and the description fails to compensate for the lack of schema documentation. This is a critical gap for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Render') and the target ('current scene to an image file'), making the primary purpose unmistakable. However, it does not explicitly differentiate from sibling tools like batch_render or render_turntable, which serve related but distinct rendering tasks, so it loses a point for lack of sibling discrimination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives such as batch_render (for multiple frames) or get_viewport_screenshot (for a quick viewport capture). The description gives no context about typical usage scenarios or exclusions, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 provide no safety or behavioral hints, so the description carries the full burden. It only states the action without disclosing side effects (e.g., file output, animation range), dependencies, or whether it rotates the camera or object. This is insufficient for an operation that produces multiple frames.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. It is concise and front-loaded with the core action. However, it is so brief that it sacrifices utility, but that is more a completeness issue than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and an output schema (though not shown), the description is far too incomplete. It doesn't explain parameter usage, output behavior, or when to choose this over related tools. An agent would struggle to call it correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. The agent gets no help understanding object_name, format, frames, distance, or resolution settings. Seven parameters are left completely unexplained, making it impossible to correctly configure the tool based on the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Render a turntable animation around an object.' This uses a specific verb and resource, and the concept of a turntable animation is distinct from sibling tools like render_image or batch_render. However, it doesn't explicitly differentiate itself from those siblings, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites (e.g., object existence, camera setup) or when a user should prefer this over render_image or batch_render. Usage 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 provided, the description carries the full burden of behavioral disclosure. It simply says it sets the active camera, but does not mention side effects (e.g., whether it affects the viewport, what happens if the named camera does not exist, or whether the operation is reversible). This is a mutation but lacks any behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words; it is efficient and front-loaded with the action. However, it is so terse that it sacrifices necessary detail, which is a trade-off. Still, as far as concise writing goes, it earns a high score for being succinct and clear in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, but does have an output schema (not shown), the description should at least clarify the expected parameter format and any preconditions. It does neither. The lack of any usage context or error-handling details makes it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the only parameter, camera_name. The description does not compensate by explaining what camera_name should contain (e.g., an existing camera's name, a string identifier). It adds no meaning beyond the parameter name, leaving the agent without information about valid values or requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('set') and resource ('camera') and indicates the intention to make it 'active' in the scene. It is clear enough to differentiate from sibling tools like create_camera or list_cameras, though it does not explicitly name them. The phrase 'active scene camera' adds context about the effect, which is helpful.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as creating a camera, adjusting lens properties, or listing cameras. There is no mention of prerequisites (e.g., the camera must exist), nor any exclusions or conditions for use. 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?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It merely says 'configure' without specifying whether changes apply immediately, whether omitted parameters are reset, if the camera must exist prior, or what errors may occur. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, which is concise. However, it is so brief that it omits crucial details. Conciseness is appropriate, but the structure lacks the explanatory depth needed for a tool with 12 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 12 parameters, no annotations, and no output schema details (though one exists), the description is incomplete. It does not explain the purpose of each parameter group, how they work together, or what the tool returns. An agent would have difficulty invoking it correctly with only this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions categories (lens, clipping, shift, sensor, DOF) but maps none of the 12 parameters to these categories. It does not explain units, ranges, defaults, or interactions between parameters (e.g., DOF focus object vs distance). The value added over the schema is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Configure') and a clear resource ('a camera') with the categories of settings (lens, clipping, shift, sensor, DOF). This distinguishes it from create_camera and set_active_camera, though it doesn't explicitly mention the required camera_name parameter, which the schema 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like create_camera or set_active_camera. It doesn't mention that a camera must already exist, whether this modifies an existing camera, or any prerequisites. The context for use 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?
No annotations are provided, so the description must disclose behavioral traits. It only states that it sets the current frame, implying a state change, but gives no details on side effects, return values, error conditions, or whether it affects playback or rendering. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no unnecessary words. It is front-loaded with the verb and resource. However, it is so brief that it borders on under-specification, which slightly reduces the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema present, the tool is simple, and the description fails to explain the input parameter or any behavioral nuances. An agent cannot correctly call this tool without knowing what 'frame' expects. The description is incomplete for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter 'frame' with no description (schema coverage 0%). The description does not explain what the frame parameter expects (e.g., integer index, timestamp, or frame range). There is no information about format, units, or acceptable values, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the resource (current frame of the scene). It is specific enough to be understood without ambiguity, and it is distinguishable from siblings like set_frame_range (which targets a range) and insert_keyframe (which adds keyframes). However, it does not explicitly differentiate itself from these siblings, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or when it would be preferable over set_frame_range or insert_keyframe. The only information is what it does, not when 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. It only states the action but does not disclose effects such as replacing existing environment, how strength is applied, or whether it affects rendering settings. This is a significant gap for a world-modifying operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is appropriately front-loaded with the core action. While it lacks detail, it does not waste words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no annotations, and an output schema not described, the description is under-specified. It omits essential details about parameter formats, side effects, and expected results, leaving an agent without enough context to use it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. 'filepath' could be assumed but its format and type are unspecified; 'strength' has a default but its meaning and bounds are unclear. The description adds no value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Load' and the resource 'HDRI/environment texture into the world', which conveys the core purpose. However, it does not differentiate from sibling tools like 'set_world_background' or 'set_world_background', so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, use cases, or when not to use it. The agent must infer usage from the tool name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only states that it sets interpolation mode, implying a mutation, but doesn't say what happens if no keyframes exist, whether it affects all keyframes or a specific frame, or any side effects on existing animation. It also doesn't mention error handling 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that gets straight to the point. It is concise and wastes no words. However, it is so brief that it omits essential details, making it slightly under-specified for an agent, though conciseness itself is not a flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature, 4 parameters, and lack of annotations, the description is incomplete. It doesn't clarify the scope (all keyframes vs. a specific frame), the valid interpolation modes, or the behavior when the data path is invalid. Even though an output schema exists, the description fails to give agents enough to call the tool correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the four parameters. The term 'data path' is used but not defined, and there is no mention of object_name, frame, or mode. The description provides no added meaning beyond what the schema already shows (which is just parameter names and types with no descriptions).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the resource (interpolation mode on keyframes for a data path). It is specific enough to distinguish from sibling tools like set_keyframe_handle_type, which targets a different property. However, it doesn't mention the frame parameter or the allowed modes, which could make the agent unsure of scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like insert_keyframe or set_keyframe_handle_type. It doesn't state prerequisites (e.g., keyframes must already exist) or any conditions that would make another tool more appropriate. No contrast with siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It merely says 'Set an attribute' which implies mutation, but does not describe side effects, error handling (e.g., what happens if modifier is not found), whether changes are reversible, or if any return value is produced. This 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, and the action is front-loaded. It is appropriately concise but lacks substance. While it is efficient, the extreme terseness contributes to the lack of behavioral and parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four required parameters and no annotations, the description is severely incomplete. It does not specify what attributes are settable, the expected value types, any constraints (e.g., modifier must exist), or what the output schema contains. An agent would struggle to use this tool correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so all four parameters (object_name, modifier_name, param, value) are undocumented. The description adds no meaning about these parameters—it does not explain that object_name identifies the object, modifier_name identifies the modifier, or what 'param' and 'value' represent. It fails entirely to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (set) and the resource (modifier) specifically, and mentions 'attribute' which aligns with the function name. It clearly distinguishes from sibling tools like set_constraint_param by explicitly targeting modifiers. However, it could be more specific about what constitutes an attribute (e.g., by naming the param or value fields), but the core 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, such as prerequisites (e.g., modifier must already exist), typical use cases, or how it differs from alternatives like set_constraint_param or set_shader_node_value. No mention of context or exclusions, leaving the agent without direction on when to choose this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits, but it only states the action ('set') without disclosing side effects, failure modes, or requirements. It does not mention whether the property must already exist, whether existing connections are affected, or what the return value indicates. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a clear verb and relevant examples. It is concise and easy to scan, but its brevity leaves out essential usage details. Given the lowness of content, it is efficient but not comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four required parameters, no annotations, and no parameter descriptions, the description is grossly inadequate. It does not explain expected inputs, error behavior, or return values, and it fails to contextualize the tool's role among many shader-related siblings. An agent would likely need to probe or guess to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must clarify parameters. It only elaborates on property_name by giving examples, but provides no insight into material_name, node_name, or value formats. The examples reduce ambiguity for one parameter, but the other three remain opaque, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb-object structure ('Set a property directly on a node') and provides concrete examples of properties (blend_type, operation, interpolation), which makes the purpose understandable. It does not explicitly differentiate from sibling tools like set_shader_node_value, but the examples signal it is about node properties rather than value inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites (e.g., material and node must exist), no exclusions, and no comparison with sibling tools such as set_shader_node_value or connect_shader_nodes. The description only implies a generic use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 bear the full burden of behavioral disclosure. It only says 'add' without detailing side effects, requirements (e.g., node group must exist), or whether the operation is reversible. It doesn't disclose anything about the mutation beyond the fact that it adds a socket.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundancy. It gets straight to the point, though it sacrifices informational content for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters and no annotations, yet the description provides no context about prerequisites, effects, or what the output represents. Even though an output schema exists, the description leaves critical gaps such as whether the node group must be created first, how default_value behaves, or any constraints on input_type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention any of the four parameters (input_name, input_type, default_value, node_group_name). It provides no meaning for what a 'group-level input socket' entails in terms of these parameters, leaving the agent without clues about how to fill them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add), the resource (group-level input socket), and the target (geometry node group). This distinguishes it from sibling tools like add_gn_group_output, which adds output sockets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool or when to prefer alternatives. It doesn't mention any prerequisites or context, leaving the agent to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of disclosing behavioral traits. It does not state that the operation is destructive, that it requires a mesh object, or that it may work only in certain modes. The term 'simple' hints at low complexity but provides no concrete behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb 'Run' and immediately lists supported operations. It contains no redundant words and is appropriately sized for the tool's simplicity, though it sacrifices detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that modifies meshes, the description is incomplete. It does not mention that the object must be a mesh, that the operation is irreversible, or any prerequisites like edit mode. The presence of an output schema (not described) does not compensate for these gaps, and with no annotations, the agent lacks critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the three valid values for the operation parameter, which is helpful. However, it provides no explanation of the object_name parameter, nor does it mention that operation has a default or that object_name is required. The added value is limited to enumerating operation choices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a simple bmesh operation and explicitly lists three supported operations (recalc_normals, triangulate, remove_doubles). This is specific enough to distinguish from sibling mesh tools like subdivide or extrude_region, though it does not explicitly state that the operation modifies the target mesh object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that it is intended for simple mesh cleanup operations, nor does it suggest when to use other mesh editing tools. The agent is left to infer applicability from the operation names 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 the full burden of behavioral disclosure. It states the action but fails to mention potential side effects (e.g., creating/overwriting image files), requirements like UV maps, or that it may alter the object's material settings. It does not disclose any operational constraints beyond 'using Cycles'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, which is efficient and well-structured. However, the brevity comes at the cost of critical information, so while it scores high on conciseness, it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Baking is a complex operation with many prerequisites and side effects. The description omits any mention of UV mapping requirements, engine setup, output handling, or the meaning of each parameter. The absence of annotations and low schema coverage makes this description wholly inadequate for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it explains no parameters. It gives no meaning for object_name, bake_type, margin, samples, resolution, or output_path. An agent cannot infer what values to provide for bake_type or how resolution/samples affect the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (bake), the resource (a texture map for the specified object), and the specific render engine (Cycles). This distinguishes it from bake_physics and other rendering tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like bake_physics or render_image. It does not mention that Cycles must be the active render engine or any prerequisites. There are no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 does not disclose whether imports overwrite existing files, what happens on unsupported formats, whether recursive traversal is default (though a recursive parameter exists), or any failure/rollback behavior. The description is too terse to reveal behavioral traits beyond the basic import action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and scope, with no wasted words. It is appropriately concise for a simple batch operation, though it could include a brief note on format options without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters (one required) and no annotations, the description is insufficient. It omits essential details about the format parameter's accepted values, recursive behavior, and any output or error handling. While an output schema exists, the description still leaves critical decision-making to the agent. Sibling tools share the 'import' context without differentiation, making completeness notably lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully for parameter meaning. It only mentions 'given format' and 'directory', but does not clarify allowed format values, the default null for format (possibly meaning all files?), or the recursive flag (including its default and effect). The 'recursive' parameter is entirely unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import all files of a given format from a directory') with a specific verb and scope, identifying it as a batch operation. However, it does not distinguish it from the sibling import_file or batch_export, so differentiation relies on the word 'all' and 'format', which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use batch_import versus existing siblings like import_file or batch_export. There is no mention of prerequisites, exclusions, or typical use cases. The agent cannot determine when this tool is preferable over alternatives without further 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 to fall back on, the description must disclose behavioral traits, but it only states the action without elaborating on consequences. It does not specify whether keyframes, actions, NLA strips, or other animation-related data are removed, whether the operation is irreversible, or if it affects shape keys. This is a significant omission 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that communicates the core action efficiently. It is front-loaded with the key verb and object, and contains no extraneous information. However, it is slightly underspecified for a destructive operation, which slightly reduces the score from perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, the description is incomplete. It does not mention the scope of 'animation data' (e.g., keyframes, actions, NLA), potential side effects, or whether the operation can be undone. Although an output schema exists, the core behavioral context necessary for safe invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the sole parameter 'object_name'. The description does not mention the parameter at all, leaving the agent to rely on its self-explanatory name. While 'object_name' is intuitive, the description should clarify that it identifies the object whose animation is cleared, and whether it expects a name or data reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Clear') and resource ('all animation data from an object'), which clearly distinguishes it from sibling tools like play_animation or set_preview_range that deal with playback rather than removal. It is unambiguous and directly conveys the primary action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as whether an object must be selected, or conditions where clearing animation is appropriate. No exclusions or alternative tool references are given, leaving the agent to infer usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Create a link', implying a mutation, but does not explain side effects, whether connections can be overwritten, if specific states (like edit mode) are required, or what happens on failure. It also does not describe the output format despite having an output schema. The lack of transparency 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is concise and front-loaded with the core action. However, the brevity contributes to the lack of detail noted in other dimensions, but for conciseness, it is appropriately sized. The structure is clean and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a 5-parameter tool with no annotations, no schema descriptions, and an output schema that isn't explained, the description is far from complete. It does not explain how to specify the node group, nodes, or sockets, nor any prerequisites like having a geometry nodes modifier. The agent has to infer everything, which is inadequate for a complex operation connecting nodes in a node tree.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameters are explained in the schema. The description only provides the overall purpose and does not clarify the meaning or format of parameters such as from_socket, to_socket, or how nodes are identified (by name, ID, etc.). It fails to compensate for the schema's lack of detail, leaving the agent to guess from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create a link) and the resource (two nodes in a geometry node group). It implicitly distinguishes from sibling tools like connect_compositor_nodes and connect_shader_nodes by specifying 'geometry node group'. However, it doesn't explicitly mention the socket-level detail, which is covered by the schema, so it's clear but not maximally precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor any prerequisites or conditions. The description does not mention that it's specifically for geometry nodes beyond the name and phrase 'geometry node group', which is implicit. There is no mention of when not to use it, such as needing existing nodes or a modifier. The agent must infer usage from the name alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 only states that a node is created, implying mutation, but does not mention side effects, whether the material must exist, if the operation is reversible, or what the output contains. This is a significant gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is immediately clear what the tool does, and the core action is front-loaded. This is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits essential context: it doesn't mention that the material must already exist, what node types are valid, or how the location parameter is interpreted. For a tool with three parameters and no annotations, this level of detail is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The description only hints that material_name identifies the material, but it does not explain node_type values or the location format, leaving the agent without enough information to set parameters correctly. The description fails to compensate for the schema's lack of coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (create) and resource (shader node) scoped to the material's node tree. This clearly distinguishes it from siblings like connect_shader_nodes, delete_shader_node, or get_shader_node_tree, so the agent can tell them apart without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as add_image_texture_node, create_emission_material, or create_material. There is no mention of prerequisites (e.g., material must exist) or exclusions, leaving the agent without enough context to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Create' without detailing side effects—whether existing lights are replaced or supplemented, whether the subject_name affects positioning, or what the returned result is. The mutation aspect is implied by the verb but not elaborated, leaving significant uncertainty for an agent invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and object. It is maximally concise with no filler or redundant information. Every word contributes to stating the tool's purpose, making it appropriately sized for what little it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Creating a three-point lighting setup is a complex operation involving multiple lights, positioning, and subject targeting. The description misses essential context: what lights are created, how energies map to specific lights, whether subject_name is required, how it interacts with existing scene lights, and what the output schema contains. With no annotations and minimal schema coverage, the description is vastly incomplete for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, and the description does not mention any parameter. Although parameter names like key_energy, rim_energy, and fill_energy are somewhat self-explanatory in a lighting context, the description adds no value to clarify their roles, defaults, or how subject_name is used. The agent must infer meaning entirely from parameter names, which is insufficient for a complex setup tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a classic three-point lighting setup aimed at a subject.' It clearly indicates the action and what is being created, and the phrase 'three-point lighting' distinguishes it from generic light creation tools like create_light. However, it does not explicitly contrast with sibling tools, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_light or set_light_property. It does not mention scenarios, prerequisites, or when not to use it. An agent has no hint whether this is a convenience shortcut or a standalone setup, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses the deletion but omits side effects such as whether connected links are automatically removed, whether the operation is reversible, or any error conditions. Minimal behavioral disclosure; just says 'Remove a node' without context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It's appropriately concise for a simple operation, though the brevity contributes to missing detail in other dimensions. Structurally it's sound—verb first, resource second—but content is thin.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter tool, the description is minimal but doesn't address failure scenarios, return values, or side effects. An output schema exists, so return format needn't be described, but the description should note typical errors (e.g., missing node) or confirmations. Not complete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the two parameters. It references 'material' and 'node' but doesn't explain their expected formats, types, or that material_name must reference an existing material and node_name a node within that tree. The description adds only a hint of the relationship, not sufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Remove') and resource ('a node from the material's node tree'). It distinguishes the tool from geometry-node removal (e.g., remove_geometry_node) by implying material/shader context, though it doesn't explicitly say 'shader node.' The name provides the shader specificity, so purpose is clear but not fully explicit 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like remove_geometry_node. It doesn't mention prerequisites (e.g., that the material and node must exist) or what happens if they don't. Only states the action, leaving the agent to infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only states 'Duplicate' without explaining how duplication works (e.g., copies data or references), what data (materials, animations) is preserved, or what the tool returns. The 'linked duplicate' concept is mentioned but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and resource. It is efficient and does not waste words, though it lacks any structural elements like context or examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no parameter descriptions, and an output schema that is not discussed, the description is inadequate for an agent to invoke it correctly. It does not cover essential details about the name parameter's target, linked behavior, or expected return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not clarify the meaning of 'name' (likely the object to duplicate) or 'linked' (whether it creates a linked copy). No parameter details are spelled out, leaving the agent to infer from naming conventions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Duplicate' and the resource 'an object', with an additional qualifier about linked duplicates. It is specific enough to convey the primary function, though it does not differentiate from sibling tools like create_object or delete_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor does it explain when to choose linked vs. non-linked duplication. There are no exclusions or context cues about prerequisite conditions or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states 'Export' but doesn't disclose that this likely creates or overwrites a file on disk, may require write permissions, or could have side effects like overwriting existing files. It also doesn't mention any potential failures (e.g., invalid filepath) or behavior differences based on format. The brevity leaves significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, clear sentence with no unnecessary words. It efficiently conveys the core purpose. However, it's so brief that it omits crucial details, which slightly reduces the score because conciseness sacrifices necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is an export operation with 2 parameters (one undocumented format) and no annotations, the description is insufficient. It doesn't clarify what 'export' results in (a file on disk), what format options exist, whether the filepath needs an extension, or what the output schema contains. For a file-writing tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description mentions only 'a file' without explaining the 'filepath' parameter's expected format or the 'format' parameter's valid values. Since 'format' has no default and no enum, the description should clarify what formats are supported (e.g., .obj, .fbx) but doesn't. This forces the agent to guess parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (export), the resource (entire scene), and the destination (to a file). It distinguishes itself from the sibling 'export_object' by specifying 'entire scene', which implies full-scene export. However, it does not explicitly mention alternatives or contrast with other export tools, so it's clear but not maximally distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'batch_export' or 'export_object'. The description implies it's for full-scene exports but doesn't state exclusions, prerequisites (e.g., requires a saved file), or when a different tool would be more appropriate. This leaves the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutation ('insert'), but doesn't mention prerequisites (e.g., object must have animation data), side effects, or behavior on invalid inputs. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. It's concise and to the point, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with no annotations, the description is incomplete. It doesn't explain the purpose of index and value, prerequisites, or error behavior. Even with an output schema, the description fails to provide enough context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only vaguely maps to 'object property' (data_path) and 'frame', but leaves index and value unexplained beyond their names. The description adds minimal semantic value over the raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Insert a keyframe') and the resource ('on an object property at a given frame'). It effectively distinguishes from sibling tools like delete_keyframe and get_keyframes by the insertion verb, though it doesn't explicitly reference them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus its alternatives (e.g., delete_keyframe, set_keyframe_interpolation). The description only states what it does, leaving the agent to infer usage context from the tool name and 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 bears full responsibility for behavioral disclosure. It only states a search action and substring matching, omitting details about pagination, response format, performance implications, or any side effects. For a query tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancy. The action is front-loaded. However, it may be under-specified, but conciseness itself is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no schema descriptions, no annotations, and an output schema that is not described, the description leaves many unknowns. It does not mention return value details or edge cases, making it incomplete for an agent to fully anticipate the behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must clarify parameters. It explains that 'query' is a substring, which adds value, but the 'limit' parameter (which defaults to 100) is entirely unexplained. This partial explanation is insufficient given the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (search) and resource (operators) with a scoping qualifier ('all categories') and a matching rule ('substring'). It distinguishes from a generic list operation by implying filtering, though it does not explicitly contrast with sibling list_operators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_operators or get_operator_info. It doesn't mention conditions, prerequisites, or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of disclosure. It only states the action 'set' without any side effects, requirements, error handling, or what happens if the specified UV map does not exist. It does not contradict annotations (there are none), but it provides essentially no behavioral context beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core purpose. It is appropriately concise for a simple operation, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters, the description is inadequate. It omits essential context such as whether the object must have an existing UV map with the given name, what happens on failure, and any side effects on the viewport or scene. While an output schema exists, the description itself leaves the calling agent without enough information to anticipate behavior or handle errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the schema itself contains only minimal titles with no descriptions or types. The description adds no information about the parameters 'object_name' or 'uv_map_name', failing to compensate for the lack of schema detail. The agent receives no semantic guidance for filling these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'set' with a clear resource 'active UV map on the specified object'. It clearly distinguishes from siblings like create_uv_map or list_uv_maps, as it focuses on switching the active mapping rather than creating or listing. The one-sentence definition leaves no ambiguity about its core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., object must already have UV maps) or conditions that would make it preferable to create_uv_map or list_uv_maps. The description only states what it does, not when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Set a value', implying mutation, but does not mention side effects, reversibility, permissions, or return values. This is minimal and insufficient for an agent to anticipate consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action. It avoids unnecessary verbosity, though it could have included brief parameter clarification without becoming lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters), the description is still incomplete: it does not explain the value parameter, potential errors, or what the output represents (despite an output schema being present). An agent would need additional context to call this reliably, especially given the absence of parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It provides partial meaning for 'path' (a dotted path ending in an attribute name) but says nothing about 'value' – its type, format, or constraints. The description does not fully compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: setting a value via a dotted path that ends in an attribute name. This specific verb+resource structure distinguishes it from the sibling get_attr_path and other setter tools, though it does not explicitly mention which object or attribute types it applies to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_attr_path or other setter tools. The description does not mention any prerequisites, conditions, or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the basic action. It does not mention whether the operation mutates state persistently, requires specific permissions, affects playback, or how it interacts with the timeline. The optional FPS is mentioned, but no details on units or side effects are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise and free of fluff. It front-loads the primary action and mentions the optional aspect inline. However, conciseness comes at the cost of completeness, which is penalized elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, including two required ones, the description is inadequate. It lacks parameter explanations, usage context, and any behavioral notes. Although an output schema exists, the description does not clarify what the tool returns or how the frame range is applied, making it insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain the parameters. It only mentions 'scene frame range' and 'FPS' without detailing start, end, or fps meanings. No information on inclusivity, units, or valid ranges is given, leaving the agent with little beyond raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the 'scene frame range' and optionally FPS, which is a specific resource and action. However, it does not explicitly differentiate from sibling tools like set_preview_range or set_frame, which could cause ambiguity. The verb-resource pairing is clear enough for most purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention scenarios where set_preview_range or set_frame would be more appropriate, nor does it provide any context about prerequisites or effects. The description leaves the agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 behavioral burden. It only says 'set', implying mutation, but does not disclose side effects (e.g., overwriting existing slot assignments), error behavior for invalid slots or missing materials, or whether material names must reference existing materials. It lacks the context needed to safely predict 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words. It is front-loaded with the core action and resource. While extremely brief, it wastes no words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has three required parameters and no annotation support, the description is insufficient. It doesn't explain parameter semantics, prerequisite conditions, or error handling. While an output schema exists, it cannot clarify input behavior. For a tool that mutates object state, more context is needed for an agent to invoke it correctly without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions for all three parameters (coverage 0%), and the description adds only generic references to 'object', 'slot', and 'material' without explaining their formats, ranges, or constraints. For example, slot_index could be zero-based or one-based, and material_name might need to be an existing material or be created on the fly. The description does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('set'), the resource ('a specific material slot on an object'), and the target ('to a given material'). It is clear and specific, and the mention of 'specific' hints at slot-index-based assignment, distinguishing it from the broader assign_material sibling. However, it does not explicitly name alternative tools or 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like assign_material or apply_material_to_all. There is no mention of conditions, prerequisites (e.g., object must exist, slot must be valid), or hints about slot indexing conventions. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'Switch mode', which is a terse statement of the action itself. It doesn't disclose side effects (e.g., changing the 3D viewport context, potential implications for selection), whether the object_name is required for some modes, or what happens if the mode is invalid. This is a significant gap for a tool that mutates the Blender context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It is appropriately concise for a clear action, but the brevity leaves out crucial context. As a result, it is not maximally effective despite being clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 2-parameter schema with 0% coverage, no annotations, and a large set of sibling tools that include many mode-specific entrypoints, this description is incomplete. It does not address the optional object_name, the relationship to sibling tools, or any preconditions. The output schema exists but the description alone is insufficient for an agent to reliably choose between set_mode and the specific enter_*_mode alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It names example values for 'mode' but does not explain the semantics of either parameter, especially 'object_name' (which is optional with a null default). The description adds nothing about what object_name does (e.g., which object's mode is switched) or how the mode parameter is validated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Switch' and the resource 'mode', and lists representative values (OBJECT, EDIT, SCULPT, POSE, WEIGHT_PAINT). This makes the tool's function clear. However, it does not distinguish itself from the many sibling enter_*_mode tools (e.g., enter_edit_mode, enter_sculpt_mode), which have more specific scopes. The description implies a generic capability but doesn't explicitly contrast it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this generic set_mode versus the specific enter_edit_mode, enter_sculpt_mode, etc. It also doesn't mention the optional object_name parameter or any prerequisites. An agent is left to infer usage from the mode names 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 must disclose behavioral traits. It only states that a relationship is set, implying a mutation, but does not describe side effects like whether existing parenting is overridden, if objects must be in the same scene, or what happens on failure. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It is appropriately sized and front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that performs a mutation on two parameters, critical information is missing: how to reference the objects, whether existing parenting is replaced or added, and any constraints on object types. The presence of an output schema is irrelevant since the description does not explain the return value. The description is far from adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the parameters have no types or descriptions. The description adds only that the parameters refer to 'two objects', but does not explain how to identify them (by name, ID, etc.) or any constraints on the relationship. The field names 'child' and 'parent' are self-explanatory, but the description does not compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action 'Set a parent-child relationship' and the resource 'two objects', making the core purpose clear. However, it does not differentiate this generic tool from specialized parenting tools like parent_mesh_to_armature, which also sets a parent-child relationship but for a specific context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as clear_parent or parent_mesh_to_armature. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full responsibility for behavioral disclosure. It only states what the tool does without revealing side effects, requirements (e.g., object must exist), whether the new UV map becomes active, or error handling. This is a minimal disclosure for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core action and target. No extraneous words, and it conveys the essential purpose without ambiguity. It is appropriately concise for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 parameters, output schema exists), the description is still incomplete. It does not explain the effect on existing UV maps, whether the new map becomes active, or any prerequisites. Without annotations, the agent lacks 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the mesh object but does not explain the required 'object_name' parameter beyond the obvious, nor does it mention the optional 'name' parameter (default 'UVMap'). No parameter details or format are provided, leaving the agent underinformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('UV map'), and specifies the target ('mesh object'). It clearly distinguishes from tools like list_uv_maps (listing) and set_active_uv_map (setting active), though it doesn't name alternatives explicitly. The phrase 'new UV map' implies creation versus modification, which adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like unwrap_uv or project_from_view. There is no mention of prerequisites (e.g., mesh must be selected or exist), nor any indication of alternatives. The agent is left to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the tool deletes a bone, but does not mention potential side effects (e.g., cascading deletion of child bones, need for certain modes, irreversibility). This is critical for a mutation tool and is entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundant words. It conveys the core purpose efficiently and is appropriately sized for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with two parameters and no annotation support, the description is incomplete. It lacks guidance on error conditions (e.g., bone not found, armature not found), mode requirements, and any impact on the rest of the armature. An agent would be acting without full understanding of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It implies that bone_name identifies the bone and armature_name identifies the armature, but does not explicitly state their roles, expected formats, or constraints (e.g., exact names vs. partial). The description adds minimal value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the target (a bone from an armature), which is unambiguous given the context of siblings like add_bone and list_bones. However, it doesn't explicitly distinguish from other delete tools (e.g., delete_geometry), but the resource is specific enough to avoid confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites such as the bone existing or the armature being in edit mode. An agent would have to infer the appropriate context from the tool name alone. This is a significant gap for a destructive operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. 'Delete' implies a destructive mutation, but the description does not mention reversibility, error behavior (e.g., if the keyframe does not exist), or side effects on animation data. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states the action and scope, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete for a tool with 4 parameters, no parameter documentation, and no annotations. It fails to explain index or provide expectations for missing keyframe conditions, making correct invocation uncertain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It vaguely covers frame ('at a given frame') and data_path ('object property'), but does not explain object_name or index, especially the meaning of index's default -1. The agent is left without key parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (delete), resource (keyframe), and context (from an object property at a given frame). It clearly identifies a single-keyframe deletion, implicitly differentiating it from siblings like insert_keyframe, get_keyframes, or clear_animation, though it does not name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool instead of alternatives. The description only states what it does, leaving the agent to infer from the name and context that it is for removing one keyframe rather than bulk operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It only says 'Return detailed information,' which implies a read-only operation but does not explicitly state side-effect freedom, expected output structure, or any limitations. The lack of detail leaves the agent guessing about what 'detailed' includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, which is appropriately sized. It front-loads the verb and resource. The only minor issue is that it is so brief it borders on under-specification, but for a getter with one parameter, it is acceptably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the tool is for retrieving 'detailed information,' and the description does not hint at what that information includes (e.g., node list, parameters, connections). It also lacks any guidance on failure cases or expected input format, making it incomplete for an agent to confidently invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the parameter material_name has only a title with no type or definition. The description does not explain what 'material_name' refers to (e.g., exact name, identifier, or path), nor does it provide any hints about its format. The description completely fails to compensate for the schema's emptiness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a material's node tree, using a specific verb ('Return') and resource. It is distinct from sibling tools like get_shader_node_tree or get_gn_node_tree, which target other node tree types, so an agent can differentiate it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states what it does without context on when it is appropriate, unlike better descriptions that mention alternatives or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says it returns a list, but does not mention valid asset_type values, error conditions, network requirements, or any side effects. For a read-only operation, this is minimal disclosure at best.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. It immediately communicates the purpose and the key parameter. Efficiency is ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and an output schema exists, the description omits crucial context about valid asset_type values. Without enums or further explanation, an agent may not know what to pass. The description is too sparse to fully guide correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description barely adds meaning to the single parameter. It echoes 'asset_type' without explaining which values are acceptable (e.g., which categories exist). The description does not compensate for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a direct action ('Return') and a specific resource ('list of categories') for a given asset_type. It is clear and unambiguous, though it does not explicitly contrast with sibling tools like search_polyhaven_assets or download_polyhaven_asset, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or use cases. The description simply states what it does, leaving the agent to infer when it 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'check whether an operator can run,' without explaining side effects (if any), error behavior, output format compatibility, or implications (e.g., whether it consumes resources). This is minimal and insufficient for safe agent use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. It is not verbose, and the structure is clear. However, it is so sparse that it sacrifices essential information for brevity, moving it slightly down from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and presence of an output schema, the description should clarify how 'idname' maps to an operator and what 'can run' means in practice. It lacks any explanation of the parameter or usage context, making it incomplete for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a required parameter 'idname' with no type or description, and schema description coverage is 0%. The tool description does not mention 'idname' at all, leaving the agent to guess its meaning. This is a major gap because the parameter is essential and undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check') and resource ('whether an operator can run'), clearly distinguishing it from sibling tools that list, search, get info, or call operators. The term 'poll' reinforces its checking nature, leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_operator_info or call_operator. It does not mention prerequisites, context requirements, or scenarios where polling is preferred over direct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It simply says 'set the default value', which implies a mutation but doesn't disclose side effects (e.g., whether the change persists, if it fails when the input doesn't exist), or any return behavior. No additional context is offered beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and context. There is no redundant or extraneous text, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are four required parameters, no annotations, and no schema descriptions, the description is insufficiently detailed. It doesn't mention that the node group must already exist, what happens when the input name is invalid, or how the value should be formatted. While an output schema exists, the tool's preconditions and edge cases are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not elaborate on parameter semantics. It hints that 'value' is the new default and 'input_name' identifies which input, but that's directly inferable from the names. No types, formats, or relationships between parameters are explained, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Set the default value of a node input' within a 'geometry node group'. This clearly distinguishes it from other geometry-node operations like add_gn_group_input or connect_gn_nodes. However, it doesn't explicitly differentiate it from the similar compositor tool set_compositor_node_input, though the geometry node group context is 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., node group must already exist), or that it's for modifying an existing node's input default rather than adding a new input. The usage context is only implied by the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 objects are selected by name, but does not clarify whether this replaces the current selection, how 'extend' interacts, what happens when names are invalid, or whether the selection becomes active. This is a significant gap for a tool that clearly mutates state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, terse sentence with zero redundancy. It front-loads the primary action and resource. While extremely short, it is not padded with fluff, making it highly efficient for scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, an output schema, and no annotations, this description is seriously incomplete. It does not explain the semantics of 'active' and 'extend', the behavior on invalid names, or the structure of the response (even though an output schema exists, its content is not conveyed). An agent would likely need to inspect the schema or experiment to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It implicitly documents object_names (the names to select) but says nothing about the 'active' or 'extend' parameters. Since the required parameter is at least hinted at, but the other two are entirely undocumented, the description adds only marginal value and fails to explain critical control flags.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Select' and the resource 'objects', and specifies the method 'by name'. It distinguishes this tool from get_selection (which retrieves the selection) and other selection-adjacent tools like frame_selected. However, it does not hint at the function of the 'active' or 'extend' parameters, which would sharpen the purpose further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_selection or other selection-manipulation commands. There is no mention of context, prerequisites, or exclusions. An agent must infer usage from the name and sibling list, which is not reliable for complex workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the basic operation. It doesn't mention whether the tool modifies an existing object, requires a selection, replaces existing physics, or has side effects. It also doesn't explain what ACTIVE versus PASSIVE means in terms of behavior. The agent is left guessing about the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and avoids filler. One sentence is efficient, but it's under-specified for the complexity of the operation. Still, given its length, it earns points for clarity and brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, an output schema, and relates to a complex physics system. The description only mentions the type parameter and does not cover mass, prerequisites, or how the tool interacts with existing rigid body setups. The output schema exists but is not described, so the agent lacks critical context about return values or side effects. The description is inadequate for a physics operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only explains the 'type' parameter (ACTIVE or PASSIVE). It doesn't explain 'mass' or 'object_name', though object_name is self-explanatory from the name. The description adds minimal value for the other parameters, leaving the agent to infer their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Add') and resource ('rigid body physics'), and includes the key type distinction (ACTIVE or PASSIVE). This clearly differentiates it from sibling physics tools like add_cloth and add_soft_body, so an agent can identify the correct tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While the name and purpose imply it's for rigid body physics, it doesn't state conditions like 'use for rigid body simulations only' or mention that cloth/soft body have separate tools. An agent unfamiliar with the domain may not know when to choose this over add_cloth, add_soft_body, or add_collision.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 that nodes are enabled, which is a notable trait, but it does not describe side effects, prerequisites, whether the new material becomes active, or any other behavioral implications. The absence of annotations and the minimal description leave significant gaps for a creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous words. It front-loads the core purpose ('Create a new material') before adding the qualifier about nodes. Every word earns its place, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simplicity of the tool (one parameter) and presence of an output schema, the description is insufficient. It lacks any parameter guidance, usage context, or elaboration on what 'nodes enabled' implies. The agent is left without enough context to confidently invoke it, especially given the many sibling material tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains one required property 'name' with no description, type, or default, and schema description coverage is 0%. The description does not mention the parameter at all, so it provides no meaning beyond the property key. An agent has no idea what format 'name' should take (string, identifier, etc.) or its significance, making this a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('a new material'), and a specific feature ('with nodes enabled'). This distinguishes it from many sibling tools like create_camera or create_light, and from material-specific variants like create_emission_material or create_glass_material, though it doesn't explicitly compare to them. It is a specific, unambiguous statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no mention of when to use this tool versus alternatives. It does not state exclusions or contexts where other material-related tools (e.g., assign_material, create_emission_material) should be used instead. The intended usage is only implied by the tool's name and description, with no guidance to help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 available, the description carries the full burden of behavioral disclosure. It only states the action itself and gives no information about side effects (e.g., whether the material is removed from all objects using it), error conditions, or behavior when the material does not exist. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is front-loaded with the action verb and target, making the core purpose immediately clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and has an output schema (so return values may be documented elsewhere), the description lacks contextual information such as the effect on object material slots, whether deletion is reversible, and any constraints on usage. It also does not differentiate itself from related material tools (e.g., set_material_slot, assign_material) in terms of when to delete versus reassign.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero documentation for the 'name' parameter, and the description provides no additional meaning. It does not clarify what type of name is expected (e.g., data-block name, display name), whether it is case-sensitive, or whether the material must be unique. The agent must infer everything from the tool name, which is risky.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific verb ('Remove') and resource ('material') with a precise location ('bpy.data.materials'). This unambiguously distinguishes it from sibling delete tools like delete_object or delete_collection, leaving no doubt about what is being operated on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention prerequisites, fallback options, or conditions that would select this tool over related tools like assign_material or set_material_slot. An agent has no context for choosing it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 behavior. It only states that it lists modifiers, but does not mention whether the operation is read-only, what happens if the object does not exist, whether it returns an error, or any side effects. The existence of an output schema could handle return format, but the description does not reference it or add any behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is perfectly concise and gets to the point immediately. No fluff or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description is minimally adequate but lacks important context such as error handling, typical usage scenarios, or notes about the returned structure. An agent might call it without knowing how to interpret potential failures, but the basic action is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for documenting the parameter. It mentions 'on an object' which implies the object_name parameter, but provides no additional detail about the required format, type, or any constraints. The parameter name is self-explanatory, but the description does not add meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (list) and resource (modifiers on an object). It is specific enough to distinguish from modifier mutation tools like add_modifier or remove_modifier. However, it does not explicitly mention any alternative or contrasting sibling, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites (e.g., object existence), no recommended context, and no exclusions. The description simply states what it does without helping an agent decide when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It only says 'Set', implying a mutation, but does not state whether attributes are overwritten or appended, how extra_params is interpreted, whether a missing system_name defaults to the active system, or what happens if the object has no particle system. There is no mention of side effects, errors, or return behavior, leaving significant ambiguity 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and includes illustrative examples. It avoids unnecessary verbosity and is efficiently structured for quick reading. The trailing '...' slightly undercuts completeness but does not significantly harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations) and the presence of an output schema (not shown), the description is underdeveloped. It fails to mention that the tool modifies an existing particle system, how extra_params interacts with the system, or any preconditions. An agent cannot confidently invoke this tool without additional assumptions about Blender's particle API. The description is insufficient for a complete, correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for its parameters, so the description must compensate. It does so by listing example attributes (count, lifetime, frame_start) that likely belong to the extra_params object, giving partial semantics. However, it does not explain the roles of object_name and system_name, nor explicitly state that extra_params is a dictionary of attribute-value pairs. The description adds some meaning beyond the bare schema but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Set particle settings attributes') and lists relevant examples (count, lifetime, frame_start), which convey the resource and scope. It is distinct from siblings like add_particle_system or list_particle_systems, though it does not explicitly contrast with them. The verb+resource is clear enough for an agent to identify the tool's basic purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., that a particle system must already exist via add_particle_system), nor does it clarify whether it is suitable for creating or only modifying systems. There is no 'when to use' or 'when not to use' context, leaving the agent to infer 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 the full burden of behavioral disclosure. It only says 'Return', implying a read-only operation, but does not explicitly state that it has no side effects, whether it requires specific permissions, or how it behaves with invalid or nonexistent operator identifiers. This lack of detail is a notable gap for a tool that retrieves schema data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the primary purpose. It is not bloated and contains no filler, but it lacks the detail needed for parameter guidance. Conciseness itself is excellent, though the sentence could have been structured to include more crucial information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description should at least clarify what 'idname' refers to, but it does not. The output schema does not compensate for the missing input semantics. The agent is left uncertain about the required argument, making the tool effectively unusable without external knowledge of Blender operators.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single parameter 'idname' with no type or description (schema description coverage is 0%). The description does not explain what 'idname' should contain (presumably the operator's identifier), leaving the agent without any guidance on how to fill the required argument. This is a critical deficiency for a tool with an undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('return') and resource ('RNA property schema') for any operator, which clearly distinguishes it from siblings like list_operators (which lists all), search_operators (which searches), and call_operator (which executes). The scope is explicit, making the tool's functionality unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—'for any operator' suggests calling this when operator schema is needed—but it provides no explicit context about when to prefer this over list_operators, search_operators, or other getters. There is no mention of alternatives or exclusions, leaving the decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool reorders a modifier in the stack, which is the primary behavioral effect. However, it does not mention side effects (e.g., that it permanently changes the object's modifier order), error conditions, or requirements (e.g., that the modifier must exist). With no annotations to fall back on, this is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that states the purpose with no redundant wording. It is front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with three required parameters and no schema descriptions. It does not define the parameters, valid direction values, or the result. While an output schema exists, the input semantics are under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage), and the description adds no parameter-specific details. It does not explain what values 'direction' accepts (e.g., 'up' vs 'down'), what 'object_name' refers to, or how 'modifier_name' is identified. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'reorder' and the resource 'modifier', and specifies the direction as 'up or down'. This distinguishes it from other modifier tools like add_modifier or remove_modifier, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other modifier operations. Context is implied from the purpose, but there are no explicit conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states only that it undoes the last action, but does not disclose whether undo is destructive, how it handles multiple undos, or what constitutes an 'action' in this context. This is minimal and insufficient for an agent to anticipate side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words, which is efficient for a zero-parameter operation. However, it may be under-specified, lacking any contextual detail, but it is not verbose or wasteful. It earns a high score for conciseness, though slightly reduced because it could be more informative without becoming lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is still incomplete. It does not explain the scope of the undo (e.g., which commands are undoable), whether there is an undo stack depth, or any limitations. The agent is left without enough context to know when and how to use it effectively, especially given the large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100% (trivially, since there are no properties). Per the guidelines, a baseline of 4 is appropriate for 0-parameter tools, and the description does not need to explain parameters. It adds no additional semantics needed beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Undo last action' provides a clear verb and resource, and it is easy to understand what the tool does. However, it does not differentiate itself from the sibling tool 'redo' or clarify which actions are considered 'undoable', though the overall 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'redo' or other action-management commands. The description does not mention any context, prerequisites, or exclusions, leaving the agent without direction on appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the core action but does not disclose requirements like material existence, whether the node is linked into the material's tree, or error behavior on invalid paths. This is insufficient disclosure 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It front-loads the main action and is appropriately sized for a simple tool, even though it lacks detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two required parameters with no schema descriptions and no annotations, and the description only addresses one. It also lacks context on how the node is connected or what happens to the material, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain both parameters. It refers to 'given path' which maps to image_path, but material_name is never mentioned. The description fails to clarify what material_name refers to or how it is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a ShaderNodeTexImage and load an image from the given path,' which clearly identifies the verb and resource. It distinguishes from generic sibling create_shader_node by specifying the exact node type and image loading action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like create_shader_node or connect_shader_nodes. There are no prerequisites, exclusions, or conditions 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 is the sole source of behavioral information. It states the core functionality (creating a material with a Glass BSDF shader) but does not disclose side effects like whether it replaces existing materials, whether it assigns to an object, or how the node tree is configured. This is acceptable for a straightforward creation tool but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly conveys the tool's purpose without unnecessary words. It is appropriately concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (so return values don't need explanation), the description lacks parameter semantics, usage guidance, and behavioral details essential for correct invocation. For a tool with 4 parameters and no annotation support, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description mentions none of the parameters (ior, name, color, roughness). The schema itself provides defaults and types, but the description adds no semantic detail about how these parameters influence the material, leaving the agent to guess at their meaning and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (a material), and the specific type (Glass BSDF shader connected to the output). This distinguishes it from generic tools like create_material or set_principled_bsdf, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as create_material or set_principled_bsdf. There is no mention of prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It states the primary action (adding a vertex group) but does not mention side effects, such as whether the operation mutates the existing object, whether it requires the object to be a mesh, or whether it can fail if the group already exists. No details about persistence or undo behavior are given, which 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence. It front-loads the primary purpose ('Add a vertex group to a mesh object') and adds a succinct optional behavior. There is no fluff or repetition, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters (2 required) and no schema descriptions or annotations. The one-sentence description is insufficient to understand the parameter semantics, usage conditions, or expected behavior. It lacks details on how to specify vertices, what the default weight means, or prerequisites like object type. Given the tool's apparent simplicity, a bit more context (e.g., that vertex_indices is a list of integers) would significantly improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only hints at 'weight' and 'vertices' without explaining the exact parameters. It does not clarify what 'vertex_indices' should be (list of integers? indices of vertices?), how 'weight' applies to the group or vertices, or the significance of 'group_name' being required. The description adds minimal meaning beyond the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a vertex group to a mesh object', specifying both the verb and the resource. It also mentions the optional assignment of vertices with a weight, which directly relates to the tool's core functionality. This is specific enough to distinguish it from other creation tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., the object must be a mesh or in edit mode), nor does it reference any sibling tools or conditions that would help an agent decide between this and other creation commands. The agent must infer usage from the name and general context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It does state that deletion affects both the scene and Blender data, which is a useful behavioral detail. However, it does not mention irreversibility, failure conditions, or side effects, leaving gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with zero superfluous content. It is appropriately sized for a simple operation and immediately conveys the key action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and an output schema exists, the description does not explain the 'name' parameter, which is critical for correct invocation. It also omits any information on error handling or prerequisites. Given the dominant role of the description in this context, it is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'name' parameter, and the description does not mention the parameter at all. The agent is left without any explanation of what 'name' refers to (presumably the light object's name), making parameter semantics completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Delete') and a specific resource ('a light object'), and explicitly mentions both the scene and Blender data. This clearly distinguishes it from other delete tools like delete_object or delete_collection, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., delete_object, remove_strip). There are no mentions of prerequisites, exclusions, or conditions under which this tool is preferred. The usage context is only implied by 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action (download and import) which implies it will create an object in Blender, but it does not disclose potential side effects like network dependency, time cost, or scene modifications beyond importing. It lacks warnings about whether it overwrites or appends, or any permissions/rate limits. Basic but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the action and destination. It is appropriately short with no redundant words, and the structure efficiently conveys the essential purpose without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that downloads external content and imports it into a 3D scene, the description is minimal. It lacks essential context such as the need to search for the model first, whether an internet connection is required, or how to handle the output. Even though an output schema exists, the absence of guidance on prerequisites or side effects makes the description insufficient for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'model_uid' has no schema description (0% coverage) and the tool description does not explain what it is, how to obtain it, or its format. The agent is left guessing that it is the Sketchfab model identifier, with no guidance on where to find it (e.g., from search results). The description adds no value beyond the parameter name itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (download and import), the resource (Sketchfab model), and the destination (Blender). It distinguishes this tool from siblings like search_sketchfab_models (which searches) and download_polyhaven_asset (different asset source). No ambiguity about the tool's core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that users typically need to search for a model first (e.g., via search_sketchfab_models) to obtain the model_uid, nor does it exclude cases like existing model files or other import methods. No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, it does not explicitly state that the tool has no side effects, what happens if the object is missing, or how the data is returned. The description lacks detail on error conditions or output format, which is a significant gap given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It states the core purpose first and the optional filter second. Every word earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and 0% schema description coverage, the description is not complete. It does not clarify the meaning of 'data path' in the Blender context, any prerequisites (e.g., object must exist), or what the output schema contains (though an output schema exists, it is not part of the description). The tool is simple, but the description leaves critical details for correct invocation unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'data_path' as a filter but does not explain what constitutes a valid data path (e.g., 'rotation_euler') or the accepted format. 'object_name' is self-explanatory but not elaborated. The description adds minimal meaning beyond the schema field names, which is insufficient for a tool with completely undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('keyframe data from an object'), and an optional filter ('by data path'). This distinguishes it from mutation siblings like insert_keyframe and delete_keyframe. The purpose is specific and unambiguous, not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is the read counterpart to insert_keyframe/delete_keyframe, nor does it indicate scenarios where other tools (e.g., clear_animation) would be appropriate. There is no explicit when/when-not 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 disclosing behavior. It only states the action ('Remove a modifier') without revealing side effects (permanent deletion), error handling (if modifier not found), or any irreversible consequences. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It states the action and the object effectively, and nothing could be removed without loss of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple remove operation with two clear parameters and an output schema, the description is minimally adequate. However, it lacks usage guidance and behavioral transparency, which are important given the numerous modifier-related sibling tools. An agent could call it correctly but may not know when it's appropriate or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, but the parameter names (object_name, modifier_name) are self-explanatory. The description reinforces that the modifier is removed from the object, mapping to the two parameters. It adds some meaning but does not elaborate on formats or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Remove') and resource ('a modifier from an object'), and the tool name aligns. It distinguishes from sibling tools like add_modifier and list_modifiers, though it doesn't explicitly name them; the intent 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as requiring the modifier to exist first (e.g., list_modifiers) or differences from apply_modifier or set_modifier_param. The description is purely a statement of action with no context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full behavioral burden. It discloses that it handles three value types (float, vector, color), which adds useful context, but it does not explain validation, side effects, error handling, or the return value (despite an output schema existing). It is a minimal contribution toward transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences with no unnecessary words. The primary action and object are front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four required parameters and no annotations, the description is inadequate. It fails to explain how to specify the value for different types, the purpose of each parameter, or what the output schema contains. An agent would lack critical details needed to reliably set a shader node input value, especially for vector or color inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage, so the description must compensate. It does not explain the meaning of material_name, node_name, input_name, or value beyond the type hint implied by 'Handles float, vector, and color.' No parameter semantics are added, leaving the agent to guess how to format the value for each type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the target resource ('default_value of a node input'). It also specifies the supported value types (float, vector, color), which distinguishes it from sibling tools like set_shader_node_property that set other node attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as set_shader_node_property, connect_shader_nodes, or create_shader_node. There are no prerequisites, exclusions, or context hints to help an agent choose the appropriate tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral disclosure. It does state that the armature is linked to the active scene, which is a key behavior. However, it doesn't mention side effects (e.g., becomes the active object?), error conditions, naming conflicts, or return behavior. The minimal disclosure provides only a small hint of what happens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It efficiently states the core action. It could arguably be even more concise, but the current structure is clean and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is nearly sufficient for an agent to invoke it, but significant gaps remain. It doesn't explain parameter semantics, likely return values (though an output schema exists, it's not shown), or potential side effects beyond linking to the scene. For a creation tool with no annotations, more behavioral and parameter detail would be warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no explanation for the 'name' or 'location' parameters. The defaults are visible in the schema, but their meaning, constraints, or how they affect the creation is entirely absent. The description does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: create an armature data block and object, and link it to the active scene. It specifically identifies the resource (armature) and distinguishes it from other creation tools like create_object or create_curve by focusing on armatures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies usage: use this when you need an armature. However, it doesn't explicitly mention alternatives or exclusions (e.g., when to use create_object instead). It provides no explicit 'use this when' or 'not for' guidance, but the context is clear enough for an agent to infer its role.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. The phrase 'Return' weakly implies a read-only operation, but there is no mention of side effects, safety, permissions, error conditions, or the structure of the response. For a status check, this is minimal but lacks essential context about what the tool actually does beyond the literal meaning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundancy. It states the action and resource in a compact manner, which is appropriate for a tool of this simplicity. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very simple (zero parameters) and has an output schema that likely defines the return format, so the description does not need to detail return values. However, the description lacks any context about the tool's purpose within the larger workflow—e.g., why an agent might check Poly Haven availability before downloading assets. It is minimally complete but not rich enough to guide an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema is empty (coverage is trivially 100%). The description does not need to elaborate on parameters since there are none. According to the rubric, a zero-parameter tool receives a baseline of 4, and the description correctly adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Return) and the resource (availability status for Poly Haven), which distinguishes it from sibling status tools like get_sketchfab_status. However, it does not elaborate on what 'availability status' specifically entails (e.g., online/offline, server health), leaving some ambiguity but still narrowly scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. There are related tools like get_sketchfab_status and get_geometry_nodes_status, but the description gives no context for choosing this one. It neither states when to use it nor when not to, leaving the agent to infer based solely on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the entire burden of behavioral disclosure. It only states that it lists commands, but says nothing about side effects (e.g., read-only), output format, or any operational nuances. For a listing tool this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancy. It is immediately front-loaded with the core action and resource, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument listing tool with an output schema, the description is minimal but arguably adequate. However, it omits any context about when to prefer this over the many similar listing tools, and it does not hint at the shape of the grouping. Given the breadth of siblings, a bit more context would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, which matches the baseline of 4. The description does not need to add parameter context because there are none, and it introduces no confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (List), a resource (dedicated Blender Studio Pro MCP commands), and a distinguishing organization (grouped by module). It is specific enough to separate it from many siblings, though it does not explicitly contrast with the similarly named list_dedicated_commands, so it misses 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/5
Does 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 like list_dedicated_commands, list_operator_categories, or list_tool_categories. The description only states what it does, leaving selection entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal that mode is 'hint only', meaning it does not filter results, which is beyond the schema. However, it omits other behavioral aspects like side effects (expected to be none for a list operation), permissions, or any limitations. The 'mode hint' statement adds value but the transparency is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using only two short sentences. It front-loads the primary action ('List brushes') and then adds the key behavioral detail about mode and output. It is not verbose, and every word serves a purpose, though the phrase 'mode hint only' is slightly cryptic but still understandable in context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers the essential facts: what it lists, what it returns, and the role of the parameter. It does not explain when to prefer this over sibling list tools, but for a simple list operation, this is adequate. The presence of an output schema reduces the need to describe return format. Overall, an agent can successfully invoke this tool based on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 'mode' parameter. It clarifies that mode is a hint rather than a filter, which adds meaning beyond the bare schema property. However, it does not specify what values are valid or what the hint influences. Given the minimal parameter, the description partially compensates but leaves ambiguity about possible mode values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List brushes') and the resource (brushes), and specifies the return content ('all brush names with use flags'). It distinguishes itself from sibling list tools by naming the specific resource, though it doesn't explicitly contrast with any alternative. 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions. The only hint is 'mode hint only' which clarifies the mode parameter but not usage scenarios. There is no explicit 'when to use' or 'when not to use' information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full burden for behavioral disclosure. It only states the action without revealing that listing does not modify the object, the nature of returned data (though an output schema exists), or any error conditions. A minimal disclosure leaves the agent guessing about side effects and output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It is front-loaded with the core action and scope, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the existence of an output schema, the description covers the basic operation. However, it lacks context about the tool's role within the UV workflow (e.g., that it is a non-destructive query) and leaves the parameter semantics vague, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented 'object_name' parameter. It adds the context that the object is the owner of the UV maps, but does not specify the expected format (e.g., name string, path, or identifier) or whether it must be a currently existing object. This is thin compensation for a completely undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('UV maps') with a clear scope ('on the specified object'). It clearly differentiates from sibling operations like create_uv_map, set_active_uv_map, and unwrap_uv, which involve creating or modifying maps, whereas this one lists existing ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not state that it is a read-only operation, when it is appropriate to call (e.g., before unwrapping or baking), or mention complementary tools. The agent must infer usage from the verb 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 the full burden of behavioral disclosure. It only states 'Set Background shader color/strength' without explaining whether this creates a new background node, modifies an existing one, or overwrites all other background properties. It also does not mention any prerequisites, side effects, or the fact that the world must exist. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the action and resource, and every word contributes to meaning. This is an example of efficient writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is incomplete. An agent needs more details: whether color expects normalized RGB(A) values, acceptable ranges for strength, and whether the world must exist (or be ensured) before calling. The presence of an output schema mitigates the need to describe return values, but the input semantics remain ambiguous. The defaults in the schema are hints but not documented in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It explicitly names both parameters (color and strength), which clarifies their purpose. However, it does not explain the expected format (e.g., color as an array of four floats, strength as a scalar) or any valid ranges. The defaults in the schema hint at RGBA and a float, but the description itself adds minimal semantic value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action (Set), a specific target (Background shader on the world), and the attributes being changed (color/strength). This clearly distinguishes it from siblings like set_hdri (which sets an HDRI environment) and set_color_management (which handles color management settings). An agent can tell exactly what this tool does without needing to inspect other definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context on when to use this tool versus alternatives. It does not mention that for image-based lighting one should use set_hdri, or that set_color_management handles related but separate settings. There is no guidance on prerequisites (e.g., whether a world must exist) or scenarios where this tool is the appropriate choice. The agent is left to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 action without mentioning side effects, prerequisites (existing camera/object), error handling, or reversibility. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It front-loads the verb and object, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description lacks essential context: it does not state that camera_name and target_object must refer to existing objects, nor does it describe failure modes or return values. An agent lacks enough information to call it reliably without additional investigation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'camera' and 'named object' but does not clarify that camera_name must refer to an existing camera or that target_object must be a named object, nor provide format details. Minimal added meaning beyond the parameter titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the specific resource 'Track To constraint to a camera' with the target object. It unambiguously differentiates from generic constraint tools like add_constraint by specifying the camera and constraint type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for adding a Track To constraint to a camera, but it does not explicitly state when to use it versus alternatives like add_constraint or add_bone_constraint. No exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It indicates the tool returns nodes, links, and group I/O, but does not state whether the operation is read-only, has side effects, or requires specific permissions. It also omits any error behavior or what happens if 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It front-loads the core action and resource, and then lists the specific information categories. There is no redundancy or filler, making it an effective length for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, a get operation, and an output schema that presumably defines the return structure), the description is largely complete. It specifies what the tool retrieves, and the presence of an output schema covers return values. However, it lacks any mention of usage context or potential failure modes, which slightly detracts from completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation of the 'node_group_name' parameter beyond what is minimally implied by the schema field name. The description mentions 'node group' but does not clarify what value to provide or any format requirements. Since the parameter is not self-explanatory and there is no supplementary description, the agent receives insufficient guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving detailed information about a node group, specifying the resource (node group) and the included aspects (nodes, links, group I/O). This distinctly separates it from any sibling 'get_*' tools, as it is the only one targeting node group details. The verb 'Get' and the resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or specific contexts where this tool is preferred over similar ones like 'get_gn_node_tree'. An agent is left to infer usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Return availability status,' which is almost identical to the tool name and does not explain what 'status' entails (e.g., connectivity, service health, error handling). It also doesn't state that this is a read-only network check or any potential side effects. The description adds little beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. For a zero-parameter status check, this length is appropriate and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema covers return values, so the description doesn't need to explain them. However, given the lack of annotations and minimal prose, it might be helpful to mention that this checks network connectivity to Sketchfab or that it is a lightweight read-only call. Still, for a trivial tool, the description is functionally complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly implies there are no parameters to explain. Since the schema is empty and coverage is 100%, there is nothing more to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and resource ('availability status for Sketchfab'), which is clear. However, it does not differentiate from sibling tools like get_polyhaven_status, which follow the same pattern. It is not a tautology but lacks distinguishing context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_polyhaven_status or get_geometry_nodes_status. There is no mention of preconditions, exclusions, or specific scenarios. The agent is left to infer that it is for checking Sketchfab availability without any comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral details. It only states the action without explaining whether the screenshot saves to a file, returns image data, or has side effects. The optional 'filepath' parameter hints at saving, but its behavior is unexplained, leaving the agent unaware of the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no fluff. It is well-structured and front-loaded, focusing on the core action without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter and an output schema, but the description does not explain what happens with the screenshot or what the output contains. The filepath parameter is undocumented, and there is no mention of return values or side effects. This is inadequate for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter semantics. The single parameter 'filepath' is not mentioned at all. The agent cannot infer whether it is a destination path, source path, or what the default null means. This is a critical omission for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('capture') applied to a specific resource ('screenshot of the active 3D viewport'). It is distinct from sibling tools like render_image and render_turntable, indicating exactly what operation is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: to capture the current 3D viewport. However, it does not explicitly state when not to use it or mention alternatives (e.g., render_image for offline rendering), leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 behavioral disclosure. It only states that it lists commands, implying a read-only operation, but doesn't mention side effects, limitations, or return semantics. No additional behavioral context beyond the basic action 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence without any fluff. The purpose is front-loaded and the wording is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with no parameters and an output schema, the description provides the essential purpose. It doesn't elaborate on what ' dedicated high-level commands' means, but that is domain knowledge. The definition is sufficiently complete for agents to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so the baseline is 4. The description doesn't need to add parameter details as none exist, and it correctly omits them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'dedicated high-level commands registered in this addon.' It distinguishes from generic list tools like 'list_blender_commands' by specifying 'dedicated' and 'in this addon,' 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling list tools such as list_operators or list_blender_commands. The agent must infer from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the important side effect of unlinking from all current collections, which is valuable. However, it does not mention potential failure modes, return values, or what happens if the object is already in the target collection, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded with the core action and side effect. No filler or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and minimal schema detail, the description is incomplete. It lacks information about prerequisites (e.g., object existence, collection existence), error handling, return output, and edge cases. With an output schema present but not described, the agent is left guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It does nothing beyond restating the parameter names. No additional context like expected types, formats, or relationships between object_name and collection_name is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Move', the resource 'object', and the target 'collection', and includes the key side effect of unlinking from all current collections. This distinguishes it from sibling collection-related tools like instance_collection or create_collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context (moving objects between collections) but does not explicitly mention when to use this vs alternatives like instance_collection or set_parent. No explicit 'when not to use' or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 action ('parent') and the skinning method, but does not mention side effects (e.g., whether vertex groups are auto-created, whether an Armature modifier is added, or whether existing parents are overridden). This is a mutation operation and lacks important transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and object. There is no wasted text, and it communicates the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the operation's complexity (parenting with skinning) and the lack of annotations, the description is incomplete. It does not mention the outcome for the mesh (e.g., modifier behavior, vertex group creation) or any required prerequisites (e.g., the mesh must have an existing armature modifier). The existence of an output schema partially mitigates return format, but side effects and prerequisites remain uncovered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter semantics. It indirectly references the 'method' parameter via 'skinning method' but does not explain the possible values (e.g., AUTOMATIC, BONE_RELATIVE) or clarify mesh_name and armature_name beyond what the names imply. This is insufficient for a tool with no schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Parent') and a specific resource ('a mesh object to an armature'), and further narrows the operation with 'specified skinning method'. This distinguishes it clearly from generic parenting tools like set_parent and clear_parent, which are present among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for skinning a mesh to an armature, but does not explicitly state when to use this tool versus alternatives like set_parent or create_armature. No exclusions or alternative routing are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It indicates a mutation ('remove') but does not mention side effects, error handling (e.g., if the node does not exist), reversibility, or any prerequisites. For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no redundant wording. Every word contributes to the core function, making it efficiently front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and 0% schema coverage, the description should provide more context about parameter usage, error behavior, and potential consequences. It lacks any explanation of the required fields or what happens on failure, leaving an 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It does not mention node_group_name or node_name, leaving their semantics entirely to inference from names. Even though the names are somewhat descriptive, the tool 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Remove a node') and a clear resource context ('from a geometry node group'). It is not a tautology and distinguishes from siblings like add_geometry_node or connect_gn_nodes by indicating the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The clear verb and context imply when to use it (when a node should be removed from a geometry node group), but it does not mention alternatives or exclusions. It provides clear context without explicit 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It does reveal the key behavior that only provided values are updated, which is important and prevents accidental resets. However, it does not mention error handling, required permissions, or what happens if the object does not exist, leaving room for more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. The core action and the crucial partial-update caveat are front-loaded, making it highly efficient. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters with 0% schema coverage and no annotations, the description is far from complete. It does not describe the parameters, their types, or any constraints. An agent would struggle to correctly format a call, especially without knowing that scale, location, and rotation likely expect vector triplets. The tool is simple but the description leaves too much to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only implies that scale, location, and rotation are optional and partially updated, but it does not explain their expected format (e.g., vector arrays, units, coordinate space) or the meaning of the required 'name' parameter. This is insufficient for an agent to construct valid arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and the resource 'transform of an object', which distinguishes it from sibling tools like set_pivot_point. The added note 'Only provided values are updated' specifies partial updates, making the purpose even more precise. No ambiguity about 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. It does not reference other transform-related tools or explain that this should be used for changing scale, location, or rotation. The description is purely definitional and lacks context for an agent to decide between this and other set_* commands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. The description only says 'Add a Geometry Nodes modifier', which is a mutation, but it does not mention side effects, required object state, error conditions, or whether the operation is reversible. It provides minimal transparency beyond the basic action, leaving an agent without clues about failure modes or consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action. Every word is purposeful, with no filler. It efficiently communicates the tool's function in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters and an output schema exists, so complexity is low. The description covers the main use case but omits details like error handling, what happens if the object or node group does not exist, and whether a new node group is created when 'node_group_name' is null. It is adequate for a simple tool but could be more complete, especially since no annotations provide extra context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), so the description must explain the parameters. The description clarifies that an existing node group can be used ('optionally using an existing node group'), which gives meaning to 'node_group_name'. However, it does not explain 'object_name' beyond its obvious meaning, nor does it detail the expected format of the node group name or what happens if it is omitted. The description is insufficient to fully understand parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a Geometry Nodes modifier to an object', specifying the exact resource type and target. It distinguishes this from the generic 'add_modifier' sibling by focusing on the specific modifier type. The sentence is unambiguous and leaves no doubt about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (for adding a Geometry Nodes modifier), but it does not explicitly contrast with alternatives like 'add_modifier' or provide guidance on when not to use it. There is no mention of prerequisites or conditions that would make this the preferred choice. The usage context is 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?
No annotations exist, so the description carries the full burden. It discloses that the tool returns the node tree, which implies read-only behavior, but it does not explicitly state that it has no side effects or describe error handling (e.g., what happens if the node group does not exist). The description is not misleading, but it lacks explicit behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the primary action and result. It contains no filler or repetition, making it highly efficient for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return structure is defined separately. However, the description lacks contextual details such as prerequisites (e.g., node group must exist), whether it is specific to geometry nodes (though the name implies), or any limitations. For a simple get operation with one parameter, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not compensate. It does not explain the node_group_name parameter beyond its name, leaving ambiguity about what constitutes a valid name, how to discover it, or any constraints. Since the parameter is required and undocumented, the description should provide more guidance but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (return the full node tree structure) and implies the resource (a node group via the parameter). The phrase 'full node tree structure: nodes with input values and links' is specific and distinguishes it from siblings like get_node_group_info, which likely returns summary info. The tool name also explicitly indicates geometry nodes, reinforcing the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any specific conditions or exclusions, nor does it point to sibling tools for different scenarios. An agent must infer usage from the name and surrounding tools, but no explicit direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing behavioral traits. It only states the action without mentioning side effects (e.g., whether it modifies selection, requires edit mode, or affects existing bones). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It front-loads the primary action and key parameters, and every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and an output schema exists (though not shown), so return values need not be described. However, the description omits prerequisites (e.g., the armature must exist, edit mode requirement) and any context about the operation's effect on the scene, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'specified head/tail positions' (covering head and tail) and 'optional parent' (covering parent_bone), but does not detail armature_name and bone_name beyond inference from 'armature' and 'bone'. It adds some clarity over the schema (e.g., 'optional parent') but not complete compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a bone'), the resource ('to an armature'), and the key parameters ('head/tail positions and optional parent'). It distinguishes this from sibling tools like delete_bone, set_bone_property, and list_bones by conveying it is for creation, not modification or 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (use this to add a bone) but does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. For a basic creation tool, this implicit guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It accurately describes the core action (creating a material and connecting an emission shader), but it does not disclose side effects, requirements (e.g., active object), or whether it replaces existing materials. The transparency is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the action and is appropriately concise, containing exactly the information needed to state the tool's purpose without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, an output schema, and no annotations, the description is too sparse. It omits parameter semantics, usage context, and any behavioral constraints, leaving the agent without enough information to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description does not explain any of the parameters (name, color, strength). The agent must infer meaning from names and defaults, which is insufficient for accurate invocation, especially for color's expected format and strength's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Create a material' and specifies that an Emission shader is connected to the output. This distinguishes it from generic tools like create_material and create_glass_material, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when an emissive material is needed, but it does not explicitly state when to use it versus alternatives like create_material or create_glass_material, nor does it mention 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the core action (adjusting camera position and orientation) but does not disclose side effects, error behavior (e.g., missing objects or camera), or whether the camera's transform is permanently modified. It is adequate for a simple operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clean sentence that is front-loaded with the essential action and scope. Every word contributes to the meaning, with no filler or redundant qualifiers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a camera framing tool with two parameters and no annotations, the description covers the core function but omits usage context such as prerequisites (objects must exist, camera must exist) and does not distinguish when to prefer this over frame_selected. Since an output schema exists, return value explanation is not required, but the description is not fully complete for an agent to invoke correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only indirectly refers to 'camera' and 'listed objects' without explaining the expected format or value types of camera_name and object_names. The description does not clarify that camera_name should be an existing camera identifier or that object_names is a list of valid object names, so it adds minimal value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase ('Position and orient') with a clear resource ('a camera') and a precise scope ('frame the listed objects'). This distinguishes it from sibling tools like frame_all and frame_selected, which do not accept an explicit object list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage (frame specifically listed objects rather than all or the current selection) but does not explicitly state when to use this tool over alternatives like frame_selected. No exclusions or alternative conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation returns a list (a read operation) and mentions properties, but does not describe potential side effects (none expected), error conditions (e.g., nonexistent armature), or the structure/format of the returned list. It offers basic transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. Every word contributes to understanding the tool's purpose, with no filler or redundant detail. This is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and an output schema exists (so return details are not required), the description omits critical context such as error handling for missing armatures, the nature of 'properties' returned, and any preconditions (e.g., armature must exist). The lack of annotation coverage further amplifies these gaps. For a basic listing tool, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the parameter 'armature_name'. The tool description only reuses the term 'armature' without elaborating on its format, requirements, or relationship to the returned data. Since the description fails to compensate for the missing schema metadata, the parameter semantics are under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action ('Return a list') and resource ('all bones in an armature') with mention of properties. It distinguishes itself from sibling tools like add_bone, set_bone_property, and delete_bone by focusing on retrieval, and from other list_ tools by targeting bones specifically. This is a precise 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no explicit guidance on when to use it relative to alternatives. There's no mention of contexts like 'use before modifying bones' or references to other bone-related tools. The intended use is inferable from the name and description, but explicit routing is 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it lists names, but does not describe the output format, whether it returns a flat list, any filtering, or if it is read-only (though it can be inferred as read-only). The existence of an output schema helps, but the description itself does not add behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that is front-loaded with the core action and resource. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-less listing tool, the description is adequate to understand its purpose. The existence of an output schema (referenced in signals) presumably covers return details. However, given the many sibling tools, a brief note on what distinguishes this from 'list_data_items' would improve completeness, but it is not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document. The schema coverage is trivially 100%, and the description adds no parameter-specific info; per the guidelines, a baseline of 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the exact resource ('bpy.data collection names') with concrete examples (objects, meshes, materials). It clearly distinguishes from siblings like 'list_data_items' or 'list_collections' by focusing on Blender's data-block collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With many sibling tools that list similar entities (e.g., 'list_data_items', 'list_collections', 'list_materials'), the description should clarify the intended use case or contrast with these options, but it does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 says 'Return' which implies a read-only operation, but it does not explicitly state there are no side effects or require an active scene. It does mention the output is 'categorized dictionary', which gives some structural insight, but lacks detail on whether the list is exhaustive or if it requires a specific context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It front-loads the action ('Return') and the resource ('categorized dictionary'), making it immediately clear what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (which covers return values), the description is essentially complete for calling the tool. It clearly states the output type ('categorized dictionary') and the domain ('geometry node types'). The only minor gap is not elaborating on what categories exist, but that is likely covered by the output schema. This is a simple listing tool, so the minimal description suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides full coverage. According to the calibration, a baseline of 4 is appropriate when there are no parameters. The description adds no parameter information because there are none to describe, but this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a specific resource ('categorized dictionary of available geometry node types'). It clearly distinguishes this tool from sibling listing tools like list_data_types and list_operator_categories by focusing on geometry node types, so an agent can tell its purpose immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions. An agent must infer from the name that it is for geometry node types, but there is no explicit direction on when to prefer this over list_data_types or other node-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'live', suggesting real-time data, and states a default limit, which gives some insight into its behavior. However, it does not disclose whether the operation is read-only, whether results are paginated beyond the limit, or any side effects. The description adds minimal context beyond the schema, so it's at an acceptable baseline but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with three concise clauses: action ('List operators'), qualifier ('live'), filtering options, and default limit. It is front-loaded with the core purpose and contains no unnecessary words. Every part adds value, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (so return values are not needed in the description), the description covers the essential aspects for calling: the action, available filters, and default limit. It does not mention pagination behavior or further semantics of the filters, which could be useful, but for a simple list operation it is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly mentions 'category and/or search', mapping to the category and search params, and 'default limit 500' explaining the limit param. This provides some semantic linkage but does not detail what search matches on (e.g., name, description) or how category filtering works. It partially compensates for the lack of schema descriptions but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists operators, with a specific verb and resource. It also mentions filtering, which clarifies it's a query tool. However, it does not explicitly differentiate from siblings like search_operators, which also deals with operators, though the naming suggests a distinction. Overall the purpose is clear but the description could be more explicit about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by mentioning filtering by category and/or search, and a default limit of 500. It implies when to use this tool (to list operators with optional filters). However, it lacks explicit guidance on when not to use it or which alternative to choose (e.g., search_operators). It leaves the decision to the agent, so it's adequate 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?
With no annotations, the description must carry behavioral transparency. It discloses the effect of keep_transform ('optionally keeping its world transform'), which is useful. However, it does not mention side effects like whether the operation is reversible, what happens to the object's transform if keep_transform is false, or any other implications of the mutation. It adds some value but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and appends the optional behavior. It is concise with no wasted words, making it efficient for an agent to process.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple operation with two parameters, an output schema, and no nested objects, the description covers the essential behavior (clearing and optional transform). It does not explicitly mention return values or potential errors, but these are likely covered by the output schema and are not critical for this straightforward action. The main gap is the lack of guidance on differentiating from set_parent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the effect of keep_transform but does not describe the 'name' parameter, which is likely the object name. The description adds value for one parameter but leaves the other undocumented, resulting in a partial but not complete explanation of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Clear the parent of an object.' It uses a specific verb and resource, and the optional transform behavior adds nuance. It implicitly differentiates from set_parent by focusing on removal, so an agent can easily understand the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage (it's a clearing action) but provides no explicit guidance about when to use it versus the sibling set_parent, nor does it mention any exclusions or conditions. The use case is fairly evident from the action itself, but the lack of explicit alternatives or when-not-to-use reduces the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 states it lists actions but does not explicitly confirm that the operation is read-only or side-effect free. It also lacks context about scope (e.g., all actions in the current scene or globally) or any performance implications. The minimal description leaves these behavioral traits 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the action ('List') and immediately specifies the scope ('all actions') and the key detail ('frame ranges'). 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema available, the description is sufficient. It fully conveys what the tool does, and the output schema handles return value details. Nothing crucial is missing for an agent to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is vacuously 100%. With no parameters to document, the description does not need to add parameter semantics. The baseline of 4 applies given the zero-parameter context; there is nothing to augment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and resource ('all actions') with additional detail ('frame ranges'), which is specific and distinguishes it from related tools like create_action or assign_action. It unambiguously tells an agent 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you need to see all actions and their frame ranges, this is the tool. However, it does not explicitly state when to use this versus alternatives, nor does it mention any context or exclusions. The guidance 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?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core behavior (redoing an undone action) but does not disclose potential failure conditions (e.g., no undo history, redo buffer cleared) or side effects beyond the literal action. It is not misleading or contradictory, but it provides minimal transparency about the operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key action. There is no redundant information or fluff, making it highly efficient for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple with no parameters and has an output schema, the description lacks important contextual details such as the requirement that an undo must have occurred, the behavior if called multiple times, or whether the redo buffer is cleared after a new action. These omissions mean the agent might call it in an invalid state. Given the low complexity, it is complete enough for basic use but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema description coverage is 100% (empty schema). Since there are no parameters, the description need not add parameter explanations. The baseline for zero parameters is 4, and the description appropriately focuses on the action itself without parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Redo last undone action' clearly states the verb (redo), the resource (last undone action), and implies the inverse relationship to its sibling 'undo'. It is unambiguous and distinguishes itself from the sibling tool without needing additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While it implies redo is the opposite of undo, it lacks guidance on prerequisites (e.g., must have just undid an action) or conditions for use. There is no mention of alternatives or exclusions, so it only provides implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states this is a read operation (non-destructive), which is transparent. However, it does not disclose error behavior for invalid paths, supported value types, or whether it can access any attribute in the Blender data model. The examples hint at syntax but don't specify edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose ('Read a value via path') and immediately gives examples. Every word earns its place; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, this is largely complete. The return format is covered by the output schema, and the examples clarify path syntax. The main gap is lack of error-handling details and explicit statement of supported path forms, but these are minor for a read operation in an environment with many sibling getters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter 'path', so the description must compensate. It does this effectively by providing two concrete path examples that illustrate the syntax (dot notation for attributes, bracket notation for indices/keys). This adds meaningful semantic guidance beyond the empty schema field, though it doesn't formally define the grammar.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads a value via a path, with concrete examples ('context.scene.frame_current', 'data.objects["Cube"].location'). It distinguishes itself from the sibling set_attr_path by being the read counterpart. The verb+resource is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for reading arbitrary values via a path, but it gives no explicit guidance on when to use this instead of specific getter tools like get_object_info or get_scene_info. It does not mention any exclusions or alternatives, leaving the agent to infer that it's a generic low-level read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral disclosure. It states the tool returns information, but does not explicitly mention that it is read-only or that it has no side effects. However, the 'get' prefix strongly implies a non-destructive operation, and there are no obvious side-effect concerns for a scene information query. It doesn't disclose any potential errors (e.g., no scene open) or performance impacts, so it's minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the action and target, making it immediately understandable. It earns its place perfectly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with an output schema, the description is sufficient. It tells the agent what to use it for, and the output schema presumably details the return structure. While it doesn't enumerate what 'comprehensive information' includes, that level of detail is better left to the output schema. It lacks explicit guidance on error conditions, but that's a minor gap for such a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which according to the rubric sets a baseline of 4. The description doesn't need to explain any parameters, and it correctly avoids introducing any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns comprehensive information about the current Blender scene. The verb 'Return' and the resource 'current Blender scene' are specific, and it naturally distinguishes itself from sibling getters like get_camera_info, get_world_info, and get_object_info, which target narrower scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose is self-evident from the name and description; there is no explicit guidance on when to choose this over other info tools. While it is implied that this is the go-to for overall scene state, the description doesn't mention alternatives or conditions, so an agent might not know when to prefer, say, get_scene_info over get_camera_info. This is adequate but lacks explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden of behavioral disclosure. '100% live' conveys that the tool introspects the actual Blender build at call time, which is a meaningful behavioral trait distinguishing it from static or precomputed lists. However, it does not disclose output structure (though the output schema exists), any latency implications of live introspection, or whether the result is cached. For a zero-parameter listing tool this is a reasonable but not comprehensive disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single eleven-word fragment that conveys action, scope, and a key behavioral qualifier with zero waste. The '100% live' information is front-loaded and earns its place by distinguishing the tool from cached alternatives. Nothing is redundant; every part of the description contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with a defined output schema, the description is adequate and complete. It tells the agent what the tool returns (the full list of bpy.ops submodules) and the freshness guarantee ('100% live'). The output schema covers return-value structure, so the description need not duplicate that. The only minor gap is that it doesn't hint at sibling tools like list_operators or search_operators for when the agent needs finer-grained filtering, but this is a list-enumeration tool where the use case is self-evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters with schema description coverage at 100% (no properties at all), so baseline is 4. The description adds semantic value by clarifying that the output reflects the live build rather than a stale snapshot, which contextualizes why no parameters are needed — the tool has no inputs because it enumerates the environment. This is exactly the kind of meaning beyond the empty schema that earns the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States an unambiguous action and resource: 'List every bpy.ops submodule available in this Blender build'. Specifies the scope precisely as bpy.ops submodules, which distinguishes it from sibling tools list_operators, search_operators, get_operator_info, and list_tool_categories without needing to inspect schemas. The qualifier '100% live' adds specificity about the nature of the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it — when you need a complete, current enumeration of operator categories — and the '100% live' qualifier implies freshness may matter versus cached alternatives. However, it does not explicitly name sibling tools (list_operators, search_operators, get_operator_info) or state when NOT to use it, e.g., after the user has changed the build (where 'live' would be redundant). No exclusions or alternatives are given, so 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Return' clearly implies a read-only operation with no side effects. The behavior is transparent for a getter with no parameters. However, it does not mention potential error conditions (e.g., if no object is active) or what the returned mode's format is, but the output schema likely covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key action ('Return'). Every word earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter with an output schema (as indicated by 'Has output schema: true'), the description is complete. It states exactly what is returned, and the output schema handles the return structure. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the schema is empty (100% coverage). Baseline for 0 params is 4. The description adds nothing about parameters because none exist, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Return current object interaction mode.' It uses a specific verb and resource, and the pairing with the sibling 'set_mode' immediately differentiates it. No ambiguity about 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that this is a read-only counterpart to 'set_mode', nor does it specify any context (e.g., 'use this to check the current mode before modifying'). For a simple getter, some direction would be helpful, but it's entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It implies a read-only operation by saying 'Return a list,' but does not explicitly state that it has no side effects, nor does it mention any ordering or determinism. For such a simple list tool, this is acceptable but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states exactly the action and scope with zero 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—no parameters, an output schema already present, and a straightforward return value—the description is fully sufficient. Nothing an agent needs to call correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is fully described (empty object). With 0 params, the baseline is 4, and the description adds 'all' and 'in the scene' as scoping context, which is slightly beyond the trivial. No parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and resource ('list of all camera objects') with an explicit scope ('in the scene'). This clearly distinguishes it from sibling tools like get_camera_info (singular info) or create_camera (creation) 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use the tool (when you want all cameras), but it does not explicitly name alternatives or state when not to use them. Given the simplicity, this is adequate but lacks the explicit routing seen in higher-scoring definitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 clearly indicates a non-destructive read operation ('Return a list'), but it does not disclose potential edge cases such as behavior when the scene has no lights, nor does it mention ordering or any side effects. For a simple list tool, this is adequate but lacks explicit reassurance about being safe and side-effect-free.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no filler. It immediately states the action and resource in a compact form, making it easy for an agent to parse and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema is provided, the description fully covers what an agent needs to know. It specifies the exact resource (all light objects) and scope (in the scene), leaving no ambiguity about the tool's behavior. The presence of an output schema handles return format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has no parameters; the schema is empty, so schema coverage is trivially 100%. The description adds no parameter information because none is needed. According to the rubric, zero parameters warrant a baseline score of 4, and there is no gap to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return a list of all light objects in the scene' uses a specific verb (return), a specific resource (light objects), and a clear scope (all in the scene). It unambiguously distinguishes this read-only listing tool from siblings like create_light, delete_light, and set_light_property, which perform different actions on lights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you need to know what lights exist, call this tool. However, it does not explicitly state when to use it over alternatives or mention any exclusions. It lacks any statement like 'Use this to inspect lights before modifying them' or 'This returns all lights, not a filtered subset.' The guidance is entirely 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?
No annotations are provided, so the description carries the full burden. It correctly indicates this is a read operation via the verb 'Return', but it does not explicitly state whether the tool has side effects or requires any state. However, for a pure getter with no parameters, the lack of side-effect disclosure is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. It immediately states the action and the result, making it maximally efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a getter with no parameters and an existing output schema, the description fully covers what an agent needs to know to call it correctly. The return format is presumably specified in the output schema, so the description need not elaborate further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The schema coverage is 100% (empty), and the description adds no parameter information because none exist. No further compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and a specific resource ('selected object names and active object'). It clearly distinguishes this as the read counterpart to the sibling set_selection, providing immediate semantic differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for retrieving selection state, which is evident from the verb and resource. While it doesn't explicitly name alternatives or exclusions, the purpose is self-evident and no additional routing guidance is necessary for such a simple getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states a read-only action ('Return a list') with no side effects. While it doesn't discuss edge cases like an empty blend file or error conditions, the behavior is straightforward and accurately disclosed. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It conveys the complete purpose in a compact form, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter listing tool with an output schema present, the description is fully complete. It provides all necessary information for an agent to decide when to call it, and the output schema covers return values. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. According to the rubric, a baseline of 4 applies for zero-parameter tools. The description does not need to explain parameters, and it doesn't miss anything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and resource ('a list of all material names in the blend file'), with a clear scope ('all' and 'in the blend file'). It is unambiguous and easily distinguished from sibling material tools like create_material or get_material_info because it explicitly describes a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent would naturally select this when it needs to enumerate all material names. However, there is no explicit mention of when to use this over alternatives (e.g., get_material_info for detailed info on a specific material) or any exclusions. The guidance is thus adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states the tool checks connectivity, which implies a read-only operation, but does not mention what it returns or any side effects (though none are expected). For a tool this simple, the description is adequate but minimal; it does not contradict any annotations (none exist) and adds basic behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is front-loaded with the core action. It contains no unnecessary words and efficiently conveys the tool's purpose. Perfectly sized for the trivial scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, a clear function) and the presence of an output schema (which handles return values), the description is complete. An agent can correctly select and invoke this tool without additional context. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to add. The schema is empty and fully covers the parameters, and since no parameters exist, the baseline per instructions is 4. The description does not need to elaborate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and a clear resource ('connectivity to Blender Studio Pro MCP addon on localhost'). It unambiguously states the tool's function and distinguishes it from the many sibling tools that perform specific operations, as this is the only connectivity check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool—to verify the addon is reachable before making other calls. It does not explicitly name alternatives or exclusions, but for a ping tool the use case is self-evident. It provides sufficient context without needing to list when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![Blender-Studio-Pro-Mcp MCP server](https://glama.ai/mcp/servers/cristoferarango/Blender-Studio-Pro-Mcp/badges/card.svg)](https://glama.ai/mcp/servers/cristoferarango/Blender-Studio-Pro-Mcp)

Score Badge

Copy to your README.md:

[![Blender-Studio-Pro-Mcp MCP server](https://glama.ai/mcp/servers/cristoferarango/Blender-Studio-Pro-Mcp/badges/score.svg)](https://glama.ai/mcp/servers/cristoferarango/Blender-Studio-Pro-Mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cristoferarango/Blender-Studio-Pro-Mcp'

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