Blender Finisher
Server Quality Checklist
Latest release: v0.2.2
- Disambiguation2/5
Even with domain prefixes, the sheer number of similar verbs (report, list, get, describe, info) and overlapping generic operators (rna-call_operator, capabilities-invoke, ui-operator_invoke, system-execute_python) create serious ambiguity. Tools like mesh-report, feedback-topology, and feedback-capture all serve vaguely related 'mesh/visual inspection' purposes, and many read-only variants have unclear boundaries.
Naming Consistency3/5The domain-hyphen-action format is consistently used and readable. However, the action half mixes verb_noun and noun-only patterns (outliner-view_layers, outliner-orphans, script-paths) and uses many verbs interchangeably for the same kind of operation (list, report, get, read, describe). This reduces predictability despite the overall structural consistency.
Tool Count1/5305 tools is an extreme count that far exceeds any reasonable agent navigation surface. Even with domain grouping, the size alone makes it impractical to discover and select the right tool, and many tools are redundant generic escape hatches.
Completeness3/5The surface is very broad and covers most core Blender workflows, with generic invoke tools filling some gaps. However, there are notable missing lifecycle operations such as scene create/delete, material deletion, and many object-type deletions (camera, light, speaker, volume). The set is also asymmetric—heavy on create/report/set, lighter on remove/delete operations.
Average 3.1/5 across 284 of 305 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 341 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Set' which implies mutation, but doesn't describe side effects, permissions, or what happens to existing data. No detail on how the tool modifies geometry, making it impossible for the agent to anticipate outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one line and severely under-specified. It's not concisely informative—it's simply too short to convey necessary information. Every hint of value is missing, so this is not good conciseness but lack of content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, no annotations, no output schema, and a 0% schema description coverage. The description 'Set curve-like geometry data fields' provides almost no context for how to invoke the tool correctly. It is wholly 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions none of the nine parameters (extrude, fill_mode, dimensions, bevel_depth, etc.). The schema titles provide some hints but the description adds no additional meaning or usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set curve-like geometry data fields' uses a clear verb and resource but is extremely vague. It doesn't specify which curve properties are affected or differentiate from sibling tools like geometry-set_bezier_spline, which is more specific. The generic 'curve-like' phrasing fails to convey the tool's 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 Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool versus alternatives, no prerequisites, and no exclusions. The description offers zero context for the agent to decide 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)Skip. The description does not disclose what the tool does to the scene: whether the object is copied, whether settings are preserved, what the 'linked' parameter does at a behavioral level, or any side effects. This is a mutation tool with zero 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence is technically concise, but this is under-specification, not conciseness. The description omits essential behavioral details that an effective description should convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no annotations, no output schema, and no additional description, the agent is left to guess at semantics like linking behavior, offsets, and naming. This description is insufficient for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds zero parameter documentation. The four parameters (name, linked, object, offset) have short titles but no semantic explanation beyond header names. No compensation from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Duplicate an object' uses a clear action verb and resource, so it at least names what the tool does. However, it does not distinguish duplication from related operations like object-create or object-transform_set, nor does it note the duplication's scope or behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, and the context signals include many object-related tools without any differentiation. There are no prerequisites, exclusions, or notes on how 'linked' duplication differs from full duplication.
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 convey side effects. It only says 'Set', implying a mutation, but does not mention potential consequences, required permissions, or what happens to existing data. The description is too sparse for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but it omits essential details. It could be slightly longer without losing conciseness to clarify RNA properties and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, output schema, or additional context, the description is incomplete. It does not state what the operation returns, how errors are handled, or any side effects on the lattice object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides minimal descriptions for each parameter (value, object, property), but the tool description adds no additional clarification. It does not explain the format of 'value' or what kinds of 'property' strings are valid, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states that it sets an RNA property on lattice data, but 'RNA property' is not explained, and it's unclear how this differs from sibling tools like lattice-point_set. It identifies the action (set) and target (lattice data) but 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 Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as lattice-point_set or lattice-report. There is no context for choosing this operation over similar ones.
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, and the description reveals no side effects, permissions, or potential impacts (e.g., object rotation/scale being reset). It does not disclose any behavioral traits 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, which makes it concise, but it is too short to be informative given the tool's complexity. It lacks a proper structure to convey necessary details, though it does avoid verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to provide sufficient context. It does not explain what applying a transform means, the effect on the object, or the role of the parameters. Without this, the tool is not adequately described for a user to understand its functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no extra meaning to the schema parameters. The boolean flags (scale, location, rotation, properties, isolate_users) are not explained, leaving their purpose unclear from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Apply') and the resource ('an object's transform'), but it is vague and does not distinguish this from sibling tools like object-transform_set or object-origin_set. It lacks specificity on what 'apply' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or why one would choose this over similar transform operations.
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 side effects, mutation risks, or any special behavior. The description only says 'Set common light data properties' with no indication of whether this is destructive, reversible, affects other properties, requires permissions, or returns anything. 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
At one sentence, it is concise, but the brevity is actually under-specification. It does not front-load any useful details, and every word is generic. There is no attempt to prioritize the most important aspects (like that it requires a light name). This is not effective conciseness; it is telegraphic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters and no annotations or output schema, the description should provide substantial context about what it does, what it returns, and any side effects. It provides none. The agent cannot adequately plan a call or understand the effect of changing 'size' vs 'energy' without additional research.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description does not mention any of the six parameters (size, color, light, energy, spot_size, spot_blend). With zero description compensation, the agent only has the schema titles to infer meaning. The description provides no additional context on parameter relationships, defaults, or special requirements, leaving semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Set' and the resource 'light data properties', indicating the tool modifies properties of a light object. It is clear that this is a setter, but it's ambiguous what specific properties are considered 'common' and it doesn't distinguish from other light-related tools (e.g., light-create, light-report). It also doesn't clarify if it's for all light types or specific 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description does not mention any prerequisites, recommended use cases, or when not to use it. Given the context signals include many other light and scene tools, this lack of usage guidance leaves 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 details are disclosed. The tool mutates the mesh but there is no mention of whether it requires edit mode, whether it modifies the active object, or what happens if no selection is present. With no annotations, the description leaves all behavioral aspects to the agent's imagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it lacks structure. It is not front-loaded with the most critical information; it only partially states purpose and omits usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of mesh editing and the absence of annotations and output schema, the description is severely incomplete. It does not explain selection requirements, mode constraints, or how the resulting edge/face is determined, making the tool nearly unusable without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'object' is described only by its title ('Mesh object to edit (defaults to active)'), which provides some meaning but not enough to understand how to specify it (e.g., by name or ID). The schema coverage is 0%, so the description does not add any detail about the parameter's format or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a general action ('Create an edge or face') but lacks specificity about what input is required (selected elements, edges, vertices) and how it relates to the 'add' operation. It is vague and does not distinguish from similar mesh tools like mesh-fill or mesh-extrude.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., selection mode, being in edit mode) or scenarios where this tool would be preferred over mesh-fill or other geometry creation 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. It does not disclose any side effects, return values, or what happens in the scene (e.g., whether it creates a new object, replaces existing ones, or commits changes). The one-line description provides no behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, so it is structurally concise. However, it is too under-specified to be considered appropriately sized for a tool with 6 parameters and no annotations. It does not front-load key information like the full range of primitives it can create.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is severely incomplete. It does not mention the enumerated types, the coordinate system for location/rotation, or any prerequisites. The description is inadequate for an agent to understand the tool's full capabilities and invocation requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds no meaning beyond the schema titles and types. It does not explain how parameters like 'type', 'scale', or 'radius' interact, nor does it clarify the meaning of the CURVE and CIRCLE options in a surface creation tool. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a NURBS surface primitive' which is a clear verb and resource, but it is misleading because the 'type' enum includes CURVE, CIRCLE, and other non-surface primitives. It does not accurately distinguish from sibling tools like geometry-create_curve, making the purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, exclusions, or alternatives. The minimal 'Create a NURBS surface primitive' implies usage, but it lacks explicit direction to disambiguate from other creation 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 available, so the description must carry the full explanatory burden. It only restates the tool name-prefix 'create' and provides no extra behavioral context such as side effects, duplication behavior, validation, or required preconditions. The description adds no value beyond the tool's own name, so transparency is nearly absent (1/5).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short single sentence with no redundant words, but it is under-specified rather than concise. It contains only the bare restatement of the tool's purpose, offering no additional structure or front-loaded context that aids the agent. A score of 2 reflects under-specification while acknowledging the absence of verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a simple create operation, the description omits critical context: what happens if a vertex group with the same name already exists, whether the mesh must be a particular type, whether selections are used, or any error conditions. With no output schema and no extra description details, the tool leaves too much to infer. The description is incomplete for a tool that creates a data entity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description 'Create a mesh vertex group' does not elaborate on the parameters 'mesh' or 'name'. While the schema provides titles ('Mesh object to edit', 'Vertex group name'), the description contributes no additional semantic context and does not compensate for the lack of coverage. With 0% schema coverage and a non-explanatory description, a score of 1 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a mesh vertex group' uses a specific verb ('Create') and resource ('mesh vertex group'), making the primary action clear. It does not explicitly differentiate from sibling tools like rig-vertex_groups (list) or rig-assign_weights, but the intent is unambiguous. According to the rubric, this fits 'clear but no sibling differentiation' (4/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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, no prerequisites, and no use cases or exclusions. The description merely restates the tool's function without explaining when an agent should choose it over similar rigging tools. This is 'no guidance' (1/5).
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. While 'report' implies a read-only operation, the convoluted phrasing fails to state whether this mutates state, requires specific conditions, or returns any specific output. This is critically inadequate for a tool with no other metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but achieves this at the cost of clarity. It is an awkward sentence fragment where 'metadata surface' is an opaque, undefined phrase, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter structure, the description is the sole source of information, and it is grossly insufficient. The agent cannot learn what 'live Blender API operator/type metadata surface' means, what will be reported, or how this differs from the many sibling tools. Completely inadequate for any operational use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per rubric the baseline is 4. There are no parameters to document or clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Report' as a verb and 'live Blender API operator/type metadata surface' as the object, but the phrasing is grammatically ambiguous — 'surface' could be a noun or verb — and the tool's actual function remains unclear. It does not meaningfully distinguish this from sibling report tools like particles-report or mesh-report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, when not to use it, or what alternatives exist. With dozens of sibling tools, the lack of any usage context or exclusions leaves 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?
With no annotations available, the description carries the full burden of behavioral disclosure, but it only states 'Create a grease pencil object.' It does not explain what happens to existing objects, how the object is positioned, what the return value is, or any side effects. This is a minimal, non-informative description 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (5 words), which is under-specification rather than conciseness. It lacks critical details, so the brevity is not effective. Every sentence should earn its place, but here the single sentence provides almost no value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (7 parameters, multiple types, no output schema, no annotations), the description is severely incomplete. It fails to explain the object types, the purpose of each parameter, or any behavioral nuances, leaving the agent to guess or rely solely on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters (name, type, scale, radius, location, rotation, use_in_front) but the description covers none of them (schema coverage 0%). The description adds no meaning beyond the schema's own titles and defaults, and does not compensate for the lack of parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Create') and specific resource ('a grease pencil object'), distinguishing it from sibling geometry creation tools like geometry-create_curve or geometry-create_text. However, it does not mention the variety of subtypes (e.g., STROKE, MONKEY, LINEART) that the 'type' parameter allows, which would make the tool's full scope clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There are no explicit when-to-use, when-not-to-use, or alternative tool references. The description simply states what the tool does without 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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the tool's name. It does not indicate whether the object must already exist, whether changes are destructive, what side effects occur, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it is under-specified rather than appropriately concise. It provides no useful information beyond the tool name, so the single sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter mutation tool with no annotations and no output schema, this description is completely inadequate. It fails to explain required parameters, behavior, return values, or any operational 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter-level detail. It does not explain what 'fields' means, which parameters are commonly used together, or how values like align_x or offset_x behave.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set text object fields' clearly identifies the verb (set) and resource (text object fields), distinguishing it from sibling tools like geometry-create_text and geometry-report. It could be more specific about which fields or that it modifies an existing object, but it is not misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as geometry-create_text or geometry-set_curve. There is no mention of prerequisites, exclusions, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose the destructive nature and system behavior (e.g., irreversible, affects data, may fail on linked objects). The description only says 'delete', which is redundant with the name and lacks detail on consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but severely under-specified; it does not earn its place by adding any value beyond the name. There is no structure or front-loading of essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with one required parameter and no annotations or output schema, the description is drastically incomplete. It fails to mention what happens to selected objects, whether undo is available, or any relationship with outliner or scene context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, and the description provides zero parameter details. The single 'objects' parameter expects comma-separated names, but the description does not clarify format, syntax, or how errors are handled, leaving the agent without critical input guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (objects), distinguishing it from close siblings like mesh-delete and object-duplicate. It covers the scope (one or more), 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 Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like mesh-delete or outliner-orphans_purge. It does not mention prerequisites, effect on linked data, or any caveats for collective deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists data points (Blender version, open .blend, queue depth, last-error ring buffer) but does not describe the output format, whether the tool modifies any state, or if it has side effects. Its behavior remains unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, consisting of a single sentence with a colon and a list. It is concise and to the point, though the structure is minimal and does not aid comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is severely incomplete. It does not explain the tool's purpose, when to use it, what it returns, or any behavioral details, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to explain them. However, it also does not add clarity about the tool's output, which is not directly parameter-related. This is a neutral score since parameters are absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description lists 'Bridge health: Blender version, open .blend, queue depth, last-error ring buffer' but does not explicitly state that the tool reports system health status or what action it performs. The tool name suggests a health report, but the description is ambiguous and lacks a clear verb or 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, under what conditions, or how it differs from other tools. No alternatives or usage scenarios are mentioned, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'Create a UV layer' without revealing how the do_init parameter affects the operation, which object is targeted, or any side effects. This is insufficient 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence, which is appropriately concise in structure. However, it sacrifices essential content for brevity, making it less useful than it could be. It's not bloated, but it's too sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's context in UV layer management, with parameters like object and do_init, the description is severely incomplete. It fails to mention that it can initialize from existing UVs, that it operates on a mesh object (default active), or any return or side-effect info. This is 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no parameter documentation. The schema only provides names, types, and defaults (e.g., name default 'UVMap', do_init default true), but the description fails to explain what these do or why they matter. The agent gets no help in understanding parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (create) and resource (UV layer), but it's extremely terse and doesn't provide any additional context that distinguishes it from siblings like uv-layer_set_active or uv-layer_delete. It's minimally adequate but not informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, scenarios, or exclusions, leaving the agent without a clear decision framework.
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 does not disclose any side effects, such as whether it creates a new data block, overwrites existing content, or requires specific permissions. With no annotations and no elaboration, behavioral transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is direct and to the point, achieving high conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is extremely minimal and does not explain the outcome, return behavior, or any nuances of opening a text file. Given the lack of annotations and output schema, this leaves the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not address the parameters 'path' and 'name' at all. Since the schema provides only their types and titles, and the description adds no explanation of their roles or relationships, the parameter semantics are poorly covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (open) and the resource (text file into a Text data-block), which distinguishes it from related operations like text-create or text-write. However, it doesn't explicitly contrast with alternatives like text-read, leaving some ambiguity about the exact use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other text-* siblings. The description gives no contextual cues about scenarios where opening a text file is preferred over reading, writing, or creating.
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, but it only states 'Create a curve primitive'. It doesn't mention side effects (e.g., adding an object to the scene), required permissions, or any constraints. This is insufficient for a tool that creates an object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It is front-loaded and to the point. However, it is overly brief, which might undercut its utility, but for what it says, it is appropriately sized in terms of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, no output schema, and 0% schema coverage, the description is severely incomplete. It fails to explain what curve types are available, how parameters affect the result, or what the created object looks like. A one-liner is far from sufficient for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about parameters like 'name', 'type', 'scale', 'radius', 'location', or 'rotation'. The description does not compensate for the lack of parameter documentation; the agent must rely solely on the schema, which lacks semantic detail beyond titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a curve primitive with a specific verb ('Create') and resource ('curve primitive'). It distinguishes from sibling tools like geometry-create_text or geometry-create_surface, though it doesn't explicitly differentiate from geometry-set_curve (which modifies existing curves). The purpose is clear but could be more specific about the primitive types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or exclusions. The description is a single sentence with 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?
The description does not disclose any side effects, such as whether the object is added to the active collection, if it requires an active scene, or if it returns a reference. No annotations are provided, so the full burden rests on the description, which is completely silent on these 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence with no redundant words. It is to the point and does not waste space, though it lacks structure (e.g., sections, examples). For a tool of this simplicity, the brevity is acceptable, but it could be slightly more structured with a brief note on typical usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no annotations, and no output schema, the description is drastically incomplete. It fails to provide any context about what a 'text object' is, how parameters interact, or what the tool is used for beyond the literal action. It would be impossible to use correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists 8 parameters with titles and defaults but no descriptions. The tool description does not explain what any parameter means (e.g., 'body' could be the text string, 'name' the object name). With zero elaboration, users cannot infer parameter purpose or constraints beyond the minimal titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a text object' is specific and clear, using a verb ('create') and a resource ('text object'). It distinguishes itself from sibling tools like geometry-create_curve or text-create by its focus on a text object, leaving no ambiguity about the intended action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no indication of when to use this tool versus alternatives. It does not mention whether it is for creating 3D text in a scene, how it differs from text-create, or any context where it would be preferred. The description provides zero guidance on usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It only states 'Fill selected edges', implying a geometry modification but not disclosing if it is destructive, how it handles edge selection, side effects, or any other behaviors. It adds minimal information beyond the tool's name and fails to inform about outcomes or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise and front-loaded. It conveys the core action efficiently without unnecessary words. However, it may be too terse, omitting necessary detail, but for conciseness alone it scores high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and no annotations or output schema, the description should provide more context about the operation, parameter effects, and expected results. It does not explain what happens when the tool runs, how selection is used, or what the outcome looks like. This incompleteness would leave an agent unable to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter ('beauty' or 'object'). The schema only provides titles but no descriptions, so the agent has no idea what 'beauty' controls or how 'object' defaults to active. The description fails to compensate for the lack of parameter documentation, leaving the parameters entirely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fill selected edges' clearly indicates the action ('fill') and the target resource ('selected edges'), providing a basic understanding of the tool's function. However, it does not distinguish itself from similar mesh editing tools like mesh-edge_face_add, which also operates on selected edges to create geometry. The purpose is clear but lacks specificity about the fill method or outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor does it mention prerequisites like having edges selected. There is no mention of context, typical scenarios, or exclusions. It simply states the action without any usage context, leaving the agent without decision-making guidance.
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 on its own, but it only states the action and target. It does not mention whether unset booleans are left unchanged, how the active object is considered, whether any side effects occur, or what happens if the named modifier does not exist, making the behavior opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words or redundancy, so it is concise. However, it is overly terse and does not use that compactness to deliver practical operational detail beyond a minimal action summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given seven parameters, no annotations, and no output schema, the description is far too sparse to fully support correct invocation. It lacks any statement on which flags are actually set, what 'common' excludes, whether optional booleans default to false, and what the function returns or affects, leaving a substantial informational gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain or augment any of the seven parameters. The phrase 'visibility flags' adds no meaning beyond the property titles already in the input schema, leaving parameter semantics entirely to the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action 'Set' and the resource 'common modifier stack visibility flags,' distinguishing it from the broader 'modifiers-set' and from outliner visibility tools. It is specific enough to know this concerns modifier visibility toggles, although it does not explicitly enumerate which flags or contrast the alternative modifiers-set tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternates such as modifiers-set or outliner-visibility_set. The sentence only paraphrases the tool's name, offering no exclusion criteria, context, or situational advice.
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 full burden for behavioral disclosure. 'Add a pose bone constraint' reveals only the basic action, not side effects, safety considerations, requirements, or impact on existing constraints. It provides no information beyond the purpose 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (five words), which might seem concise, but it is under-specified for a tool with seven parameters and three required fields. While there is no waste, it also provides no substantive detail—this is under-specification, not effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, 3 required), missing annotations, and no output schema, the one-line description is grossly incomplete. It doesn't cover return values, side effects, target/subtarget requirements, or any behavioral context, making it 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter explanation, but it mentions no parameters at all. The schema titles do provide some meaning (e.g., 'Optional constraint name'), but the description adds nothing to clarify the seven parameters or their relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('pose bone constraint'), which is specific and unambiguous for Blender context. It distinguishes itself from sibling tools like 'constraints-add' (likely object constraints) and 'rig-constraint_remove' by identifying the pose-bone scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'constraints-add' or 'rig-constraint_remove'. There is no mention of prerequisites (e.g., armature selection, pose mode) or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 doesn't disclose whether this operation requires an active context, whether it switches modes implicitly, whether it has side effects on the current tool state, or what happens if the idname doesn't exist. It only says what it does, not what happens or what constraints exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clear sentence — concise and front-loaded with the verb 'Switch'. However, it lacks any additional guidance or structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool switches active tooling via idname but the description doesn't cover parameter semantics, expected behavior, or usage context. No output schema, no annotations, and 0% param coverage — the description must compensate but doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% – none of the 3 parameters are documented in the schema descriptions (no descriptions at all). The description does not explain what 'idname' format is expected, what 'mode' values are valid, or what 'area' defaulting behavior might be. The description mentions only idname; the other params are undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Switch the active workspace tool by idname', providing a clear verb and resource. However, in the context of ~40 `tool-*`, `app-*`, and `context-*` sibling tools, the term 'workspace tool' is ambiguous — it could mean the tool system, tool selection, or Blender's workspace tools. Sibling names like `tool-active` and `context-mode_set` suggest overlapping functionality that isn't distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus the many other tool-related operations (tool-active, tool-settings, context-set_active). Setting an active workspace tool via idname could be confused with tool-setting_set or tool-active, but the description doesn't clarify the relationship or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 mentions 'undo-safe' and 'args validated against its schema,' which are useful, but it does not disclose potential destructive side effects, failure modes, or how the tool behaves when an operator cannot run. For an arbitrary operator-execution tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no filler. Every clause contributes something: the action, the validation behavior, and undo safety. While it is very short, this is still acceptable concision; the problems is the lack of substantive guidance rather than inefficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity, generic operator-invocation tool with 5 parameters, no annotations, and no output schema. The description gives only one line and does not explain return behavior, error handling, side effects, prerequisite context, or relationship to poll/undo. It is far from complete for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-specific meaning. It only says 'args validated against its schema,' which does not explain the format or semantics of idname, args, mode, object, or select. The input schema has some title-level examples, but the description itself fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Run any Blender operator with args validated against its schema.' This is a specific verb+resource description. However, it does not distinguish itself from sibling tools such as ui-operator_invoke or rna-call_operator, which also invoke Blender 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like ui-operator_invoke or rna-call_operator. 'Run any Blender operator' implies broad use, but there are no context cues, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are providedainer. The description only states the action with no mention of side effects, requirements, or behavior. It doesn't disclose that it likely adds a node to the active compositor tree, nor any error conditions or return values. With no annotations, the description should convey these but does not, so it's a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no redundancy, front-loaded with action. Very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutating operation on a compositor node tree, but the description doesn't mention prerequisites (active compositor?), side effects, or how it interacts with other compositor tools. It's too terse for a tool with a required parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has two parameters (name, type) with no description and 0% schema description coverage. The tool description does not mention them at all. It does not explain what 'type' expects or how 'name' is used. The description fails to add any meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Add a node' and the resource 'scene compositor node tree'. It is specific enough to distinguish from other add-node tools like shading-add_node, though it could mention it's for the compositor specifically (which it does). Minor lack of detail about what kind of node or where it goes, but still 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention preconditions (e.g., need an active compositor scene), or scenarios where this tool is appropriate. Sibling tools like shading-add_node or geometry_nodes-add_node are not mentioned. No exclusions or context 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 available, the description must disclose behavioral traits but does not. It only states 'Replace a curve's spline with bezier control points' without mentioning side effects, requirements (e.g., curve type), or any consequences for existing handles. The phrase 'the modeling curve' is unclear and adds no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence), but it is not well-structured; it ends with a fragment 'the modeling curve' and lacks coherent structure. It is concise but at the expense of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the operation (setting bezier splines with handles and closure), the absence of output schema, annotations, and detailed parameter descriptions makes this description severely incomplete. It does not explain input formats, handle types, or the effect of 'closed'. This is inadequate for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters, but it does not. It mentions 'bezier control points' which loosely maps to 'points' but provides no explanation for 'object', 'handles', or 'closed'. The description adds no meaningful semantic value beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Replace a curve's spline') on a specific resource ('curve's spline'), which distinguishes it from sibling tools like geometry-set_curve that likely handle other curve properties. While the phrase 'the modeling curve' is ambiguous, the overall purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, preferred contexts, or differences from similar tools like geometry-set_curve. Users must 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 present, so the description carries the full burden of behavioral disclosure. It only states that selected mesh elements are dissolved, without mentioning destructive side effects, how selection is interpreted, what limited mode does, or whether boundaries/vertices are affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, which is concise. However, it is under-specified for a tool with five parameters and multiple dissolve modes, so it is not appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% schema description coverage, the one-sentence description leaves the agent without information about mode semantics, defaults, object targeting, or side effects. This is inadequate for a 5-parameter mesh operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the five parameters (type, object, use_verts, angle_limit, use_dissolve_boundaries). The schema titles and defaults are self-descriptive, but the description adds no meaning to help an agent understand parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Dissolve' with the resource 'selected mesh elements,' clearly identifying a mesh editing operation. It does not explicitly distinguish it from sibling tools like mesh-delete or mesh-merge, but the operation name is specific enough to convey the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use dissolve versus alternatives such as mesh-delete, mesh-merge, or mesh-remove_doubles. There is also no mention of selection prerequisites or how the 'type' mode affects 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 must carry the full behavioral disclosure burden. It only says 'Create' and does not explain whether the object is added to the active scene, any side effects, permissions, or what the result/return value is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. However, it is under-specified for a tool with this many parameters and behavioral implications, so brevity sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity 18-parameter creation tool with no output schema and no annotations. The one-sentence description is far too minimal to help an agent understand type-specific parameters, defaults, placement behavior, or expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 18 parameters and 0% schema description coverage, the description provides no parameter semantics. It does not mention that `type` selects the primitive, nor explain primitive-specific parameters like radius, vertices, rotation, or location.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a common mesh primitive or empty.' It clearly conveys the core function. However, it does not distinguish this from other creation tools in the sibling list such as light-create, camera-create, or volume-create_empty.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like object-duplicate, mesh-fill, or geometry_create_curve. No preconditions, scene context, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'decimated' and 'duplicate' but doesn't explain side effects (e.g., whether the original is modified, if the decimate modifier is added non-destructively or applied immediately, or if the new object is automatically selected). Given 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficient and without fluff. It conveys the core action in few words. However, it's too sparse, bordering on under-specification, but since it is concise and to the point, a 4 is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, no output schema, no annotations), the description is incomplete. It fails to explain return values, behavioral nuances, or use cases. The schema provides some parameter details but lacks crucial context. For a tool that creates a new object with a decimate modifier, much more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in the schema beyond titles). The description does not explain the parameters at all. With 5 parameters, this is insufficient. The schema's titles (e.g., 'Decimate ratio for the LOD mesh') provide some clarity, but the description adds no value beyond the schema, and the parameters like 'apply' and 'level' lack context on defaults and implications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates a decimated LOD duplicate with a generic naming convention, which is a clear verb+resource. However, it doesn't distinguish from sibling tools like object-duplicate or object-collision_proxy_create, and doesn't clarify what 'LOD' implies beyond context. The reliance on the name 'object-lod_create' and a brief description is adequate but not highly informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives like object-duplicate or modifiers-add. No mention of prerequisites (e.g., object must be selected) or typical use cases. The description only states what it does, not when or why to choose 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 must convey behavioral traits. It only says 'set' without mentioning side effects, reversibility, or idempotency. The tool mutates state but gives no warning or confirmation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. However, it is overly minimal; it omits essential information, so while it's efficient, it's not effective. Structure is fine but content is sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema coverage, the description is far from complete. It doesn't explain return values, errors, or specific force field property examples. For a 3-parameter tool, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero descriptions, so the description must explain parameters. It only repeats parameter names ('object', 'property', 'value') and adds a vague 'RNA property identifier' for property. No detail on value format (JSON string) or how properties are referenced. Fails to compensate for schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the action (set) and the target (RNA property on object's force field). It distinguishes from siblings like physics-field_report (report) and physics-set (general set), though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or exclusions. The description provides no usage conditions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. 'List point cloud geometry attributes and color attributes' implies a read-only listing operation, but it does not specify output format, side effects, or limitations (e.g., whether it requires an active point cloud, performance implications). The description is too terse to convey behavioral expectations beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the action (list) and the targets (geometry attributes and color attributes). It is front-loaded and contains no filler. However, it lacks a brief note on usage context, but given the single-sentence constraint, it's reasonably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no annotations, the description is minimal. It doesn't explain what 'attributes' includes (e.g., position, normals, UVs, vertex colors?), nor does it mention any prerequisites like requiring a selected point cloud. Given siblings like pointcloud-report (which might give a broader view) and pointcloud-set, the description is incomplete for an agent to decide when to use this vs alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'name_or_object' described as 'Point cloud object or data-block name'. Schema description coverage is 0%, meaning the schema property lacks a description. The tool description does not explain what values are acceptable, how the parameter should be formatted, or whether it accepts a name or an object reference. The description adds minimal semantic value beyond the schema's 'title' field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists point cloud geometry and color attributes, which identifies the resource (point cloud) and verb (list). However, it doesn't distinguish from sibling tools like pointcloud-report or pointcloud-set, and 'attributes' is somewhat ambiguous (could include position, normals, UVs, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like pointcloud-report or pointcloud-set. The description does not mention typical use cases, prerequisites, or scenarios where this tool is preferred. Sibling tools covering similar ground (pointcloud-report, pointcloud-set) make the lack of differentiation a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure, but it discloses nothing beyond the bare act of creation. It does not state whether the operation is additive, whether it overwrites existing speakers, or what side effects (e.g., adding to the active scene) occur. While it is not misleading, it fails to inform the agent about return values, permissions, or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single short sentence with no wasted words, which technically satisfies conciseness. However, the excessive brevity borders on under-specification, as it adds no more information than the tool name. It is structured clearly but sacrifices substance for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a creation tool with two optional parameters and no output schema, the description is inadequate. It does not explain what a 'speaker' represents in the domain, what happens upon success, or how 'name' and 'location' affect the result. Sibling tools like 'speaker-report' and 'speaker-set' suggest a CRUD context, but this tool's description fails to fit into that narrative, leaving the agent without enough information to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines two parameters ('name' and 'location') with defaults, but the description provides zero explanation of their purpose, format, or relationship to the 'speaker object'. Since schema description coverage is 0%, the description was expected to compensate, but it does not mention either parameter at all. This leaves agents with no additional semantic understanding beyond the parameter names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a speaker object' clearly specifies the action (create) and the resource (speaker object), which distinguishes it from sibling tools like 'speaker-list' and 'speaker-report'. While it is minimal, it unambiguously identifies the tool's function. However, it does not elaborate on what a 'speaker' is, relying on the tool name for context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'speaker-set' or 'object-create'. There is no mention of use cases, prerequisites, or conditions under which this tool is preferred. The lack of any contextual or contrasting information means the agent gets no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only notes that the property is 'writable', implying mutation, but it does not explain what happens if the property is read-only, whether the speaker must exist, or any potential side effects. There is also no mention of error handling 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. However, it is under-specified for a mutating tool with three parameters and no annotations, so while it is compact, it lacks necessary detail. The conciseness itself is appropriate, but it does not earn its place fully because it omits critical information that could be added without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% parameter coverage, the description is severely incomplete. It provides minimal context about the tool's scope, behavior, or parameter semantics, leaving the agent to rely solely on the schema. For a mutation tool, this is highly inadequate, as the agent needs to know prerequisites, side effects, and parameter constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three parameters (name, property, value), and schema description coverage is 0%. The description does not elaborate on any of these parameters, merely repeating the words 'property' and 'value' without adding meaning. The schema titles provide some basic context, but the description adds no value beyond what the schema already conveys, and it fails to compensate for the 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the resource (a speaker data-block), and it is specific about setting a single writable RNA property. It distinguishes from sibling tools like speaker-create, speaker-list, and speaker-report, which handle creation, listing, and reporting rather than property modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives. There is no mention of prerequisites (e.g., speaker must exist), no indication that this is for modifying existing speakers as opposed to creating them, and no reference to other tools like speaker-report for querying properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only says 'Report', implying a read-only operation, but does not clarify what state is shown, whether any changes occur, what the output format is, or how component filtering affects results. This is a significant gap for a report 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is under-specified rather than appropriately concise. Important semantic details about the tool's output and parameter behavior are omitted, making the brevity a liability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and unhelpful parameter coverage, the description is incomplete for a moderately configurable report tool. It does not describe the return value, the effect of component choices, or how the report relates to the spreadsheet editor state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the object and component parameters. It fails to do so; neither parameter is mentioned. The phrase 'object table shape' does not help the agent understand how 'object' or 'component' control the report.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Report') and target ('spreadsheet editor state and object table shape'), which broadly distinguishes it from sibling spreadsheet tools. However, 'object table shape' is ambiguous and could mean the geometry component, column structure, or data layout, so it does not fully communicate the tool's 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like spreadsheet-columns or spreadsheet-rows. The description mentions no exclusions, prerequisites, or typical scenarios, leaving the agent to infer when this report 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?
There are no annotations and no disclosure of side effects, permissions, or non-destructive nature. The description does not reveal any behavioral traits 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no unnecessary words. It is well-structured and directly states the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a complete understanding. It omits return values, expected input format, and assumes knowledge of what a 'Text data-block' is. With no output schema, the tool's behavior remains ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'name' has a schema title 'Text data-block name' which provides some meaning, but the description does not explain it. The semantic coverage is minimal, relying solely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool reads a Text data-block, which is clear and distinct from sibling tools like text-create or text-write. However, it does not specify what 'read' entails (e.g., returns content, metadata), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, use cases, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description must carry the full burden of behavioral disclosure. The description is extremely sparse and does not state whether the removal is permanent, whether it affects linked data, or what happens if the named data-block does not exist. For a destructive operation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words studly. It is front-loaded and easy to parse. However, it is extremely brief and could include more useful detail without becoming verbose, so it does not get a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a single-parameter removal operation with no annotations and no output schema, so its simplicity could justify a higher score, but the description does not cover important operational details like error handling or reversibility. Given the tool's simplicity Credit, a minimum viable description would include more behavioral context, making this incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter, 'name' (a string), with 0% schema description coverage Gradient. The description adds no information about the 'name' parameter beyond what the schema shows, failing to compensate for the lack of schema documentation. Since the parameter is simple, a higher score is possible, but the description provides no semantic context, so it earns a low score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a Text data-block' indicates the action (remove) and the resource (Text data-block), which is a specific verb+resource. However, it does not differentiate from other removal tools like particles-remove or modifiers-remove, though the subject is unique. It is clear but lacks detail on scope, so it is adequate but not exceptional.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., the text data-block must exist), no mention of undoability, and no naming of alternative tools for similar operations. The context of this tool within the text-* family is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'live ToolSettings RNA properties' but doesn't explain what 'live' means, whether it's read-only, or what the output format is. The description is too terse to convey behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded. It states the core purpose without waste, but it's so brief that it sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and no annotations, the description is incomplete. It doesn't explain the return value, the meaning of 'live', or how the parameters affect the report. The agent would need to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't explain the 'mode' and 'area_type' parameters at all, leaving the agent without guidance on how to use them. The schema titles provide some hints (e.g., 'Optional mode, e.g. OBJECT or EDIT_MESH') but the description adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Report active tool and live ToolSettings RNA properties' clearly states the tool reports active tool and live ToolSettings RNA properties, which is a specific verb+resource. However, it doesn't distinguish from sibling tools like 'tool-active', 'tool-set', 'tool-setting_get', 'tool-setting_set', which are closely related and could be confused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'tool-active' or 'tool-setting_get'. It doesn't mention any context or exclusions, leaving the agent to guess which tool is appropriate for reporting tool settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only says 'Request', implying a non-destructive operation, but fails to mention that it might be a no-op if the timer isn't available, any side effects, or whether it returns anything. This is insufficient for an action 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is structurally fine, but it is under-specified. It lacks any structure that would help an agent parse conditions or usage, so while efficient, it does not pack enough information into its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two optional parameters, but the description fails to provide essential context such as effect, return value, or failure modes. The absence of an output schema means the description should at least hint at no return or success/failure signaling, which it doesn't. Overall, it is barely adequate 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description entirely ignores the parameters 'type' and 'iterations'. There is no explanation of what redraw timer types mean or how iteration count affects behavior, leaving the agent to guess solely from defaults and names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it requests a Blender UI redraw, with a specific condition (when wm.redraw_timer is available). This is a specific verb+resource, and there are no sibling tools with a similar intent, so it stands out. However, it could be more precise about what a 'redraw' accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The mention of 'when wm.redraw_timer is available' is a technical prerequisite, not a usage context. There is no discussion of scenarios like forcing a refresh or after model changes, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description must convey side effects explicitly. The word 'report' implies read-only, but it doesn't explicitly state that no modifications are made. It also doesn't describe error conditions or data limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words, making it highly concise and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks explanation of the report format or content details. Without an output schema, the user is left uncertain about what the report will return, and there's no information about potential edge cases or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes a single parameter 'object' with a title indicating it defaults to the active object, but no detailed description of the expected value or format. The description adds no additional semantic information about the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as providing a detailed report on f-curves and keyframes for an object. It uses a specific verb ('report') and resource (f-curves/keyframes). However, it doesn't distinguish from other similar report tools like anim-report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other animation-related tools. It doesn't mention any prerequisites, use cases, or criteria 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 carries the full burden of behavioral disclosure, but it only states the action without revealing side effects, prerequisites, or response behavior. For a mutating tool, there is no mention of what happens to existing constraints or how conflicts are resolved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one short sentence, but it is under-specified for a tool with five parameters. While no words are wasted, the brevity comes at the expense of necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is insufficient. It does not mention the owner/bone relationship, constraint type usage, or any validation rules, leaving the agent to rely solely on parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any parameters. The schema titles provide some inherent meaning, but the description adds no value beyond stating the action itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('add') and a clear resource ('object or pose-bone constraint'), making the core function understandable. It distinguishes from modifiers-add but doesn't fully differentiate from constraints-set, which might also be used for constraint management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like constraints-set or rig-constraint_add. The description simply states what it does without any contextual or comparative information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It hints at checking 'current or proposed context' but does not specify whether the operation is read-only, what it returns (e.g., boolean), or any side effects. No mention of error handling or return value semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the core purpose without fluff. It is appropriately sized for a simple check operation, though it could benefit from slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (4 parameters, no output schema), but the description is too sparse to be complete. It does not explain what 'poll' means in Blender, what constitutes a 'context', or what the tool will return. Without annotations, this lacks substantial context 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% because the description mentions none of the parameters. The schema itself provides titles for each parameter (e.g., 'Operator id, e.g. mesh.subdivide'), but the description adds no further meaning. Since the description must compensate for low coverage and does not, the score is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking whether a Blender operator polls in a context. It uses a specific verb and resource, which distinguishes it from tools like `ui-operator_invoke` (which invokes rather than checks). However, it does not explicitly differentiate from the sibling `ui-operator_poll`, which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like `ui-operator_poll` or `ui-operator_invoke`. The description gives no context for when polling should be checked, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal and does not disclose whether any scene changes occur, whether the render is displayed or saved, how analytics are returned, or what inputs are required to succeed. No annotations exist to fill in the behavioral safety profile, so the description carries the full burden but only says 'render and return analytics.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, front-loaded, and contains no redundant fluff. However, it is slightly underspecified, and terms like 'eye' make it less precise; it earns high marks for brevity but not maximum for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and only a single sentence, the description leaves out critical context such as what analytics are produced, how to select an object, what views are relevant, and whether the tool modifies the scene. It is inadequate for an agent to anticipate results or failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description adds no meaning for res, view, object, or texture_size. It does not explain how these parameters affect rendering or analytics, so the agent must rely on parameter titles alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb + resource: render a UV checker pattern and return structured UV analytics. It is reasonably specific, but there is some ambiguity in 'UV checker eye' and it does not differentiate itself from sibling feedback-* or uv-* tools such as uv-report or feedback-capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no indication of when to use this tool instead of uv-report, uv-export_layout, or feedback-capture, and no exclusions, prerequisites, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'create a link', without explaining whether existing links are overwritten, what happens if sockets are incompatible, or the required state of the nodes (e.g., must already exist in the modifier). It also doesn't mention any validation or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient. However, it is skimming on necessary details; while concise, it omits crucial context that could be included without bloating (e.g., socket type compatibility, behavior on existing links). It is not tautological but is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 required params, no annotations, no output schema), the description is incomplete. It doesn't mention the need for nodes to exist, how sockets are referenced (name vs index), or what happens if the link fails. The schema is sparse, so the description has a heavy burden that it fails to meet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 6 parameters, the description adds no meaning beyond the schema titles. It doesn't clarify that 'from_socket' and 'to_socket' accept names or indices, or that 'modifier' is optional and defaults to the first geometry nodes modifier. The schema titles provide some context, but the description does not compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a link between two Geometry Nodes sockets, using a specific verb and resource. It distinguishes from siblings like shading-link_nodes and compositor-link by referencing Geometry Nodes, though it doesn't explicitly differentiate from other geometry_nodes-* 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as shading-link_nodes for shader nodes or compositor-link for compositor nodes. It also doesn't mention prerequisites like the existence of a Geometry Nodes modifier or the objects owning 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 should disclose behavioral side effects and environment assumptions. It only declares the creation action, without mentioning whether the light is added to the current scene, what defaults are used, whether it returns a reference, or how it interacts with the scene. This is insufficient transparency for a create 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and lacks filler, but it is under-specified rather than appropriately compressed. For a tool with 9 configurable parameters, a single generic sentence is efficient but not structured enough to be genuinely useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given nine parameters, no output schema, and multiple sibling light/creation tools, the description is incomplete. It does not state where the object is created, which light types exist, how to choose a type, or what happens after creation. It places most burden on the schema and sibling names, but the description itself is too weak.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema-description coverage is 0%, but the description provides no parameter insight whatsoever. The schema titles and defaults are helpful, but the description doesn't explain relationships like spot_size/spot_blend applying to spot lights, or which parameters matter for different light types. With 9 parameters and no description-level semantics, the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Create') and the resource ('a light object'). It is easily distinguishable from sibling light-related tools like light-set, light-list, and light-report. However, it is very terse and does not provide detail about what 'create' entangles in the current scene, so it does not fully differentiate from similar create-entity tools like camera-create or speaker-create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool, what prerequisites exist, or how it relates to alternatives like light-set, light-list, or object-create. The description only says 'Create a light object', which provides implied usage but no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the creation action but does not detail side effects, required permissions, or whether existing light probes are affected. There is no mention of return values or error conditions, leaving the agent under-informed 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is underspecified given the three parameters. It is appropriately front-loaded but lacks essential details, making it feel more like an under-specification than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description is severely incomplete. It offers no information about the parameters, types, location default, or any context about how this fits with sibling lightprobe tools. A create operation with multiple options should provide at least a summary of what the parameters control.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the description does not mention any of the three parameters (name, type, location). While the schema titles and enum give some context (e.g., type choices), the description adds no additional meaning, forcing the agent to infer parameter usage solely from raw schema. This fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a light probe object' clearly states the verb ('Create') and the resource ('light probe object'), distinguishing it from sibling tools like lightprobe-list, lightprobe-report, and lightprobe-set. It precisely identifies the action and target, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. While the name implies creation, the description does not mention any prerequisites or contexts (e.g., requiring an active scene) nor does it reference other lightprobe tools as alternatives. Usage is only implied by the verb 'Create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 simply says 'Set an object's origin' without mentioning side effects (e.g., moving the object's geometry, affecting transforms) or any irreversible changes. This is a significant gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler words. It is front-loaded and the only sentence earns its place, effectively stating the core operation without tangents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 3 parameters, two enums, no output schema, and no annotations, indicating moderate complexity. The description is too sparse: it fails to explain the modes of origin setting, the center options, or the consequences of the operation, making it 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It does not mention any parameters, the 'type' enum options, the 'center' mode, or the required 'object' name. The description adds no value to understanding what these parameters do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and target ('an object's origin'), which is a specific, meaningful operation. It distinguishes from sibling object tools by focusing on 'origin', a concept not present in other sibling names, though it doesn't explicitly contrast with related tools like object-transform_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description merely states the action without indicating prerequisites, context, or exclusions. With many object-related siblings, some context about when changing an origin is appropriate would be expected.
Agents often have multiple tools that could apply. Explicit usage guidance like "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, but 'Rename a collection' reveals nothing about side effects (e.g., whether the rename propagates to scene references), name constraints, error behavior, or reversibility. For a mutating tool, this is a significant disclosure 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
At three words, the description is maximally concise and front-loaded with zero filler. However, this brevity borders on under-specification rather than efficient compression, since it adds almost no information beyond the tool name itself and the context signals show substantial gaps elsewhere that the description could have filled.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations, no output schema, and 0% parameter description coverage, a single sentence is insufficient. The description does not explain what a 'collection' is in this domain, what identifier format is expected, or what happens to dependent data — context that sibling tool definitions or richer descriptions typically provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation, but it adds no meaning to either 'name' or 'collection'. Both parameters rely entirely on their schema titles, and the description offers no details about name format constraints, uniqueness requirements, or how collection identifiers are resolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('rename') and identifies the resource ('a collection'), making the core intent immediately clear. However, it essentially restates the tool name in natural language and offers no differentiation from sibling tools like outliner-collection_create, outliner-collection_delete, or object-rename.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or context is given, and the description does not reference sibling tools such as outliner-collection_create/delete or outliner-object_move that might be relevant alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only repeats the action of creating. It does not mention side effects, naming constraints, duplicate handling, whether the new layer becomes active, or what happens if creation fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded with no filler. However, it is under-specified rather than efficiently concise, providing only a literal restatement of the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema, but the description still omits important contextual details about view layers in Blender, such as whether the layer is added to the current scene, whether it must be unique, and how it interacts with outliner visibility tools. The current description is minimally adequate but leaves meaningful gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning to the single 'name' parameter beyond the schema's title 'New view layer name.' The description fails to compensate for missing parameter details such as naming rules, uniqueness, or character restrictions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: 'Create a view layer.' This clearly identifies the operation and differentiates from sibling tools like outliner-view_layer_delete and outliner-collection_create through the 'view layer' resource. However, it does not elaborate on what a view layer is or how it relates to the outliner context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, such as an existing scene or collection, nor any comparison with related tools like outliner-view_layers or outliner-view_layer_delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits beyond the action itself, such as what happens if the constraint does not exist, whether it requires the armature to be in pose mode, or any side effects like undo behavior. The description is very minimal and lacks transparency about potential errors or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise and to the point. It conveys the essential action without any fluff. For a simple tool with 3 parameters, this level of brevity is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations, no output schema, and 0% parameter description coverage, the description is insufficient. A removal operation on a bone constraint should include context like prerequisites (armature must be pose mode), what constitutes a valid constraint name, and what happens on success/failure. The description is too sparse to be considered complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters beyond their titles. The schema provides titles like 'Pose bone to edit' and 'Constraint name to remove', but the description adds no additional meaning about the types, formats, or relationships between parameters. For a 3-parameter tool with 0% coverage, the description does not compensate, leaving the agent to infer that 'name' is the constraint name and 'bone' is the pose bone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a named pose bone constraint' clearly states the action (remove) and the resource (named pose bone constraint), which is adequate. However, it does not differentiate from sibling tool 'constraints-remove' which likely does a similar operation on constraints, but for objects modifiers. The description is clear enough but lacks explicit statement of scope (e.g., on armature's pose bone).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'rig-constraints', 'rig-constraint_add', or 'constraints-remove'. The description only states what it does, not when it is appropriate or when to use a different tool. For example, it does not mention that this is for pose bone constraints while 'constraints-remove' may be for object constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 transparency. It only says 'Add', implying creation, but it does not disclose what happens if the strip already exists, whether it modifies existing strips, or any side effects. The description provides minimal insight 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded and efficient. There is no wasted wording or unnecessary detail. However, its brevity borders on under-specification, but for conciseness alone it scores well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description is notably incomplete. It does not explain how the parameters (e.g., type, path, channel) affect the created strip, nor does it clarify any constraints. The description leaves the agent guessing about input requirements and expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines 5 parameters (name, path, type, channel, frame_start), but the description provides zero information about them. Schema description coverage is 0%, so the description fails to add any meaning beyond the schema. The agent receives no hints about parameter relationships, defaults, or required formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a sequence strip' uses a specific verb (Add) and resource (sequence strip), clearly distinguishing this from sibling operations like sequencer-strip_remove and sequencer-strip_set. However, it does not elaborate on what constitutes a sequence strip or the types of strips it can add, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any prerequisites, restrictions, or context in which the tool is appropriate or unsuitable. The description simply states the action without directing the agent on selection among the many sequencer-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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it creates a Text data-block, but it does not mention side effects, return values, error cases, or any implications of the operation. This is minimal transparency 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it extremely concise and front-loaded. It is easy to read and parse, but its brevity comes at the cost of missing important details, which is a trade-off. For a simple tool, this is appropriately sized, though not overly rich.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters, no output schema, and no annotations, the description should provide more context about what a 'Text data-block' is, how the 'body' parameter is used, and what the result of creation looks like. The current description is too incomplete to fully guide an agent, especially with sibling tools like text-open and text-save nearby.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning the description must compensate for parameter semantics, but it does not. The schema lists 'name' and 'body' with titles, but the description gives no additional meaning, such as how the parameters relate to the data-block or any constraints or formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a Text data-block' clearly states the verb (create) and the resource (Text data-block), which is specific enough to convey the tool's primary function. It is distinct from sibling tools like text-open, text-read, and text-write, but it does not explicitly call out those distinctions, so it doesn't reach 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The sibling list is extensive, but the description doesn't help the agent decide between text-create and text-write or geometry-create_text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it only states 'Report one image datablock'. It does not clarify whether the operation is read-only, what side effects might occur, what data is returned, or how errors are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundant content. It is front-loaded but overly terse, sacrificing clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a single undocumented parameter, this description is insufficient. It states the object of operation but does not explain what a 'report' entails, leaving the agent uncertain about expected output and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, leaving the description to compensate. It adds no information about the 'name' parameter beyond the schema's property title, failing to explain how the name is used or what constitutes a valid value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and clear resource ('one image datablock'), which distinguishes it from siblings like textures-list (multiple datablocks) and textures-load (loading instead of reporting). It is concise but lacks detail on what the report contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description neither states a context nor excludes other tools; usage is only implied by the tool name and sibling structure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing side effects, validation behavior, error handling, or persistence. As a mutation tool, it should indicate what happens on invalid paths or malformed JSON, but it does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste, but it is too terse to be fully effective. It conveys the action but omits essential context, so it is not the ideal minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's two required parameters and lack of output schema or annotations, the description is incomplete. It does not mention valid path patterns, how the JSON value is applied, prerequisites, or what the tool returns, making it insufficient for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no explanation of the parameters beyond what the input schema titles already provide. Since schema description coverage is 0%, the description fails to compensate and does not clarify path syntax or JSON value format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set one ToolSettings path' clearly indicates a set operation on a specific resource, distinguishing it from sibling tool-setting_get (retrieval) and tool-settings (listing). However, it does not elaborate on what a 'ToolSettings path' is, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention that tool-setting_get should be used for reading or that tool-settings lists available paths, so the usage context is entirely unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 correctly indicates the tool mutates seam flags, but it does not mention side effects, default object behavior, selection requirements, or whether existing seams are preserved or replaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler. It is front-loaded and efficiently communicates the core operation, though it is too terse to provide richer context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotations, no output schema, and 0% parameter coverage, the one-line description leaves the agent without enough context to confidently invoke the tool. It omits usage context, parameter semantics, and behavioral caveats, making it minimally adequate at best.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation of the `edges`, `action`, or `object` parameters. The parameter titles and enum in the schema are the only source of semantic information, so the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (seam edge flags) and lists the four supported mutation operations (set, add, remove, clear), making the tool's function clear. It is not explicitly differentiated from siblings like uv-seams, but the uv- prefix and mutation verbs provide enough context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as uv-seams or uv-report. It does not mention prerequisites like edit mode, existing seam state, or when SET vs ADD/REMOVE 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. It discloses that it operates on selected faces and existing seams, but does not mention side effects (e.g., changes to UV layout, potential distortion with CONFORMAL method) or prerequisites (e.g., faces must be selected, seams must be marked). This is a significant gap for a tool that modifies UV data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence), which is concise, but it is too terse to convey essential information. It front-loads the core action but omits necessary detail, so it does not earn its place as a standalone guide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters including an enum, no output schema, no annotations), the description is incomplete. It does not explain how parameters affect the operation, what the expected output is (UV coordinates), or any limitations (e.g., requires selection, requires seams). For a UV editing tool, the description leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with 0% description coverage, so the description must compensate. It only mentions 'existing seams' but does not explain the meaning of 'method' (ANGLE_BASED vs CONFORMAL) or 'island_margin' (spacing in UV space), leaving the agent to guess. The enum values are not documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Unwrap the selected faces along existing seams' with a specific verb and resource, but it does not explicitly differentiate from sibling tools like uv-smart_unwrap or uv-cube_project. It implies a standard UV unwrapping operation on existing seams, which is distinct enough for an expert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives like uv-smart_unwrap or uv-cube_project. The description implies it is for manually seamed meshes, but there is no mention of when not to use it or alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action 'enable' but doesn't disclose side effects, such as whether enabling requires a restart, changes to the UI, or potential errors if the module is already enabled. The description is too terse to convey behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded with the action. However, it is under-specified, but for conciseness, it earns a 4 because it is not verbose and gets to the point quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimal but lacks essential context. It doesn't mention how to obtain the module id, what happens if the module is not installed, or any related tools like app-addons for listing add-ons. The description is incomplete for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the 'module' parameter. The schema only provides the title 'Add-on module id', but the description doesn't clarify what constitutes a valid module id, how to find it, or any format expectations. The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (enable) and the resource (installed Blender add-on module). It distinguishes from the sibling tool app-addon_disable, which performs the opposite action. However, it doesn't explicitly mention the context of add-on management beyond the name, but the verb+resource is specific 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like the add-on being installed or disabled, nor does it reference the sibling app-addon_disable for disabling. The description is minimal and 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.
- 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 'Set', implying a mutation, but does not mention side effects, permissions, reversibility, or response format. This is a minimal surface-level statement that does not enrich the agent's understanding of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundancy. It is front-loaded and easy to parse. However, it is so brief that it borders on under-specification, but it earns a 4 for being concise without being bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters and no output schema or annotations, a one-line description is inadequate. It doesn't explain what 'common' means, which properties are relevant, or any constraints. The schema compensates somewhat, but the description fails to provide sufficient operational context for an agent to safely select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides rich titles and enums for each parameter, but the description adds no additional meaning or context for any of the six parameters. Schema description coverage is 0%, so the description fails to compensate for the schema's low-level definitions. It does not clarify how parameters interact, defaults, or typical usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set common camera data properties' clearly identifies the verb (Set) and resource (camera data properties). It distinguishes from siblings like camera-create (create a new camera) and camera-set_active (set active camera). However, the word 'common' is vague and doesn't specify which properties are included, which could lead to ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or how it differs from other camera-related tools. The description merely states the action without contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
This is a mutation tool (it links sockets, likely creating a connection between nodes) with NO annotations provided, so the description carries full burden for behavioral disclosure. The description is extremely terse ('Link two compositor node sockets') and does not disclose any behavioral details such as: whether existing links are replaced, what happens if the link fails, whether the operation is idempotent, or any side effects. For a mutation 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: 'Link two compositor node sockets' in 5 words. It is not verbose nor redundant. However, it is extremely terse, bordering on under-specification. For a tool with 4 parameters and no other information, this brevity comes at the cost of clarity; but as a standalone description it is clear for a simple linking operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 required parameters, no enums, no output schema, and no annotations. The description must carry the full burden to explain what the operation does and any nuances of linking sockets in a compositor. Given the complexity of a node-link operation (potential for invalid connections, type mismatches, etc.), the description is too thin. It does not mention the compositor context, how to specify sockets (name or index), or any error behavior. For an experienced Blender user, this may be sufficient, but the machine-readable description should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. The description says nothing about the parameters beyond the schema's titles which already exist in the schema (e.g., 'Destination node name', 'Source output socket name or index'). The parameter names (from_node, from_socket, to_node, to_socket) are fairly self-explanatory, but the description adds no extra meaning about how to construct these values (e.g., how to specify name vs index, what syntax is expected).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Link two compositor node sockets'), specifying the verb 'Link' and the resource 'compositor node sockets'. This is specific enough to distinguish from sibling tools like 'shading-link_nodes' (which links shader nodes) and 'compositor-add_node' (which adds nodes), so it differentiates between similar link operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool name and description clearly state the action ('Link two compositor node sockets') and the parameter names fully align with the schema. There is no sibling differentiation because the other link tool (shading-link_nodes) exists for a different node type, so the purpose is inherently distinct. However, there are no explicit usage guidelines about when to use this tool versus alternatives, nor any context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden of behavioral disclosure. It only states a read-like action ('List') but does not mention return format, safety characteristics, or any side effects. This is insufficient given the absence of structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose with no filler. It is well-structured and front-loaded, though it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the presence of multiple sibling constraint tools, the description is too sparse. It does not explain what the tool returns, how owner works, or how it relates to other constraint tools, leaving significant gaps for an agent to reason about.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description should compensate by explaining parameters. It does not mention any of the three parameters (object, bone, owner). While the schema titles are somewhat descriptive, the description adds no semantic value, leaving the agent to rely solely on potentially cryptic field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('object or pose-bone constraints'), making the purpose unambiguous. It does not explicitly differentiate from sibling tools like constraints-report or rig-constraints, but the verb 'List' implies a simple enumeration, which distinguishes it from add/remove/set operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as constraints-report or rig-constraints. The description gives no context for choosing this over other constraint-related tools, leaving the agent without directional advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden, but it only states the action without disclosing side effects, whether it requires edit mode, whether it affects only the active mesh, or any persistence or UI-state changes. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler. It is appropriately front-loaded and wastes no words, though the brevity sacrifices depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is too sparse. It fails to mention when it applies (edit mode), which objects it affects, or the significance of the combined enum modes, leaving the agent without key operating context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it adds nothing beyond the schema. The enum values (VERT, EDGE, FACE, etc.) are self-explanatory, yet the description neither explains their meaning nor how the mode parameter behaves in combination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set mesh edit selection mode' clearly states the tool's function: it changes the selection mode for mesh editing. It uses a specific verb+resource and is distinguishable from general mode-setting siblings like context-mode_set, though it could be more explicit about the object scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites such as being in edit mode or having a mesh selected, nor any comparison with related tools like context-mode_set or mesh-select_all.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 explains what is recorded (silhouettes, bbox, checkpoint) but does not mention side effects, persistence, whether it overwrites data, or any safety implications. The term 'record' is ambiguous—does it save to disk, memory, or just report? This lack of clarity on effects is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, tightly packed with technical specifics. It front-loads the purpose and avoids redundancy. Every phrase earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter, no annotations, and no output schema, the description is insufficient. It does not explain when to use this tool, what happens when invoked, how the checkpoint is used, or how it relates to the broader feedback tool family. The description leaves the agent guessing about workflow integration and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the single parameter 'object' at all. The schema provides only a title ('Mesh object to baseline (defaults to active)') and zero description coverage. The tool description adds no meaning beyond the schema field title, leaving the agent without any guidance on how to set the parameter or its role in the baseline capture.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it records a baseline of silhouettes, bounding box, and a session checkpoint, using specific technical terms. This distinguishes it somewhat from generic capture tools, but it does not explicitly contrast with siblings like 'feedback-capture' or 'feedback-silhouette', so 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for establishing a 'do-no-harm baseline' before modifications, but provides no explicit when-to-use guidance or alternatives. It lacks direction on when to choose this over other feedback-capture variants, and there is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of behavioral disclosure, and it reveals almost nothing: no mention of whether rendered images are saved to files, sent to a feedback report, displayed in the viewport, or whether the operation blocks or requires render engine setup. The term 'anti-blob' adds jargon without explanation, further reducing transparency for an agent deciding whether invocation is safe and contextually appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of ten words — no wasted prose. However, the parenthetical '(the anti-blob)' is cryptic jargon that does not earn its place without explanation, so it loses a point despite the overall economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, zero annotations, no output schema, and 12+ feedback-* siblings, the one-line description is insufficient: it does not clarify what 'several images' are used for, how this differs from feedback-turntable or feedback-capture, or what happens after rendering. An agent would have to infer the entire usage model from the tool name and the schema's enum titles.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description contributes zero parameter meaning: it does not mention res, object, preset, or shading. The schema's own titles do useful work (e.g., preset's title decodes ortho4/ortho6/orbit4; shading's title maps enum values to Workbench/EEVEE), but the rubric requires the description to compensate for low coverage and it fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Render a multi-angle preset... as several images.' The parenthetical '(the anti-blob)' provides a niche signal that hints at this tool's differentiating role among the many feedback-* siblings, though the term is unexplained. It is clear enough to identify the action, but the differentiation from feedback-capture, feedback-turntable, and feedback-silhouette is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives. It does not say 'use this when you need multiple orthogonal views' or name competing tools like feedback-capture, feedback-turntable, or feedback-silhouette. The only contextual clue is the cryptic '(the anti-blob)' which does not constitute actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavior disclosure. It only states what the tool does ('render') and what it returns ('quality analytics'), but does not disclose whether it modifies the scene, how long the render might take, whether it requires a specific context (e.g., an active object), or what 'quality analytics' includes. This is minimal and leaves significant unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and outcome. There is no fluff, repetition, or unnecessary detail. It adheres to minimalism while staying on topic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (rendering a turntable, returning analytics) with three parameters, no output schema, and no annotations. The description does not explain what 'quality analytics' entails, what the output looks like, how parameters affect the process, or any setup requirements. It lacks essential context for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must explain the parameters (res, count, object) to compensate. The description mentions none of them. It only talks about 'material-shaded lookdev turntable' and 'quality analytics', giving no clue about resolution, frame count, or object selection. This is a critical failure for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Render a material-shaded lookdev turntable and return quality analytics.' It specifies the action (render) and the subject (lookdev turntable) and mentions the additional deliverable (quality analytics). It distinguishes from similar siblings like feedback-turntable or feedback-quality by adding 'material-shaded' and 'lookdev', though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or when not to use it. The sibling list includes several feedback-* tools (e.g., feedback-turntable, feedback-quality), but the description gives no context on how this one differs or when it is preferred. This leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only adds 'read-only' and a list of metric areas. It does not disclose behavior around validation gates, export profile checks, budgets, LOD rules, or what the tool returns. This is minimal transparency for a complex analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a clear metric list and a read-only qualifier. Every word earns its place, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high complexity (18 parameters, no output schema, no annotations), the description provides only a high-level overview. It omits how the many validation parameters are used, what the output format will be, and how this relates to sibling tools like feedback-readiness or io-profile_validate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 18 parameters, and the description does not compensate by explaining any of them. It only names high-level metric categories; the 18 parameters dealing with budgets, LOD ratios, export profiles, collision requirements, and validation gates are entirely unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides objective quality metrics for a mesh, listing specific metric categories (topology, UVs, orientation, symmetry, proportion, scale, readiness). It is more specific than the tool name and broadly distinguishes from visual feedback siblings like feedback-capture or feedback-lookdev, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus the many related feedback-* and io-profile_validate siblings. The description implies it is for objective mesh quality measurement, but there are no explicit usage conditions, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden, but it only states the high-level action and result. It does not disclose potential side effects, whether the viewport is modified, how rendering is performed, or whether this is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words. It front-loads the core action and expected result, making it easy to parse, though it is lean to the point of losing useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no annotations, and no output schema, the description is too sparse. It does not explain how the returned image sequence is delivered, what output format is expected, or how the parameters affect the orbit behavior, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate with parameter guidance, but it mentions no parameters. The schema titles provide some meaning, but the description itself adds no semantic value about res, count, object, or shading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('Orbit') and resource ('object/scene') and states the outcome ('return a sequence of images'). It is clear and actionable, though it does not explicitly distinguish itself from sibling feedback-capture tools or mention the 'turntable' concept beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like feedback-capture or feedback-capture_views. The description only states what the tool does, not the context in which it is preferred or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavioral traits itself. It implies a read-only operation via 'report' but does not explicitly state safety, side effects, or what happens to the object/modifier. The description adds minimal behavioral context 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, one sentence with no fluff. However, it is under-specified, so while it is well-structured and front-loaded, it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a report tool with no output schema and no annotations, the description is too minimal. It does not describe the return format, behavioral nuances, or how it differs from similar report tools (e.g., other *_report tools). Given the complexity of Geometry Nodes modifiers, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters 'object' or 'modifier' beyond their titles. The description mentions the modifier and node group, which loosely relates, but it does not clarify which object or how the modifier name is used, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reports a Geometry Nodes modifier and its node group, using a specific verb and resource. It distinguishes from sibling tools that create, add, or link nodes, though it does not specify the exact content of the report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like geometry_nodes-create_modifier or geometry_nodes-add_node. The context of a report tool is implied but no explicit usage context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. 'Merge selected vertices' implies a permanent modification to the mesh, but it does not disclose side effects (e.g., what happens to faces/edges), prerequisites (e.g., vertex selection required), or whether UVs are affected by default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence with no filler. It is front-loaded and efficient, but the extreme brevity sacrifices necessary operational detail. It earns a 4 for being concise without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (multiple merge modes, UV toggle, object targeting) yet the description provides none of the needed context. There is no output schema to compensate, so the agent lacks information about behavior, return values, or how parameters interact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description adds no explanation of the three parameters (uvs, type, object). The enum for 'type' is self-explanatory to some extent, but the description does not elaborate on options like CENTER vs CURSOR or how the 'object' parameter works, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Merge selected vertices' uses a specific verb and resource, clearly conveying the core operation. It is distinct from sibling tools like 'mesh-subdivide' or 'mesh-remove_doubles' but does not explicitly differentiate itself, leaving a small ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With sibling tools like 'mesh-remove_doubles' (which also merges vertices by distance) and 'mesh-dissolve', the lack of context or exclusions makes it hard for an agent to select this tool 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 carries full burden. It doesn't disclose whether the selection replaces, adds, removes, or toggles (though the 'action' parameter covers this), nor does it mention side effects like deselecting other elements, mode requirements, or whether the operation is destructive. The description is minimal and lacks behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core purpose. No wasted words, but it may be too terse given the lack of parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain how indices are formatted (comma-separated is in schema but not description), what modes are available, or what the tool returns. The tool is moderately complex (selection actions, element modes) and the description doesn't cover these aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'zero-based index' which relates to the 'indices' parameter, but doesn't explain 'mode' (VERT/EDGE/FACE), 'action' (REPLACE/ADD/REMOVE/TOGGLE), or 'object' semantics. The description adds minimal value beyond the schema's titles and enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Select mesh elements by zero-based index' clearly states the action (select) and resource (mesh elements) with a specific detail (zero-based index). It distinguishes from sibling tools like mesh-select_all and mesh-selection_report, though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like mesh-select_all or mesh-selection_report. The description implies usage for selecting specific elements by index but doesn't provide context on prerequisites (e.g., object must be in edit mode) or when to prefer other selection 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 full burden. It only states the primary action without disclosing how the conversion works, the effect of the face_threshold and shape_threshold parameters, or any side effects like merging faces. It does not contradict annotations (none exist), but it is far from transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise and front-loaded. There is no wasted text. However, it may be too sparse, sacrificing needed detail for brevity. Still, it earns a high score for conciseness without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description is incomplete. It does not explain the object parameter's default behavior (active mesh), the role of the threshold angles, or any prerequisites such as having a mesh selected. Given the tool's complexity (topology conversion), more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameters. It does not mention any of the parameters (object, face_threshold, shape_threshold). The schema provides only titles and defaults, leaving the agent to guess the meaning and interaction of thresholds. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Convert selected triangles to quads') with a specific verb and resource. It defines what the tool does at a high level. However, it does not explicitly distinguish from sibling tools like mesh-quads_to_tris or mesh-fill, though the opposite nature is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. It does not mention when to apply it (e.g., after using mesh-quads_to_tris or for cleanup) or any prerequisites (e.g., need an active mesh with selected triangles). No exclusions are stated, but that is because nothing is 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?
With no annotations, the description must carry behavioral disclosure, but it only states that a modifier is added. It does not mention ordering, side effects, immediate application, or any prerequisites for the object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler or repeated information. It is efficient, though the terseness contributes to under-specification elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, a single sentence is insufficient context. The schema titles clarify some defaults, but the description alone leaves significant gaps around usage, side effects, and alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining type, name, or object parameters. The word 'object' loosely maps to one input, but type values and defaults are left to the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a clear verb ('Add') and resource ('modifier to an object's stack'), so the basic purpose is unambiguous. It does not explicitly mention sibling tools such as modifiers-set or modifiers-copy, making the distinction less direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided, and no alternatives are referenced. The only context is the imperative in the description, which is not enough to choose confidently among the many modifier-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing side effects (e.g., name conflicts, renaming all objects with the same name, or what happens if the object is not found).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient and front-loaded. However, it is so minimal that it sacrifices informative value for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter rename tool with no annotations, no output schema, and no parameter documentation, the description is underspecified. It does not cover edge cases, expected behavior, or the operational context beyond the bare operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter-level meaning. The property titles 'New object name' and 'Object name' give some hint, but the distinction between them is ambiguous without further context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename') and the resource ('an object'), matching the tool name. It distinguishes from siblings like object-delete and object-duplicate, though it doesn't specify what type of object or scope is affected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of alternatives like outliner-collection_rename or object-duplicate. It also lacks prerequisites such as whether the object must exist or if it affects the active object only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states 'Read', implying non-destructiveness, but does not describe return format, coordinate space, or behavior on invalid object names. This is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and direct. It avoids fluff, though it is under-specified in other dimensions; the brevity itself is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 1 parameter, no output schema, and no annotations, the description still lacks key details such as what the returned transform state contains and how the object is uniquely identified. This creates a meaningful gap for an agent expecting actionable information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the lone parameter 'object' only has a title 'Object name'. The description does not clarify whether the parameter expects a name, path, or ID, nor does it add semantics beyond the generic 'an object'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Read') and identifies the resource ('an object's transform state'), which distinguishes it from sibling tools like object-transform_set and object-transform_apply. However, it does not elaborate on what 'transform state' encompasses (e.g., location, rotation, scale), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as object-transform_set or object-origin_set. The description provides no contextual cues, exclusions, or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It states 'describe' which implies a read operation, but does not clarify return format, behavior on missing targets, or any side effects. It lacks specifics like whether it's non-destructive or requires particular permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise with no redundancies. It is front-loaded with the core action, but it is so brief that it sacrifices substance for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (multiple kinds, a default, 2 params, no output schema, no annotations), the description is incomplete. It doesn't specify what 'describe' returns, how to use the kind parameter, or any edge cases, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the 'kind' or 'target' parameters beyond what the schema already provides. It lists the kinds implicitly in the prose but fails to clarify how the kind parameter interacts or what format target should be in, leaving 0% schema coverage uncompensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (describe) and the resource (object, collection, scene, or view layer by name). It distinguishes from sibling tools like outliner-visibility_set by focusing on description, but doesn't explicitly mention alternatives or scope beyond the listed kinds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided. The description implies use when you need to describe a named datablock, but doesn't mention when to prefer this over other outliner tools like outliner-find or outliner-tree, nor does it state any prerequisites 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 carries the full burden of disclosure, but it only says 'Set... restrictions.' It does not state whether this mutates existing settings, whether boolean flags overwrite or merge with current values, what happens if the view_layer or collection does not exist, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the verb and resource, and free of filler. It is structurally clean, though the brevity comes at the cost of missing useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has six parameters, two required, no annotations, and no output schema, yet the description is only a single clause. It lacks prerequisites, behavior on existing settings, validity constraints, and any indication of return values or errors. The description is not complete enough for an agent to invoke this correctly in varied situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds almost no parameter meaning. 'Restrictions' vaguely hints at boolean toggles like exclude, holdout, viewport, and indirect_only, but domain-specific terms such as 'holdout' and 'indirect_only' remain completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and identifies the resource ('view-layer collection restrictions') for one collection. It clearly indicates the operation's scope, though it does not explicitly distinguish itself from sibling tools like outliner-collection_visibility_set or outliner-view_layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as outliner-collection_visibility_set, outliner-view-layers, or outliner-view_layer_create. The intended usage is only implied by the name and description, with no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether this is a mutating operation (which 'set' implies) or any side effects, such as immediately updating the system or requiring a viewport refresh. It also doesn't mention error scenarios or confirmation responses, leaving the agent with minimal behavioral understanding 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of a single sentence that gets to the point. It does not waste words, but it could be longer to provide necessary detail. It is appropriately brief for a simple action, though lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and zero parameter documentation in the description, the description is incomplete. It leaves the agent guessing about the exact property path format, value handling (JSON), and which object sub-parts are editable. The tool's complexity is moderate (four parameters) but the description only covers half the picture. Sibling tools like physics-set and pointcloud-set likely have similar patterns, but the description does not leverage that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. The description only mentions 'RNA property' and 'particle system', but the parameters 'object' (what object to edit) and 'value' (JSON format) are not elaborated. For example, 'object' could be 'system' or 'settings', and 'value' must be JSON, which is in the schema but not in the description. The description fails to clarify parameter relationships or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set one RNA property on a particle system or its settings' clearly states the action (set an RNA property) and the resource (particle system or its settings). It distinguishes from sibling tools like particles-add/remove (which create/delete systems) and particles-report (which reads). However, it does not explicitly mention that it modifies rather than creates, but the verb 'set' conveys that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like physics-set or pointcloud-set, nor does it specify any prerequisites or conditions (e.g., must select a particle system first). It implies usage by its name and purpose but lacks explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must fully disclose behavioral traits. It adds the word 'live' to suggest current/dynamic RNA values, but it does not explain whether this is read-only, what data is included, what 'RNA properties' means, or what the output format is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is easy to scan and front-loads the main action. It is not bloated, though it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, the description is too thin. It does not specify what the report contains, how results are presented, or any operational context such as whether live data can be refreshed or queried by data-block name versus object reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the name_or_object parameter beyond what the schema title already states. It adds only the vague target 'point cloud' but not what kinds of names or objects are accepted or how the object is resolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and resource ('a point cloud'), clearly indicating this tool retrieves live RNA property information. It distinguishes itself somewhat from sibling tools like pointcloud-list and pointcloud-set, though it doesn't explicitly differentiate from pointcloud-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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as pointcloud-attributes or rna-get_property. The description implies a reporting purpose but gives no explicit context, exclusions, or recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It says 'Report' which implies read-only, but it does not explicitly state that it does not modify anything, nor does it mention any limitations, side effects, or prerequisites. The term 'live' suggests state access but is not elaborated. This is insufficient for a tool with no 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous content. It is concise and to the point, though it could be more informative within the same length. Structure is effective for brevity but lacks detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no output schema, the description is underspecified. It does not explain what the report returns in detail, how the include flags affect output, or when this tool is more appropriate than siblings. The description alone is insufficient for an agent to correctly invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'data', 'modifiers', and 'custom props' which map roughly to include_data and include_modifiers, but it does not explain the 'include_values' parameter. The description adds minimal meaning beyond the schema's parameter titles, leaving the boolean flags unexplained and uncontextualized.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Report' and the resource: 'all live RNA properties for an object, its data, modifiers, and custom props'. This is specific and distinguishes it from generic siblings like 'properties-report' by scoping to object-level with data, modifiers, and custom props. However, it does not explicitly differentiate from similar reporting tools, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, context, or when to prefer it over 'properties-report', 'rna-describe', or other property tools. The only hint is that it's object-specific, but that is implicit, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Set common render settings', which merely indicates mutation without addressing side effects, scope (current scene? global?), persistence, or whether settings are applied to subsequent renders. There is no consideration of auth, permissions, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence is highly concise and free of filler. However, it is more under-specification than deliberate condensation; the sentence offers little nuance but earns its place as a minimal label.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six optional parameters and no output schema or annotations, the description is insufficiently complete. It does not mention what these settings affect, how they relate to rendering workflows, or when they take effect. A sentence about the target workflow (e.g., 'Sets parameters for render-still') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level information, and schema description coverage is 0%. While the schema properties have descriptive titles and enums, the description does not compensate for the low coverage or clarify interactions between parameters (e.g., how transparent relates to image_format). This is less than ideal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'render settings', which accurately reflects the tool's function. However, the qualifier 'common' is vague, and it does not distinguish itself from sibling tools like render-settings or render-still, though the set action is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as render-still or render-settings. It neither states prerequisites, exclusions, or the intended context (e.g., before rendering a still image). This is a clear gap for an otherwise flexible settings setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 side effects, validation, or safety concerns. It only mentions that the value is JSON-encoded, but does not explain potential risks like setting invalid data, undo behavior, or whether changes are permanent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for its core purpose, though some behavioral details are missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and sparse parameter info, the description is insufficient. It does not explain return values, potential failures, or how the JSON encoding should be formatted beyond a generic mention. This could be dangerous for an arbitrary property setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage (only titles), so the description must compensate. It mentions 'path under bpy.data' and 'value is JSON-encoded', which overlaps with the schema titles but adds little beyond them. No additional examples, format details, or constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'a data property by path under bpy.data', which identifies its function and distinguishes it from generic property setters like properties-set. However, it does not explicitly differentiate from sibling tools like rna-call_operator or properties-set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, leaving the agent to infer use cases from the bpy.data path mention. There are no exclusions or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the mutation action but omits side effects, error conditions, or 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, and front-loaded intent. However, it is too minimal to provide adequate context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 required parameters, no annotations, and no output schema, the description lacks essential context like usage examples, prerequisites, or validation rules, making it severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description adds no parameter explanations. It does not clarify the format of 'value' or the nature of 'property' beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (set), target (strip modifier), and scope (one RNA property), distinguishing it from sibling tools like add, remove, and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool, prerequisites (e.g., modifier must exist), or alternatives such as sequencer-modifier_add or sequencer-modifier_remove.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details, but it only states the removal action. It does not explain whether removal is permanent, what happens if the named effect does not exist, or whether the target object must be specified in a particular format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundant wording. It is concise, though the brevity sacrifices important usage and behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a very short description, the tool lacks sufficient context for reliable invocation. The description does not explain how the object parameter is used or what the operational consequences of removal are, leaving a destructive action under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds little beyond the schema titles. The word 'named' aligns with the 'name' parameter, but the role of the 'object' parameter and any constraints on its value are left entirely to the schema title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and identifies the resource ('a named shader effect'), which distinguishes it from sibling tools like shaderfx-add, shaderfx-list, and shaderfx-set. It could additionally clarify that removal targets a specific object, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as shaderfx-add, shaderfx-set, or other remove tools. Prerequisites like the existence of the effect or how to target an object are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must explicitly disclose behavioral traits. It only says 'set', which implies mutation, but does not mention side effects, error behavior, or any requirements (e.g., whether the shader effect must already exist, whether it overwrites existing values, or what happens on failure). The description is insufficiently transparent for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource. It is efficient and avoids fluff, though it may be overly terse given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 required parameters, no annotations, and no output schema, this description is critically incomplete. It does not explain how the shader effect is identified, what the value format is, or any operational context (e.g., that it mutates an existing effect). It leaves too much to the agent to infer from parameter titles alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the parameters beyond what the schema titles already provide. It does not explain the relationship between object/name/property/value, nor clarify that value is expected as a JSON string. Schema coverage is 0%, so the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: set one RNA property on a shader effect. It uses a specific verb (set) and resource (shader effect), and distinguishes from sibling tools like shaderfx-add, shaderfx-remove, and shaderfx-report by focusing on property assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, such as the shader effect needing to exist first, or contrast with shaderfx-set versus other set tools like shading-set_node_input or rna-set_property.
Agents often have multiple tools that could apply. Explicit usage guidance like "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, but it only says what the tool does, not how it behaves. It does not mention whether the material is auto-assigned, what default node setup is created, or whether this is destructive to an existing material.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, front-loading the key action and object. It is appropriately concise though perhaps too sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no annotations and no output schema, more context is needed. The description lacks guidance about return values, side effects, or relationship to the active material/selection, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the parameter title 'Optional material name'. It does not clarify how the name parameter affects the material or what happens when it is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new node-based material'), making the tool's purpose immediately understandable. It distinguishes from siblings like shading-assign_material or shading-list_materials, though it doesn't explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as shading-set_principled or shading-add_node. There is no mention of prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. The word 'Read' implies non-mutating behavior, but it does not state what happens for invalid paths, the return format, or any side effects. This is insufficient for a getter tool without annotations or an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that is front-loaded with the verb and object. There is no redundancy or fluff, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and lack of annotations, the description is incomplete. It does not explain what the return value is, whether errors are raised for missing paths, or how the dot path maps to tool settings. The agent lacks sufficient context to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'path' with a title 'Dot path under bpy.context.tool_settings', and schema description coverage is 0%. The description adds no meaning about path format, constraints, or examples; it simply repeats the tool's purpose. The schema title provides some context, but 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'one ToolSettings path', indicating a singular retrieval operation. It distinguishes from sibling tools like 'tool-setting_set' (write) and 'tool-settings' (list) through the word 'one', though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that it is for reading a single setting value, nor does it contrast with 'tool-setting_set' or 'tool-settings', 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 carries full burden for disclosing behavioral traits. It does not mention side effects such as modifying existing UVs, auto-creating seams, or whether the operation is destructive. The phrase 'Smart UV project' implies it may alter UV layout but lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, one sentence, and front-loaded with the core purpose. It earns its place without unnecessary filler, though it could benefit from slightly more detail given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no annotations, the description is incomplete. It does not cover usage scenarios, parameter behavior, or operational details, leaving an agent with insufficient context to decide when and how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not mention any of the three parameters (object, angle_limit, island_margin) or their roles, although the schema titles provide some basic semantics. The mention of 'angle-based' hints at angle_limit but does not explain the other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Smart UV project') on a specific resource ('the selected faces') and hints at the approach ('angle-based auto seams'), which helps distinguish it from sibling tools like uv-unwrap or uv-cube_project. However, it could be more explicit about what 'smart' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like uv-unwrap or other projection methods. The description does not mention any prerequisites, selection requirements, or scenarios where this is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. 'Report' implies a read-only operation and 'live' suggests current state, but the description does not disclose return format, error behavior, side effects, or required context, leaving the agent with significant 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundancy. It is appropriately concise, though it sacrifices substantive content for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and no output schema, which lowers complexity, but the description is still too sparse. It does not explain what returning 'live RNA properties' entails, what the output looks like, or when the operation might fail, so an agent cannot fully anticipate the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not. The schema title 'Volume object or data-block name' provides the only useful hint; the description adds no information about what values are valid or how to specify the volume.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('Report') and the resource ('live RNA properties for a volume'), and the 'volume-report' name is distinct from sibling tools like 'volume-list', 'volume-set', and 'volume-import'. However, it does not explain what 'RNA properties' refers to, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool over alternatives, what prerequisites exist, or how it differs from 'volume-list' or other report tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action but does not mention side effects (e.g., losing unsaved state), permissions required, or whether the switch is immediate and persistent. It lacks any detail beyond the obvious action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple operation, though it could include additional context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple switch operation, the description is minimally viable but lacks important context such as how to list available workspaces (e.g., via 'app-workspaces') or what happens if an invalid name is given. Given the absence of output schema and annotations, it could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter 'name' with no description, and schema coverage is 0%. The description adds only the phrase 'named workspace', which provides minimal context. It does not clarify the expected format of the name, how to retrieve valid names, or any constraints (e.g., exact match vs partial match).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (switch active window) and the target (named workspace), which is specific and unambiguous. It does not explicitly differentiate from sibling tools like 'app-workspaces' (likely listing), but the verb 'switch' distinguishes the intent well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that workspace names can be discovered via 'app-workspaces' or any prerequisites or context for switching. 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?
With no annotations, the description must carry the full burden of disclosing side effects. It only says 'Update object selection' without mentioning that the default action is REPLACE, how existing selection is affected, or what happens for invalid object names. The schema provides the action enum, but the description does not augment this with behavioral context, so the agent is left to infer the mutation semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately communicates the operation and key parameter format. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is under-specified for a state-changing tool with three parameters and no output schema. It omits how the action parameter modifies the selection, the default REPLACE behavior, handling of the active object, and potential failure modes. The agent likely needs more information to invoke it correctly in various scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only adds meaning for the 'objects' parameter via 'comma-separated object names'. The 'action' and 'active' parameters are left to title-level hints and enum values, with no additional explanation from the description. This is insufficient for a 3-parameter tool with no comprehensive schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('object selection') with a clear modifier ('by comma-separated object names'). This distinguishes it from sibling tools like context-select_all, which would select all objects rather than named ones. It is concise and unambiguous enough, though 'update' could be more precise about the selection operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as context-select_all or context-mesh_select_mode. The description only states the action without explaining the context in which it should be invoked or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of explaining behavior. It only restates the schema's select parameter ('optionally select it') and does not disclose side effects like whether previous selections are cleared, whether the object must already exist, or any other contextual behavior changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short, front-loaded sentence that directly states the action and optional parameter. No wasted words or redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and minimal parameter semantics, the description is too sparse for an agent to understand all relevant behavior. While the tool is simple, absence of prerequisites, side effects, or object identifier details leaves important gaps for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it adds little beyond paraphrasing the schema titles: 'Object to make active' and 'Also select the object'. It does not clarify the expected format of the object string (e.g., name, path, or ID) or the consequences of the select parameter beyond the schema default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and clear resource ('the active object'), and mentions the optional selection behavior, making the core action unambiguous. It partially distinguishes itself from sibling tools like context-select_objects by emphasizing 'active' versus selection, though it doesn't explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives such as context-select_objects or context-select_all. The intended use is only implied by the phrase 'active object' and the sibling tool names, offering no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It mentions rendering and returning analytics, but does not clarify whether the tool modifies the scene, requires specific permissions, or has side effects. This lack of transparency could cause an agent to misuse 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that captures the core action and result. It has no redundancy or unnecessary details, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the basic purpose but omits important context: when to use it, what the analytics contain, and any side effects. Given the simplicity of the tool, it might be acceptable, but the lack of usage and behavioral details makes it incomplete for an agent to safely and effectively invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides titles for parameters (e.g., 'Square render resolution (px)', 'Named view to render from'), but no descriptions. The tool description mentions none of the parameters, so it fails to add meaning beyond the schema. Since the schema coverage is low (no descriptions), the description should have compensated by explaining the purpose of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a normal/backface orientation eye and returns orientation analytics. It is specific enough to distinguish it from other feedback tools like feedback-topology or feedback-uv, though the exact nature of the 'eye' and the analytics could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, contexts, or any conditions that would make this tool the preferred choice, leaving the agent to infer its purpose from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action and resource without explaining side effects, return value format, or potential errors. The read-only nature is implied by 'report' but not explicitly confirmed, and no details about data coverage are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the primary action and target. It contains no fluff or redundant information, fitting the minimalist style of the sibling report tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is relatively simple (one parameter, no output schema), the description omits crucial context such as what data is actually reported, whether the tool is read-only, and how the output is structured. Given the lack of annotations and output schema, the description leaves a significant gap for an agent to anticipate behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage stealth, and the description adds no explanation for the 'object' parameter beyond the schema's title. It does not clarify the expected format (e.g., name vs. path), accepted object types, or how the parameter affects the report. Thus, the description does not add meaningful value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (report) and the resource (non-mesh geometry object data), which distinguishes it from mesh-specific reporting tools. However, it does not specify what aspects of the data are reported (e.g., dimensions, transforms, modifiers), leaving some ambiguity about the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like mesh_report or other report tools. The description only implies a use case for non-mesh geometry, but does not explicitly state prerequisites, exclusions, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It reveals that the tool mutates state ('Set'), but gives no information about side effects, error handling, reversibility, or prerequisites. The agent is left blind to what happens on invalid input or partial changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple setter, but with no annotations, no output schema, and minimal parameter documentation, the description is too sparse. An agent would need external knowledge about light probe data-blocks, RNA property paths, and valid values to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only adds the term 'RNA property', which hints at the property parameter's nature, but does not explain how to construct the value JSON, what names are valid, or how to find available properties. The schema titles already provide basic meanings, so the description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('one RNA property on a light probe data-block'). It is specific enough to distinguish from sibling tools like lightprobe-list or lightprobe-report, though it does not explicitly differentiate from other property-setting 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, when not to use it, or how to discover valid properties. The description only states what it does, not the context in which it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply states the action without revealing whether the operation is destructive, whether it requires a specific mesh mode, or what side effects occur (e.g., modifying geometry). This lacks critical transparency for safe tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and target, exemplifying concise writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, the description is too sparse to fully guide an agent. It fails to cover essential context such as object targeting (defaulting to active), selection requirements, the effect of offset and segments, or the result of the operation, making it inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate, but it does not mention any of the three parameters (object, offset, segments). The schema's titles ('Bevel width', 'Number of bevel segments') provide some clarity, but the description adds no additional meaning or usage details for these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Bevel' and identifies the resource as 'selected edges/vertices', clearly indicating a mesh editing operation. It distinguishes itself from sibling tools like extrude, inset, or subdivide, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other mesh operations, nor any prerequisites such as being in edit mode or having a mesh selection. The only implied context is the mention of 'selected edges/vertices', but there is no explicit when-to-use or exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits on its own. It states 'Delete' which implies a destructive operation, but it does not explain consequences like irreversibility, how different delete modes affect connected elements, or whether the tool only operates on the active object. This is too thin for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words and is front-loaded with the key verb. However, it is borderline under-specified, but as a standalone summary it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with five enum-based delete modes and no output schema. The description is not complete enough for safe invocation: it does not explain mode-specific behaviors, prerequisites like being in edit mode, or the effect of the object parameter. An agent would likely need to inspect the schema or experiment to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no semantic detail for the parameters. It does not explain what the 'type' enum values (VERT, EDGE, FACE, etc.) actually do or how the 'object' parameter behaves beyond 'defaults to active'. The description fails to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete selected mesh elements' clearly names the action (delete) and the resource (selected mesh elements), distinguishing it from object-level deletion tools like object-delete and from other mesh operations. The scope is specific enough to convey 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as mesh-dissolve, mesh-merge, or object-delete. It does not mention edit mode requirements, prerequisites, or situations where a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only says 'extrude and translate' but does not mention whether the operation is destructive, requires a selection, affects the original mesh permanently, or what happens if no selection exists. No side effects or prerequisites are described, leaving the agent without crucial behavior expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's function. It is extremely concise, with no wasted words, and front-loads the primary action. Given the simplicity of the tool, this level of brevity is appropriate and earns high marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient for a tool that modifies mesh geometry. It lacks details on prerequisites (active object? edit mode?), the result of extrusion, whether translation is applied relative to original or extruded face, and any return values or side effects. With no output schema, the description should compensate but fails to provide essential operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description adds no parameter information beyond the schema titles. The titles like 'Mesh object to edit (defaults to active)' and 'Translation applied to the extruded region [x, y, z]' provide basic meaning, but the description does not explain how to use these parameters, their formats, or their interplay. The description adds no value beyond the schema's inherent hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Extrude the selected region and translate it' clearly identifies the action (extrude and translate) on a specific resource (selected region of a mesh). It distinguishes from sibling mesh editing tools like bevel or inset by focusing on extrusion plus translation. However, it is somewhat generic and doesn't mention that it operates on mesh objects or any specifics about the extrusion behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It doesn't describe prerequisites (e.g., having a mesh selected, being in edit mode), nor does it mention scenarios where other tools like 'mesh-bevel' or 'mesh-inset' might be more appropriate. The description only states the operation without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It states the core mutation but doesn't mention that the operation is destructive, that it operates on the active/selected object, or how the different triangulation methods affect results. This is minimal transparency for a mesh-editing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler words, which is excellent conciseness. However, it is so brief that it omits essential operational context, making it slightly under-specified rather than optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, two of which are enum-based, and no annotations or output schema, the description is incomplete. It explains the basic operation but fails to mention object targeting or the meaning/selection of triangulation methods, leaving an agent without enough context to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning for object, ngon_method, or quad_method. The enum values (BEAUTY, CLIP, FIXED, etc.) are left unexplained, and the description doesn't even hint that these parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and target ('Convert selected faces to triangles') that precisely identifies the operation and scope. It clearly distinguishes from siblings like mesh-tris_to_quads, mesh-subdivide, or mesh-fill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies you need selected faces but provides no explicit guidance on when to use this tool versus alternatives such as mesh-subdivide, mesh-tris_to_quads, or mesh-fill. It also doesn't mention prerequisites like being in edit mode or requiring a mesh object.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It does not mention that this is a mutating operation, whether existing normals are overwritten, how the 'inside' parameter affects behavior, or any side effects on the mesh.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is so brief that it sacrifices useful detail, though conciseness itself is strong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating mesh operation with no annotations and no output schema, the description is incomplete. It does not explain the effect of the 'inside' parameter, how the target object is chosen, or what 'consistently' means in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to either parameter. The 'inside' and 'object' parameters are only explained by their schema titles, not by the tool description, which fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Recalculate') and the resource ('mesh normals'), with a qualifier ('consistently') that adds intent. It is distinct from sibling mesh tools like mesh-shade_smooth or mesh-fill, which address different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. The description simply states what it does without contextualizing its appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Report' without clarifying whether the operation is read-only, what output format to expect, or how selection is determined (e.g., mesh mode, hidden elements).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler or redundancy, placing the action and target immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal annotations, this description is under-specified. It does not convey what kind of report is generated, the format or type of data returned, or the conditions under which 'selected' is determined for the given object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'object', is not mentioned in the description. While the schema title provides 'Mesh object to inspect (defaults to active)', the description itself adds no parameter meaning and does not compensate for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Report') and the specific resource (selected vertices, edges, and faces). It distinguishes the tool from more generic sibling tools like mesh-report by focusing on selection data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as mesh-report or mesh-select_all. There are no explicit exclusions, prerequisites, or recommended contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It does not state that the operation modifies the mesh, is destructive, or that it affects the active object. It also fails to mention that the 'cuts' parameter controls subdivision levels or that the operation may fail without a selection. This is insufficient transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no superfluous content. It is front-loaded with the essential purpose. Perfectly sized for such a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's apparent simplicity, the description is incomplete. It lacks details about what 'subdivide' does geometrically, how 'cuts' affects the result, what the 'object' parameter overrides, and what happens if no selection is made. With no output schema and only minimal parameter schemas, the description should provide richer context but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining the parameters. It does not mention 'cuts' or 'object' at all. While the schema titles ('Number of cuts' and 'Mesh object to edit (defaults to active)') are descriptive, the tool description adds no additional meaning, leaving the parameters under-explained especially regarding their optionality and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Subdivide') and a specific target ('selected edges/faces'), making the tool's purpose understandable. However, it does not explicitly differentiate itself from similar mesh editing operations like bevel or inset, though the verb 'subdivide' is distinct enough. It is specific but lacks mention of the mesh object context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention typical use cases (e.g., increasing geometry density), prerequisites (like having a selection), or scenarios where other mesh tools would be more appropriate. There is no 'when not to use' or reference to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions 'bake' but does not state that applying modifies the mesh permanently and typically removes the modifier from the stack. The irreversible nature of the operation is not disclosed, and there is no mention of how it affects the object's data or whether it can be undone. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundant or filler content. Every word contributes to conveying the core action. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 params, no output schema, no annotations), the description is not complete. It omits crucial details about the operation's irrevocability, the fact that applying typically removes the modifier, and any prerequisites (e.g., object selection). For a destructive operation, this is a serious omission. The description does not prepare the agent for the tool's side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has informative titles for both parameters ('Name of the modifier to apply' and 'Object owning the modifier (defaults to active)'), but the description adds no parameter-specific context. Since schema description coverage is 0% (the description does not mention parameters), it fails to compensate, although the schema titles themselves reduce the need. Overall, the description provides no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Apply (bake) a modifier into the mesh,' which specifies the verb and resource, and it distinguishes from sibling tools like modifiers-add, modifiers-set, and modifiers-remove by indicating a permanent baking operation. It is slightly generic but effective.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of when applying is appropriate compared to setting visibility or removing a modifier, nor any mention of fallback tools like modifiers-set. The description implies a use case but does not explicitly state it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without addressing potential errors (e.g., invalid property, missing modifier), effects on other properties, or error handling. The one-sentence description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words, perfectly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is minimally adequate but lacks context on how to discover valid properties (e.g., referencing modifiers-types) and the behavior of the optional 'object' parameter. It assumes the user knows modifier terminology, which may be acceptable given the sibling toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it adds no parameter details beyond the schema's titles. It does not explain valid property values, defaulting behavior, or value coercion, which are only hinted at in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set a property') and the target resource ('an existing modifier'), distinguishing it from sibling tools like modifiers-add or modifiers-remove. However, it is somewhat generic and doesn't specify which properties are settable, relying on the schema for that detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided; the description does not mention when to use this tool versus other modifier tools like modifiers-set_visibility or modifiers-move, nor any prerequisites (e.g., modifier must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full behavioral burden. 'Add a particle system' only conveys a mutating action; it does not disclose whether existing particle systems are preserved, whether a duplicate name is rejected, whether the object must be valid/editable, or what the result of a successful call looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence, 'Add a particle system to an object,' with no filler or redundancy. It is front-loaded with the action and target, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an action tool with no annotations and no output schema, the description is not complete enough. It does not explain prerequisites, side effects, or how addition interacts with existing particle systems. The low parameter count reduces complexity, but the missing behavioral context for a mutating operation is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to explain the 'name' and 'object' parameters, but it only mentions 'an object' generically. The schema's titles ('Optional particle system name', 'Object to edit') provide minimal meaning, yet the description adds no semantic detail about defaults, naming behavior, or which object is selected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Add a particle system to an object.' The verb 'add' and the noun 'particle system' distinguish it from related sibling tools like particles-remove, particles-report, and particles-set. However, it does not explicitly scope beyond 'an object' (e.g., new vs. existing system), which keeps it just short of fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as particles-set or particles-remove. It only states the basic action, leaving the agent to infer which situation calls for adding a particle system rather than modifying or removing 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, the description must carry the behavioral disclosure burden. It mentions reporting project preferences and project.toml data, which suggests a read operation, but it does not explain what 'preferences' or 'active project fields' entail, nor does it specify if the tool is read-only, whether output formatting is consistent, or any side effects. This is a significant gap for a tool with no structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is concise, with no waste. It is front-loaded with the action 'Report' and resource 'project preferences, active project fields, and project.toml data', making it easy to scan. It could be more structured but is generally acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, no output schema, and no annotations, so the description is the only source of information. It names several pieces of data but lacks details on the structure of 'project.toml data' or what 'preferences' might include. For a reporting tool, the description is insufficiently complete given the lack of schema and output schema context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and provides no parameter details. The description does not need to explain parameters, but it does mention the types of data returned (preferences, fields, toml data), which gives some context. Since there are no parameters, the description actually compensates reasonably by indicating what is reported.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool reports project preferences, active project fields, and project.toml data. It identifies a specific resource (project settings) and the action (report), but it does not clearly distinguish from sibling tools like project-report or project-files, making it somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives such as project-report or properties-report. The description implies a read-only reporting purpose but fails to elaborate on appropriate contexts, exclusions, or relationships with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It adds one detail: 'args validated against its RNA', which hints at argument checking. But it does not disclose that running bpy.ops operators can mutate scene state, may fail due to context/poll requirements, or what happens on error. This is a significant transparency gap for a tool that executes arbitrary operators.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no filler. It efficiently conveys the core purpose and the key value-add (RNA validation). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex generic tool with no output schema and no annotations. The description is far too minimal to be complete: it doesn't explain return values, error handling, how selection/object/mode affect execution, or how the JSON arguments should be structured. Given the breadth of bpy.ops, significantly more detail is needed for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It only mentions 'args' and validation, but does not explain the JSON format for args, the purpose of mode/object/select, or how idname maps to an operator. The schema titles provide some examples, but the description adds little beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Run any bpy.ops operator'. The verb 'Run' and resource 'bpy.ops operator' are specific, and the phrase 'any' differentiates it from dedicated sibling tools like mesh-bevel or object-shade_smooth. However, it doesn't explicitly distinguish itself from similar generic tools like ui-operator_invoke.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this generic operator runner instead of a dedicated operator tool or ui-operator_invoke. The description implies it can handle any operator, but doesn't state that it should be used as a fallback or for unsupported operators. No exclusions, alternatives, or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action (create) without mentioning side effects, whether the new object becomes the active/selected one, if it requires an active scene, or any limitations. The description is too thin for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It is appropriately sized for the tool's simplicity and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description fails to provide essential context such as success/failure behavior, return values, prerequisites (e.g., active scene), or examples. For a creation tool, more information is expected to ensure correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds nothing about parameters. The schema itself provides titles for parameters (e.g., 'Primitive type', 'World location'), so the agent can infer meaning, but the description fails to compensate for the low coverage as required. It doesn't explain how parameters affect behavior or any defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a primitive object in the scene, using a specific verb and resource. It distinguishes from general object creation (object-create) by limiting to primitives, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other creation tools like object-create, geometry-create_curve, or volume-create_empty. The sibling list includes many creation tools, and without context, an agent cannot decide which one 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, the description carries the full burden, but it only states the action without disclosing any behavioral traits beyond it. It does not mention whether the operation appends or replaces modifiers, potential side effects (e.g., requiring an existing strip), or failure conditions. This is a minimal behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the purpose without filler. It is front-loaded and every word contributes to the meaning, making it an example of efficient, appropriately sized description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and a low-complexity schema, but even so the description is incomplete. It doesn't explain the expected relationship between 'name', 'type', and 'modifier_name', nor does it address return behavior or required preconditions. The simple verb 'add' leaves important invocation details unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage; property titles are the only semantic clues ('Strip name', 'Modifier type, e.g. BRIGHT_CONTRAST', 'Optional modifier name'). The tool description adds no additional meaning about parameters, leaving the agent reliant on titles that may be ambiguous (e.g., 'name' could refer to modifier name or strip name).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a strip modifier to a sequence strip' clearly identifies the action (add), the resource (strip modifier), and the target (sequence strip). The specific verb 'add' distinguishes it from siblings like sequencer-modifier_set and sequencer-modifier_remove, though it doesn't explicitly contrast these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention that this creates a new modifier as opposed to setting an existing one, nor any context about prerequisites like having a strip selected. The sibling tools imply a family but the description offers no explicit 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 provided, the description carries the full burden of disclosing behavior. It states 'report' which implies a read-only operation, but it doesn't explicitly confirm no side effects, describe error handling (e.g., missing speaker), or indicate what 'live RNA properties' means. No details on return format or potential mutations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise, and front-loaded. There is no wasted text, and it gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimal but lacks important context. It doesn't explain what 'RNA properties' are, what 'live' means, or what the report output will look like. Since there's no output schema, the description should compensate by describing the return, but it doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'name' with 0% description coverage, and the tool description provides no additional explanation of the parameter. The schema title 'Speaker object name' is somewhat self-explanatory, but the description fails to add semantic context, such as how to obtain the name or what format is expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reports live RNA properties for a speaker, using a specific verb (report) and resource (speaker). It distinguishes from sibling tools like speaker-create, speaker-list, and speaker-set, which serve different actions. However, it doesn't mention that it's specifically a read-only getter, but 'report' implies that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like speaker-list or speaker-set. The description implies usage for retrieving properties, but it doesn't explicitly state context, prerequisites, or when not to use it. Sibling tools are present but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 convey behavioral traits. It states it 'reports' and mentions 'context and scene statistics', which implies a read-only operation, but it doesn't explicitly state that it has no side effects or clarify what happens when invoked. It also doesn't describe the output format. Given zero annotations, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise, and front-loaded with the verb. It wastes no words. However, it could be more informative without being verbose, so it's not perfect, but it's appropriately sized for a simple report tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description is expected to provide more context about what the report contains. It says 'scene statistics', which is vague. It should clarify what statistics are included (e.g., object counts, memory usage) and what format the output takes. For a reporting tool with no structured output, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (meaning there are no parameters to fail coverage). Since there are no parameters, the description does not need to explain any, and a baseline of 4 is appropriate. The description adds no param info, but that's fine because there's nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Report Status Bar context and scene statistics' clearly states the tool's action (report) and resource (Status Bar context and scene statistics). It distinguishes this tool from siblings like 'topbar-report' and 'particles-report' by specifying the Status Bar context and scene statistics, though it doesn't explicitly name alternatives. It's a bit vague on what 'scene statistics' includes, but it's specific enough for a basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description doesn't provide any explicit context about when to use this tool versus other reporting tools like 'scene-info' or 'context-info'. It implies it's for retrieving Status Bar and scene statistics, but there's no mention of when it's appropriate or when other tools might be better. The lack of any guidelines 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?
With no annotations, the description must disclose side effects and requirements. It states it averages scale but does not mention that this modifies the mesh, whether it is destructive, or if any selection is needed. The user is left unaware of the mutation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is concise and to the point, earning top marks for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description should compensate by explaining expected behavior, reversibility, and setup. It does none of this, so the tool is under-specified for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter ('object') is given a title in the schema but no description in the tool description. The description does not explain what 'object' means or its optionality (defaults to active). Since schema coverage is 0%, the description fails to enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Average') and the target ('texel density / scale of all UV islands'), which is a specific operation distinct from siblings like uv-pack_islands or uv-unwrap. However, it could be slightly more explicit about the scope (mesh object) and how it differs from other UV tools, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like uv-pack_islands or uv-smart_unwrap. The description does not mention context, preconditions, or exclusions, leaving the agent to guess when 'averaging' is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only says 'Export' and does not mention file overwrite behavior, format inference, what 'modified' does, or how export_all affects the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no wasted words. It is concise, though it omits useful context that would make it more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no annotations, and no output schema, a one-line description is not enough to reliably invoke the tool in varied situations. It leaves unclear the behavior of AUTO format, modifier handling, selection defaults, and failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the seven parameters. Size, format, object selection, opacity, modified, and export_all semantics are left entirely to the schema titles and defaults, so the description adds no parameter-level value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Export'), a clear resource ('mesh UV layout'), and an output form ('image file'). This clearly distinguishes it from sibling UV tools like uv-report, uv-unwrap, or uv-pack_islands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, nor are prerequisites mentioned (e.g., active mesh, existing UV map). The intended use is only implied by the verb 'export'.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 transparency. It only states that UV layers and the active UV layer are listed; it does not clarify return shape, behavior when no object is supplied, error cases, or whether anything is modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no padding or redundancy. It fails to provide some useful surrounding context, but as a prose description it is structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list-style tool with one optional parameter, the description is minimally functional: it names the primary output (UV layers) and the active-layer indicator. However, with no output schema, no annotations, and no guidance about object fallback or returned data structure, the completeness remains only partial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The one optional parameter, 'object', is not mentioned in the tool description at all. The schema title 'Mesh object to inspect (defaults to active)' provides some meaning, but with 0% schema description coverage and no description-level parameter guidance, the parameter semantics remain under-supported.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'List', and names a concrete resource: UV layers, plus the active UV layer. This clearly distinguishes it from sibling tools like uv-layer_create, uv-layer_set_active, and uv-layer_delete, which are mutation-oriented rather than read-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool instead of siblings such as uv-report or other UV-layer inspection tools. The intended use must be inferred from the single word 'List', and no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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. 'Report seam edge indices' implies a read operation but does not describe the output format, whether the active object is used by default, or how errors are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too sparse to be fully self-contained. It omits return value information, object selection behavior, and any relationship to related UV seam tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining the object parameter. It does not mention any parameters at all, despite the schema defining an optional 'object' argument; the schema's title does provide some meaning, so this is not a total failure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb and resource: 'Report seam edge indices', clearly indicating a read-only reporting action on seam edges. It is distinct enough from siblings like uv-set_seams and uv-report, though it could be more explicit about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as uv-report or uv-set_seams. The purpose implies inspection of seams, but there are no explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must explain behavioral aspects. It mentions 'writable' but doesn't describe consequences of setting a property (e.g., irreversible changes, potential errors on invalid paths, or need for context). No mention of validation or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, clear and to the point, with no unnecessary words. It's appropriately sized for a simple setter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that mutates volume properties, the description lacks context about error handling, what happens if the property is invalid, or the need for an existing volume. It also doesn't mention that it only sets one property at a time, which is implied but not explicit. Given the tool's simplicity, a slightly more detailed description would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds no parameter details. It leaves the 'value' format as a JSON string, but doesn't explain that it must be valid JSON or how to construct a property path beyond the schema's example. The schema titles already provide examples, but the description doesn't enhance them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Set) and the target (volume data-block or nested settings object), and specifies 'one writable RNA property' which distinguishes it from reporting or listing tools. However, it doesn't explicitly differentiate from sibling setters like 'physics-set' but the resource is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives like volume-report, volume-import, or other setters. It doesn't mention that for multiple properties one might need multiple calls or that it's only for volumes.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'sets' a property, implying mutation, but does not describe side effects, error behavior, or any additional context such as whether it is destructive or requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded with the verb. However, it is so minimal that it borders on under-specification rather than true conciseness—it is appropriately short but lacks essential detail for a tool with six parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (six parameters), the absence of an output schema, and no annotations, the description is far too minimal. It does not explain parameter interactions, error handling, or provide enough context to safely invoke the tool, making it incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the six parameters. The schema titles provide minimal hints (e.g., 'New value as JSON'), but with 0% schema description coverage, the description should compensate. It adds no parameter meaning beyond what the raw schema already implies, leaving users to guess the exact format and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Set' and identifies the resource as an RNA property on an object or pose-bone constraint. This clearly distinguishes it from sibling tools like constraints-list, constraints-add, and constraints-remove, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description simply states what it does without context on when to apply it, which is insufficient for a setter tool with many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions rendering and quality analytics but does not disclose whether this is a read-only operation, whether it modifies the scene, or what 'quality analytics' entails. It also doesn't state if it requires a specific viewport or if it affects the active object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the main action. It includes key features (shaded material, wire overlay, quality analytics) without unnecessary words. However, it could be slightly more structured to separate the rendering from the analytics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the return value (what 'quality analytics' means), the effect of the 'view' parameter, or any prerequisites. The sibling tools suggest a feedback family, but this description does not clarify its unique role within that family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the parameters (res, view, object) beyond what the schema provides. The description mentions 'real wire geometry overlay' but does not clarify how parameters affect the output, such as what 'res' controls or how 'object' defaults to active.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a shaded material view with wire geometry overlay and quality analytics. It specifies the resource (material view) and the action (render), and the mention of 'quality analytics' distinguishes it from other feedback tools like feedback-quality or feedback-capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting a mesh with shaded material and wire overlay, but it does not explicitly state when to use this tool versus alternatives like feedback-lookdev or feedback-capture. No exclusions or alternative tool names are provided, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 says only 'create', implying a state change, but gives no details about side effects, return values, whether a new object is added to the scene, or how parameters affect the outcome. This lacks any behavior beyond the initial verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, extremely terse sentence with zero wasted words. It is immediately parsed and front-loaded with the primary verb and object, making it easily scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no annotations, and no output schema, this description is highly under-specified. The agent cannot know what exactly happens when the tool is called, what the return value is, or how parameters affect the primitive. A creation tool should at least indicate that it adds a new of scene object, but that is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description 'Create a metaball primitive' adds nothing about the meaning of the 6 parameters. The parameter titles in the schema are self-explanatory, but the description does not help the agent understand how to use or relate parameters, failing to compensate for no description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a metaball primitive' clearly states the specific action (create) and resource (metaball primitive), which distinguishes it from sibling geometry creation tools like create_curve, create_surface, or create_grease_pencil. It is a succinct, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, and no explicit context or exclusions. It only states what the tool does, leaving the agent to infer usage from the name alone. No sibling comparisons or prerequisite conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior on its own. 'Return' implies a read operation, but it does not explain what 'Info editor report messages' contain, how 'exposed by Blender RNA' limits availability, or whether there are any side effects or permissions. The description is too thin to provide meaningful behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is 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 verb and object, making it easy to parse quickly, though the vague 'when exposed by Blender RNA' tail could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, this description is too sparse. It doesn't explain the return format, filtering behavior, or what 'exposed by Blender RNA' means, which leaves important gaps for an agent deciding whether and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'limit' parameter is well documented in the schema with a title, default, and minimum, so the description adds little here. However, since schema description coverage is 0%, the description does not explicitly mention or explain the limit parameter, missing a chance to add context about how limiting works in practice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('Info editor report messages'), which clearly states the tool's core function. The qualifier 'when exposed by Blender RNA' adds scope but is somewhat opaque. It is distinct enough from siblings like info-report, though it could differentiate more explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as info-report. There are no stated use cases, exclusions, or prerequisites, leaving the agent to infer when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It doesn't disclose effects (e.g., adds a new object to the scene, affect scene state), nor does it mention return values or side effects. The description is minimal, leaving behavioral details to schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no waste. It's concise but lacks detail; however, for a simple creation tool, this is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 0 required parameters, output schema absent, and low description coverage. It doesn't explain defaults (e.g., default location [0,0,0]) or how 'name' is used. For a creation tool, more context is needed: does it return a handle? Does it affect scene level? Contextual completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate, but it doesn't. It doesn't explain 'name' or 'location' beyond their titles. The schema itself is self-explanatory for these simple parameters, but description adds no value. With 0% coverage, score should be lower, but parameters are intuitive, so 3 is baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a lattice object' is clear: specific verb (Create) + resource (lattice object). It distinguishes from siblings like 'lattice-report' and 'lattice-set' but doesn't explicitly mention its relation to 'pointcloud-create' or other object creation tools. Still, it conveys the core purpose well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'object-create' or other geometry creation tools. It doesn't explain when a lattice is needed or how it differs from other object types. The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states 'List scene lights' without disclosing behavior such as read-only nature, return format, or potential side effects. A list operation is presumably safe, but nothing is stated to 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase 'List scene lights' with no wasted words. It is front-loaded and direct, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema, the description fails to explain what the tool returns (e.g., names, IDs, count). It also doesn't mention any context or usage notes. For a minimal tool, some indication of output structure is needed, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (vacuous). Since there are no parameters to document, the description adds no additional semantics, but the baseline of 3 applies due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List scene lights' clearly states the verb (list) and resource (scene lights), making the purpose unambiguous. However, it doesn't distinguish from the sibling tool 'light-report', which might also return light information, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or when to prefer other tools like 'light-report' or 'light-set'. The description provides no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the tool has side effects, requires specific object states, or what 'live' means (e.g., real-time updates). The verb 'report' suggests read-only, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point. It is brief but not overly vague, though it could be more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimal. However, it lacks details about what 'live RNA properties' includes (e.g., specific fields like location, rotation, scale) and how to interpret the report. The absence of any output schema makes this more pressing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'name' with a title 'Light probe object name', but no description. Because schema coverage is 0%, the description must compensate, but it only says 'for a light probe', which adds minimal meaning beyond the title. It does not clarify the format or expectations for the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool reports live RNA properties for a light probe, which clearly identifies the resource (light probe) and the action (report). However, it does not explicitly differentiate from sibling tools like 'lightprobe-set' or 'lightprobe-list', but the phrase 'live RNA properties' provides some specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'lightprobe-list' or 'lightprobe-report' (though 'lightprobe-report' itself is unique). The description implies it is for inspecting properties but does not specify scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't state that this is a destructive operation (merging vertices removes them), whether it affects the active object by default, or what happens to UVs, normals, or other vertex data. The description is too terse to convey the operational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets to the point. It's front-loaded with the action and resource. However, it's so brief that it sacrifices necessary detail, but for conciseness alone it earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mesh editing with a threshold parameter) and the lack of annotations and output schema, the description is incomplete. It doesn't explain the effect of the threshold, whether it operates on the active object, or any side effects. The sibling tools like mesh-merge and mesh-dissolve suggest a family of mesh operations, but this description doesn't position itself within that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'threshold' implicitly via 'merge distance threshold' in the schema, but the description itself doesn't explain the parameters. The schema provides titles and defaults, but the description adds no extra meaning beyond what the schema already shows. With 2 parameters and 0% coverage, a score of 3 is appropriate because the schema is fairly self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Merge duplicate vertices' clearly states the action (merge) and the resource (duplicate vertices), which is specific enough to distinguish it from sibling tools like mesh-merge, mesh-dissolve, and mesh-delete. It doesn't explicitly mention the mesh object context, but the tool name and schema parameter 'object' clarify that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like mesh-merge or mesh-dissolve. It doesn't mention prerequisites (e.g., being in edit mode, selecting vertices) or typical use cases. The threshold parameter is self-explanatory but no context is given for choosing appropriate values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explicitly marks the tool as 'read-only', which is a key safety trait, but does not describe output format, side effects, or any limitations. This is minimal but adequate for a simple report tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and safety trait. There is no wasted wording or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should clarify what the report contains and how to use it. It only states 'analytic topology report' without explaining what topology data is returned or how the object parameter works beyond the schema title. This leaves significant gaps for an agent trying to choose and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameter details. The input schema has a single optional 'object' parameter whose title ('Mesh object to inspect (defaults to active)') provides some meaning, but since schema description coverage is 0%, the description was expected to compensate and does not. The parameter is completely ignored.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a read-only report for mesh topology, which distinguishes it from sibling mesh mutation tools like mesh-fill or mesh-subdivide. It uses a specific verb ('report') and resource ('mesh') with a specific focus ('topology'), though it doesn't elaborate on what the report contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternative reporting tools (e.g., properties-report, mesh-selection_report) or mutation tools. It only states the default behavior of the object parameter but gives no context on preferred use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It only lists the four actions without disclosing scope (e.g., active object vs. all objects), mode requirements, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasteful words. It is front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool, the description is too sparse. It omits critical context such as requiring edit mode and how it determines the mesh object (though the schema notes 'defaults to active'). The schema's titles provide minimal help, and the description does not add the necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'action' or 'object' parameters at all. With 0% schema description coverage, the description fails to compensate, leaving the agent to rely solely on the minimal schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool selects, deselects, inverts, or toggles all mesh elements. It uses specific verbs and a clear resource ('all mesh elements'), distinguishing it from siblings like mesh-select_by_index, which selects by index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as mesh-select_by_index or context-select_all. It does not mention prerequisites like edit mode or when this is the preferred choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the move is destructive (e.g., does it reorder the stack? does it replace an existing modifier at the destination index?), whether it requires specific permissions, or what happens if the index is out of bounds. The description only states the action without any side effects or constraints, leaving the agent to guess.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence of six words. It is front-loaded with the action and object. However, it is perhaps too sparse, omitting necessary behavioral details, but for conciseness alone, it earns a high score because it wastes no words. The compactness is appropriate given the tool's narrow function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, no output schema), the description is incomplete. It does not explain the effect of the move on the modifier stack, potential errors, or default behavior of the 'object' parameter. It lacks critical context that would help an agent safely invoke the tool, such as what happens if the index is already occupied or out of range. The sibling tools like modifiers-set or modifiers-list provide more context, but this description alone is insufficient for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the schema's property titles are minimal ('Name of the modifier to move', 'Destination stack index'). The description does not add any additional semantic detail beyond what the schema provides. However, the parameter names and titles are relatively clear: 'name' is the modifier identifier, 'index' is the destination stack position, and 'object' defaults to the active object. The description adds no extra value, so it's baseline 3 for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Move a modifier to a stack index' clearly states the action (move) and the resource (modifier), and specifies the target (a stack index). It is distinct from siblings like modifiers-add, modifiers-remove, modifiers-set, modifiers-copy, and modifiers-apply, which handle other modifier operations. The verb 'move' and the resource 'modifier' are specific, though it doesn't explicitly mention which stack (e.g., object's modifier stack), but the context implies 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the modifier must exist, the stack index must be valid), nor does it contrast with other modifier operations like reordering via modifiers-set or copying. The agent must infer usage from the name and parameters, 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 provided, so the description must carry the full burden of behavioral disclosure. The description does not mention that this is a mutating operation, whether it requires specific permissions, or whether it can be undone. It also doesn't clarify the effects of setting delta values versus absolute values, or whether changing rotation_mode affects existing rotations. This is a significant gap for a tool that modifies object state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise at 6 words, which is appropriate for a tool with a clear purpose. It is front-loaded with the key action and resource. However, it is so brief that it misses opportunities to include important usage context, but it earns a 4 because it is not verbose and every word is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, including delta and absolute transform values, and a rotation_mode enum), the description is far too sparse. It lacks any explanation of how the parameters interact, prerequisites (e.g., an object must exist), or the effect of setting deltas versus absolute values. The output schema is absent, so the description could have clarified what the tool returns, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not. However, the input schema itself is quite informative: each parameter has a title that explains its purpose (e.g., 'Scale [x, y, z]', 'Euler rotation in radians'). The description adds no extra meaning beyond the schema, so the baseline is 3. The schema's titles effectively document the parameters, so the lack of description is partly offset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set an object's transform fields' clearly states the action (set) and the resource (an object's transform fields), distinguishing it from related tools like object-transform_apply and object-transform_get. It is specific enough for an agent to understand the tool's core function, even though it doesn't enumerate all the fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus the sibling tools (e.g., object-transform_apply, object-transform_get). The existence of these siblings implies a set vs. get vs. apply distinction, but the description does not clarify that this tool mutates the current transform state, while apply commits modifiers or that get retrieves values. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 does not clarify what 'move' does to the object's prior collection memberships, whether multiple source collections are allowed, what happens if the target collection does not exist, or any mutation side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the action and includes the key constraint in a compact, readable way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool, the description gives the core operation but is incomplete overall. With no annotations, no output schema, and zero parameter documentation, the agent is left without enough context to know identifier formats, prerequisites, or behavioral consequences of moving an object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It only restates 'object' and 'target collection' without explaining the expected format, identifier type, or constraints for these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Move an object to exactly one target collection.' It clearly states both the action and its destination, and the 'exactly one' constraint helps distinguish it from sibling tools like outliner-object_link and outliner-object_unlink.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of alternatives such as outliner-object_link, outliner-object_unlink, or outliner-parent_set. The phrase 'exactly one target collection' implies a constraint, but the description does not explain the intended context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action. It does not mention prerequisites, side effects, irreversibility, or what happens to the object's existing physics stack.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no filler or redundant content. It is short but not tautological.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only two parameters, the tool involves domain-specific concepts (RIGID_BODY, CLOTH, SOFT_BODY, etc.) and no output schema or annotations. The description does not explain how to identify the object, which physics types apply, or what the result of removal is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the parameter names. The 'type' enum values and 'object' identifier format are left entirely unexplained, so the agent must infer semantics from titles alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove'), a clear resource ('physics stack'), and a target ('an object'). It clearly distinguishes itself from sibling tools like physics-add, physics-set, and physics-report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as physics-add, physics-set, or constraints-remove. It simply states the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries all the burden. It only states 'Report' which implies a read operation but does not disclose side effects, permission requirements, or what 'live' means (e.g., dynamic updates, thread safety). It also omits any error conditions (e.g., invalid paths) or return semantics 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It is front-loaded with the core purpose, but it is perhaps too sparse to cover necessary details, though this is not a fluff issue—more under-specification. It earns a high score for having no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no output schema, and no annotations, the description is inadequate. It does not explain what 'live RNA properties' entails, what the output report contains, how the path parameter work with types (e.g., object vs data), or what the include_values updates. Missing crucial context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only indirectly mentions 'path' via 'target' but fails to explain the optional 'include_values' flag and its effect. The schema provides an example for path, but the description adds negligible value over the schema titles and does not address any parameters explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Report') and the resource ('all live RNA properties') for a defined target ('any stable Properties path target'). It distinguishes itself from siblings like properties-object_report (which is object-specific) and properties-get (which likely fetches individual properties), making its scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this versus alternatives (e.g., properties-get or specific object reports). While the description implies a comprehensive listing, it does not mention exclusions, prerequisites, or alternative tools for getting single properties or object-constrained reports.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 full behavioral disclosure. It only states 'Set', implying mutation, but does not explain whether all transforms must be provided together, whether partial updates are allowed, or what units are used (though schema titles hint at radians and world location). It also fails to mention error conditions or side effects beyond the mutation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose with no filler or redundancy. It is front-loaded and easy to scan, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, more context is needed. The description does not clarify whether the operation is idempotent, whether all three transform properties are required or optional, or how partial calls behave. It also fails to differentiate from similar sibling tools, leaving the agent with incomplete information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes descriptive titles for each property (e.g., 'World location [x, y, z]', 'Euler rotation in radians [x, y, z]') that already convey the meaning effectively. The description adds no additional semantic value beyond repeating the property names. Since the schema does the heavy lifting, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Set an object's location/rotation/scale'. It uses a specific verb and resource, making the purpose obvious. However, it does not distinguish itself from the sibling tool 'object-transform_set', which likely performs a similar transformative operation, so it loses a point for lack of differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like object-transform_set. The description does not mention any preconditions, common use cases, or exclusions. Users must infer from the name and schema 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, the description carries the full burden of disclosing behavior. 'Append' implies mutation, but the description does not state whether the operation requires an existing text block, what happens on failure, or whether it is destructive to existing content. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and directly states the core purpose. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the core action, but it lacks any context about prerequisites, return values, or interaction with sibling text tools. The absence of annotations and output schema makes this minimal description insufficient for an agent to invoke it correctly in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not mention the 'name' or 'body' parameters at all, leaving the agent to rely solely on the schema's minimal titles. No added semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Append') and the resource ('Text data-block body'), making it distinct from sibling tools like text-write or text-read. It is specific and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention text-write for overwriting or text-save for persistence, leaving the agent to infer appropriate usage.
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 information about side effects or lack thereof. Since it is a listing operation, it is presumably non-destructive, but this is not stated. No annotations compensate for this absence, leaving behavior opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the action. It contains no filler or redundant words, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about what the listing returns, such as the format or content of the list. Without an output schema, the agent is left without essential context about the expected result, which diminishes completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which establishes a baseline of 4. The description does not need to elaborate on parameter meanings, and no parameter information is expected or missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists Text data-blocks, using a specific verb and resource. It distinguishes from sibling tools like text-create or text-read, but does not explicitly mention scope such as 'all' or filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not indicate any specific scenarios or prerequisites, leaving the agent without direction on when listing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether the save overwrites existing files, what happens on failure, or any side effects. As a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy or unnecessary details. It efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation, the description omits important context like overwrite behavior, error handling, or whether it supports different file formats. The lack of annotations and minimal details make it incomplete for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides minimal descriptions for 'name' and 'path', and the tool description adds no extra meaning. It clarifies that path is optional and defaults to text.filepath, but does not explain how the path is used or if it can be a directory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action (save) and target (Text data-block) to disk, distinguishing it from other text-related tools. However, it lacks specificity about the destination or any options beyond the implicit path 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., text-write for writing content, or file save for whole scenes). The description does not mention typical use cases or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action but doesn't disclose side effects (e.g., whether it replaces an existing datablock with the same name, whether it loads into the current blend file, or if it requires specific permissions). The term 'load' implies a read operation, but the tool likely creates a new datablock, which is a mutation. This ambiguity is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action. It avoids fluff and is easy to parse. However, it could be slightly more informative without becoming verbose, so it doesn't earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and no annotations, the description is too sparse. It doesn't explain the return value (e.g., the created datablock name), error conditions (e.g., file not found), or how it integrates with the texture pipeline. Sibling tools like textures-list and textures-report exist, so the description should clarify how loading fits in. The description is minimally viable but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'image datablock' and 'disk' but doesn't explain the 'name' parameter's role (optional name for the datablock) or the 'path' format. The schema provides titles but no descriptions, so the tool description adds minimal value beyond the parameter names. Baseline 3 is appropriate because the description at least clarifies the purpose of the tool, but it doesn't detail parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Load an image datablock from disk' clearly states the action (load) and resource (image datablock) with a source (disk). It distinguishes from sibling tools like textures-list and textures-report, which are for listing/reporting, not loading. However, it doesn't explicitly mention that it creates a new datablock or how it relates to existing textures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., file format support, whether the path must be absolute), nor does it contrast with textures-list or textures-report. The agent must 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 must carry the burden of disclosing behavior. It only says 'Report', which implies a non-mutating read operation, but doesn't state whether it has side effects, what happens if no tool is active, or if it requires a specific context. It doesn't mention any limitations or edge cases, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets straight to the point. It is appropriately sized, though it could benefit from a bit more detail without becoming verbose. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no output schema), the description is minimal but incomplete. It doesn't explain what the report contains, the expected format, or how the parameters alter the output. There are many sibling tools related to tool management, but no contextual guidance to differentiate or provide usage context. Agents may not know what to expect from the invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no detail about the parameters. The schema provides titles for each parameter (e.g., 'Optional mode, e.g. OBJECT or EDIT_MESH'), which is some help, but the description doesn't explain how these parameters affect the report or what values are valid. With no required parameters and no enums, the description should clarify the meaning and default behavior, which it fails to do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Report' and the resource 'active workspace tool', clearly indicating it provides information about the current tool. It also specifies the context ('for an editor/mode'), which helps distinguish it from other reporting tools. However, it doesn't explicitly mention how it differs from similar tools like 'tool-set' or 'tool-settings'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying the active tool, but doesn't provide explicit guidance on when to use this vs. other tool-related commands. There is no mention of alternatives or scenarios where this should not be used. The optional parameters (mode, area_type) hint at querying in different contexts, but no specific examples are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Load' but does not mention side effects (e.g., replacing an existing clip), required permissions, error behavior for missing files, or whether the clip is added to the current scene. This is insufficient for an agent to anticipate outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no redundancy. It is front-loaded and to the point. It could arguably be too terse, but for such a simple tool it is appropriately concise, earning a high score without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but given no output schema and no annotations, the description should provide more context: where the clip is loaded (current scene? tracking data?), accepted formats, and any consequences. It only states the action and resource, leaving significant gaps for an agent to understand the full impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter clarity. It does not explain the 'name' parameter's purpose or provide context for 'path' beyond implying a file path. The schema only gives titles, which are minimal. The description fails to add meaningful parameter semantics beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Load') and the resource ('a movie clip or image sequence source'). It is specific and distinguishes from sibling tools like tracking-clips (which lists clips) and tracking-report (which provides status). The verb-noun pair 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as prerequisites (e.g., must have a tracking setup) or whether this is the first step in a tracking workflow. Sibling tools like tracking-marker_report and tracking-track_report imply different uses, but the description does not clarify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only states the action ('report') without clarifying whether it mutates state, requires specific prerequisites (like clip loaded), or what happens on errors. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is appropriately brief for a simple tool with one parameter, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a tool with no annotations and no output schema, the description is incomplete. It does not explain the content or format of the markers, any dependencies (e.g., clip must be loaded), or what the report includes. Given the tool's context (motion tracking), more details on scope and output would be necessary for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The input schema only provides a title 'MovieClip name' which gives a hint, but the description adds no extra explanation about the 'clip' parameter, its format, or its relationship to loaded clips. The description does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('report markers') and the scope ('for each track in a clip'). It distinguishes from sibling tools like tracking-track_report, which likely focuses on a single track, and tracking-report, which may report overall tracking data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus tracking-track_report or tracking-clip_load. The description implies it is for reporting markers per clip, but no alternative tools or conditional usage are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It implies a read-only report operation, but it does not explain what the returned report contains, whether the clip must be loaded, or what kinds of tracks are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, front-loaded with the action 'Report tracks' and immediately scoped to 'a clip'. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and a single but undocumented parameter, the six-word description is too sparse to give an agent enough confidence about expected result and behavior. It is minimally usable but leaves important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description is not compensated for explaining the parameter. It only restates the clip concept already represented in the schema; it does not describe how to format the clip name or how the clip parameter relates to track reporting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Report tracks') and scopes it to a clip, which distinguishes it from sibling tools like tracking-report or tracking-marker_report. The word 'report' is somewhat generic, but the clip scoping makes the intended purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a clip' implies this tool is for per-clip track reporting rather than general tracking reporting, but it does not explicitly state when to choose it over siblings or name any alternatives. Usage context is embedded but not directly detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it merely restates the tool name. It does not explain what 'empty volume' means, how the object is added to the scene, any selection behavior, or other side effects, providing minimal beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, making it concise. However, it under-specifies by essentially paraphrasing the tool name, and the brevity results in insufficient information for an agent to use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with two optional parameters and no output schema, the description states the core action but lacks usage context, parameter elaboration, and clarification of what 'empty' means in the context of the volume toolset. It is minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not mention the 'name' or 'location' parameters. The schema titles offer basic meaning, but the description fails to add any context about how these parameters affect the created volume, leaving the agent without crucial guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' and the resource 'empty volume object', clearly identifying the function. It distinguishes from sibling tools like volume-import (which imports data) and volume-set (which modifies existing volumes) by emphasizing 'empty'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as volume-import or volume-set. There is no mention of prerequisites, typical workflow, or cases where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 uses the word 'safe' which implies no side effects, but it does not explicitly state that it is read-only, does not mutate data, or what output format is returned. It also does not clarify what 'high-level' means operationally, leaving agents with incomplete expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with five words, which is very concise and front-loaded. It contains no fluff or repetition. However, its extreme brevity leaves key information about the exact scope of 'preferences' unstated, but as a concise statement it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description should at least clarify what preferences are included (e.g., themes, units, shortcuts) and what 'safe' means (e.g., read-only guarantee). The description is too vague for an agent to reliably know what to get or how to interpret results, especially given the large sibling toolset that may have overlapping functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there are no parameter semantics to clarify. The description's brevity is acceptable here because there are no inputs to document. Baseline 4 is appropriate given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and resource ('user preference values') with a qualifier ('safe high-level'), clearly indicating it's a read-only query for preferences. It distinguishes from the sibling 'app-preferences_save' which is clearly a write operation, though it doesn't name alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus others. The description implies it is for reading preferences, but it does not mention prerequisites, context, or alternatives. The sibling list includes save, but no mention of when to use this over other preference-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 must carry the safety and behavior information. The term 'report' suggests a non-mutating operation, but it does not explicitly state that no changes are made, nor does it mention permissions, rate limits, or error behaviors. For a tool with no annotations, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the core purpose without any fluff or redundant information. It is front-loaded and efficient, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, a required field, and an enum, yet the description gives no guidance on how to use them (e.g., default values, owner/bone dependencies). It also lacks any description of the return format or what 'live RNA properties' entails. With no output schema and sparse parameter explanation, the description is incomplete for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter-specific information, and schema coverage is 0%. The schema itself has descriptive titles (e.g., 'Pose bone name when owner is BONE'), but the description does not clarify interactions between parameters (e.g., that 'bone' is only relevant when owner is BONE) or provide usage examples. With 0% coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Report live RNA properties for object or pose-bone constraints' – a specific verb (report), resource (RNA properties), and scope (constraints). It distinguishes from siblings like constraints-list (listing) and constraints-set (modifying), though not explicitly naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this is for reporting properties on constraints, implying a read-only inspection use case. However, it does not explicitly state when to use this versus constraints-list or constraints-set, nor when not to use it. The intended usage is inferable but not directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses useful behavior: it renders exactly one view and produces a PNG visible to the agent. However, with no annotations provided, it does not mention that rendering is non-destructive, how the PNG is returned, or performance/side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It earns its place by stating the core operation and output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no annotations, no output schema, and closely related sibling tools like feedback-capture_views and render-still, one sentence is under-specified. It lacks alternative selection guidance, output return details, and parameter clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only partially does so for 'view' via 'named or the live scene camera', which overlaps with the schema title, and says nothing about res, object, or shading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Render'), the object ('one view'), and the output ('to a PNG the agent can see'). It is specific enough to convey the tool's function, though it does not explicitly name sibling tools like feedback-capture_views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as feedback-capture_views, render-still, or ui-screenshot. There are no exclusions or 'when-to-use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Return' implies a read-only operation, and 'paginated' hints at limit/offset behavior. However, it does not disclose what happens on invalid input (e.g., unknown object or component), whether errors are raised, or the exact structure of the returned rows. It 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence with no filler. Every word contributes to the core meaning, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and low parameter coverage, the description is insufficiently complete. It fails to explain what the returned rows contain, how the 'object' default behaves, or the implications of the 'component' choices. A user would need to guess or invoke the tool to learn its behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints at parameter meaning via 'object geometry attributes' (which relates to 'component') and 'paginated' (which relates to limit/offset), but does not explicitly explain any of the four parameters. The description adds minimal value beyond the parameter titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and resource ('spreadsheet rows'), and adds specificity with 'paginated' and 'derived from object geometry attributes'. It distinguishes itself from sibling tools like spreadsheet-columns and spreadsheet-report by focusing on rows with geometry-derived data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not explain typical use cases (e.g., inspecting vertex data) or mention any exclusion conditions. Without this, an agent may not know when to call spreadsheet-rows over spreadsheet-report or spreadsheet-columns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does disclose that dispatch is 'undo-safe' and that controlled editor area context is used. However, it does not explain what side effects arbitrary operators may have, how failures are surfaced, or what 'undo-safe' practically means for the calling agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words: 'Run any Blender operator' is the core action, followed by two meaningful qualifiers. It is appropriately concise despite the complexity of the underlying tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a broad, multiparameter tool with no annotations, no enums, and no output schema, yet the description does not mention return values, error behaviors, operator availability, or how arguments should be structured. It gives a viable starting point but is too incomplete for safe and confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only implies the area/region/window-related parameters. The meanings, formatting, and interaction of parameters like pathetic mode, select, object, or args are not explained beyond their schema titles, so the description adds very little semantic value for a 10-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run any Blender operator' with a specific execution approach ('explicit editor area context and undo-safe dispatch'). It distinguishes this as a generic operator execution tool, though it does not explicitly differentiate it from sibling tools like ui-operator_poll or rna-call_operator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no preconditions, no when-not-to-use cases, and no mention of how 'any Blender operator' should be selected or validated. The phrase implies broad usage, but actionable selection criteria are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and condition, but fails to mention what happens if the API is unavailable, potential side effects, required permissions, or error handling. For a screenshot tool, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extra words. It is front-loaded with the action and condition, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description provides only the basic action and a condition. It lacks usage guidance, behavioral details, and differentiation from similar screenshot tools, making it incomplete for an agent to decide when to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. Although the input schema provides titles for both parameters (full and path), the schema description coverage is 0%, and the description adds no additional meaning beyond what the titles already imply. It does not compensate for the lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it captures Blender's UI screenshot with a specific condition (when screen.screenshot is available). The verb and resource are specific, but it doesn't explicitly distinguish from similar tools like feedback-capture or ui-redraw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage condition ('when screen.screenshot is available'), giving some context. However, it doesn't mention when to use this tool over alternatives or any exclusions, leaving the agent to infer 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the operation type (insert) without revealing whether existing keyframes are overwritten, how defaults like current frame/active object are handled, or any side effects on the animation data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It conveys the core action efficiently and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is too sparse. It omits critical context such as valid data_path formats, index semantics, and how defaults are applied, leaving the agent to infer too much from the schema titles alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about any of the 4 parameters. Schema description coverage is 0%, and while the schema titles provide some hints (e.g., 'defaults to current scene frame'), the description does not compensate for the low coverage or clarify parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Insert a keyframe') and the target resource ('object property at a frame'), distinguishing it from sibling tools like anim-delete_keyframe and anim-set_interpolation. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or related tools that might be more appropriate for different animation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It states the direct effect (sets the current scene frame), which is appropriate for a simple setter. However, it does not disclose potential clamping behavior, range constraints, or whether playback state is affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core action with no filler. It is appropriately front-loaded and effectively scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-param action, the description is minimally adequate. It could still be more complete by mentioning usage context, likely range rules, or clarifying that it does not insert/remove keyframes. Nonetheless, the operation is trivial enough that the description is not severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate for parameter meaning. It does not explain the 'frame' parameter beyond the schema's own property title. The description adds no additional detail about frame values, intervals, or special cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and clearly identifies the resource ('current scene frame/playhead'). It is distinct from siblings like anim-set_timeline and anim-insert_keyframe, though it does not explicitly mention those distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternative animation tools, no context about prerequisites, and no exclusion statements. The sibling tools include similarly named setters, so this gap matters.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. The word 'live' hints at real-time data, but nothing is said about pagination, matching semantics, or potential side effects (if any). The information is minimal and does not go beyond the basic verb and resource.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It directly states the purpose and is appropriately sized for a simple search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description lacks essential context such as return format, behavioral constraints, or any limitations. With no annotations and no output schema, the description alone is insufficient for an agent to fully anticipate the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It adds no context about the limit or query parameters beyond the schema's titles, providing no additional value over the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Search' and the resource 'live Blender API operators and RNA types', which distinguishes it from siblings like rna-search or rna-describe. It is specific and unambiguous regarding its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like rna-search or capabilities-search. There are no exclusions, prerequisites, or preferred contexts mentioned, 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral transparency burden. The verb 'Describe' implies a read-only operation with no side effects, and the tool name reinforces this. However, the description does not state what 'describe' returns or whether any state changes occur, leaving some 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no filler or redundant information. It is front-loaded with the key verb and resource, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter describe tool with an enum constraint, the description is minimally adequate. However, with no output schema and no annotations, the description does not clarify what a 'profile' contains or what the user should expect in the response, leaving the tool somewhat underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no property descriptions, giving 0% schema description coverage, and the description does not explain the `asset_class` parameter or its possible values. The enum values are somewhat self-explanatory, but the description adds no semantics beyond the schema's field name and allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Describe') and the resource ('one Layer 2 game-asset class profile'), which distinguishes it from the sibling tool `asset_class-list` that presumably lists multiple classes. The 'Layer 2' qualifier adds some domain-specific context, though it is not fully explained, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. The sibling `asset_class-list` could be the correct tool for enumerating classes versus describing one class, but the description does not mention this or any other when/when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It states the end state but omits side effects, validation behavior, failure modes, or whether the camera must already exist in the scene.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but without annotations or an output schema, the description lacks workflow context such as whether the camera must already exist, how the active scene is determined, and how this relates to camera-create or camera-report.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the property name 'camera' and the schema title 'Camera object name'. It does not clarify accepted formats, how to obtain the camera name, or behavior for invalid names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and names the exact resource ('the active scene camera'), distinguishing it from sibling tools like camera-set and camera-create. The action 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of camera-set, camera-create, camera-report, or camera-list. No prerequisites, exclusions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 the action (remove) without mentioning potential side effects, reversibility, error handling, or the distinction between OBJECT and BONE owners. This is minimal and does not clarify what happens in different scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It is appropriately sized for a simple removal tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is incomplete. It does not explain when to use 'bone' versus 'object' (or how owner affects behavior), what happens if the constraint does not exist, or any prerequisites. With no output schema and no annotations, this leaves significant gaps for an agent to execute correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the four parameters: object, name, owner, or bone. Schema description coverage is 0%, and while titles exist (e.g., 'Pose bone name when owner is BONE'), the description adds no clarity. The term 'named' hints at the 'name' parameter but does not describe how to use it or the role of owner/bone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a named object or pose-bone constraint' clearly states the verb (remove) and the resource (constraint) with specific scope (object or pose-bone). It effectively distinguishes from sibling tools like constraints-add, constraints-list, and constraints-set, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for both object and bone constraints, but does not explicitly state when to use this tool over alternatives such as constraints-set (for modifications) or rig-constraint_remove (which may be another removal path). No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'One observe call' implying a read-only operation, but it doesn't explicitly state that it doesn't modify the scene, what the report contains beyond 'mesh/UV', or any side effects. It also doesn't clarify whether it requires a specific context (e.g., active object). The description adds some context (bundled report) but is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the core purpose. It uses compact phrasing like 'the anti-blob' in the schema title, but the description itself is efficient. It doesn't waste words, though it could be slightly more structured with a second sentence for usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what the report contains, how the parameters affect the output, or what the agent should do with the results. The sibling tools like feedback-quality and feedback-topology suggest a family of feedback tools, but this description doesn't clarify how this one fits. It's a single sentence that leaves many gaps for a tool that bundles multiple outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multi-angle images' and 'mesh/UV report' but doesn't explain the parameters (res, object, preset, shading) beyond what the schema titles provide. The schema already has titles and enums, but the description doesn't add meaning like how 'preset' affects the images or what 'object' selection means. It's a baseline 3 because the schema has some self-documenting elements (titles, enums), but the description doesn't add significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'One observe call to judge a model' with 'multi-angle images + mesh/UV report bundled'. It specifies the verb (judge) and resource (model), and the bundled report distinguishes it from other feedback tools like feedback-quality or feedback-topology. However, it doesn't explicitly name sibling alternatives, so it doesn't fully differentiate from all feedback-* 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for judging a model via multi-angle images and a mesh/UV report, but it doesn't provide explicit when-to-use or when-not-to-use guidance. It doesn't mention alternatives like feedback-quality or feedback-topology, nor does it state prerequisites (e.g., object must be selected). The context is clear but lacks exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it does not export, but fails to say whether validation is read-only, what outcomes are produced, or whether any state changes occur. This leaves the safety and side-effect profile ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff or repetition. Every word contributes to conveying the primary purpose and key differentiator.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a complex 9-parameter schema, no annotations, and no output schema, this one-line description is insufficient. It omits behavioral details, parameter guidance, validation outcome semantics, and error conditions, making it inadequate for an agent to confidently select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds no meaning to any of the 9 parameters, failing to explain 'object', 'profile', or the 'CUSTOM override' parameters. The schema titles provide the only hints, but the description itself contributes nothing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Validate'), the target ('an object against a parameterized export profile'), and the critical scoping ('without exporting'). It effectively distinguishes this from sibling io-export/io-import tools by emphasizing the no-export behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies a pre-export validation use case via 'without exporting', but does not explicitly state when to use this tool over io-export or other alternatives. There are no exclusions or named alternative tools, though the context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. 'List' implies a read-only operation, but the description does not state what is returned (e.g., names, full object data, counts) or any side effects. It adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words, with no filler. It front-loads the action and object. While it could add a bit more detail, it avoids any verbosity and is appropriately sized for a trivial zero-param list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description is minimally viable but leaves gaps. It does not clarify what distinguishes 'list' from 'report', nor what shape the returned list takes. Given the simplicity, this is acceptable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter explanation is needed. The baseline for 0-param tools is 4, and the description adequately reflects that there are no inputs to configure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List light probe objects' uses a specific verb 'List' and a clear resource, distinguishing it from sibling tools like lightprobe-create, lightprobe-report, and lightprobe-set. It is slightly less distinct from lightprobe-report, which may also enumerate information, but the intent is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as lightprobe-report or lightprobe-set. No context, prerequisites, or exclusions are given, leaving the agent to guess which listing tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. 'Copy a modifier in the stack' implies duplication, but it does not explain whether the copy is added immediately below the original, whether it inherits all settings, what naming conventions apply, or whether any context like active object matters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to the core action, which is appropriate for a simple mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no annotations, and no output schema, the description is under-specified. It lacks behavioral expectations, default naming behavior, stack placement, or any note about how the result is reflected. It is minimally viable for identifying the action but not complete for an AI agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level meaning beyond the input schema. The schema titles already indicate that 'name' identifies the modifier, 'object' defaults to the active owner, and 'new_name' renames the copy. Since schema description coverage is 0%, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('copy') and resource ('a modifier in the stack'), making the tool's function immediately clear. It also differentiates from sibling tools such as modifiers-add, modifiers-move, and modifiers-remove, since copying is a distinct operation on an existing modifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus related tools like modifiers-add, modifiers-move, or modifiers-apply. There is no mention of prerequisites, selection requirements, or situations where copying is preferred over other 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?
No annotations are present, so the description carries the full burden. It only says 'Report' without explicitly stating it is read-only, what data it returns, or whether it has side effects. The minimal phrasing does not disclose behavioral traits beyond the dictionary definition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancy, front-loaded with the action. It is about as brief as possible while conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description does not cover expected return format, scope of force field settings, or any edge cases. It is minimally sufficient but inadequate for an agent to fully understand the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single 'object' parameter with title 'Object to inspect', but the description adds no extra meaning. Schema description coverage is 0%, so the description fails to explain the parameter type, format, or relationship to the report. The title is helpful but the description offers nothing additional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Report') and the target ('an object's force field settings'), which is specific and distinguishes it from sibling tools like physics-report (broader physics report) and physics-field_set (setter).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention when to use it (e.g., to inspect before setting) or when not to use it, leaving context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 says 'report', implying a read-only operation, but does not disclose edge cases, failure conditions, return format, or whether any side effects occur. The absence of such detail makes behavior unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundancy. It is perfectly front-loaded and concise, satisfying the requirement for efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a report tool with no output schema and no annotations, the description is too terse. It omits what 'physics stacks' entail, what the report includes, and how to interpret results. Given the suite's many report tools, this lacks essential context for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the lone parameter 'object'. It adds no extra meaning beyond the parameter name, failing to specify expected format, required object type, or examples, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'report' and resource 'physics stacks' on an object, distinguishing it from sibling mutation tools like physics-add, physics-remove, and physics-set. It also differs from physics-field_report, which targets fields specifically, making the purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like physics-field_report or constraints-report. It lacks any mention of prerequisites, exclusions, or specific scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, error behavior, or state changes. It only states the action without explaining what happens on failure, whether the modification is reversible, or if it triggers recalculations. This lack of transparency makes it hard 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It directly conveys the action and target, making it efficient and easy to parse. No filler or ambiguity in length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple setter, and the description covers the core action, but it omits details about return values (though no output schema exists) and error conditions. It doesn't clarify if the 'physics stack' must already exist or if the property path is validated. Given the simplicity, a score of 3 is balanced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides titles for all four parameters ('type', 'value', 'object', 'property'), covering the essentials. The description adds no extra meaning beyond the generic 'set one RNA property', but the parameter names and enum values (e.g., RIGID_BODY, CLOTH) are self-explanatory, so coverage is high. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'one RNA property on a physics stack', which properly conveys the tool's function. It distinguishes from physics-report (read) and physics-add/remove (structural changes), though it doesn't explicitly differentiate from physics-field_set, which could be ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention contexts where physics-set is appropriate or list exclusions (e.g., 'use for property modifications, not for creating or deleting physics entities'). This leaves the agent without direction on selection 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.
- 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 only states that it sets a property, but does not mention side effects, error behavior, or the fact that the value is a JSON-encoded string, which is critical for correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant wording. It is front-loaded with the action and resource, maximizing clarity for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a setter with three parameters and no output schema, the description omits essential details such as the JSON value format, potential error responses, and what happens if the property is not writable. It is insufficient for an agent to use reliably without additional external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides basic titles but no enums, and the description adds no further meaning about property naming conventions or how the JSON value is parsed. With 0% schema description coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'set' and resource 'point cloud data-block', clearly distinguishing it from sibling tools like pointcloud-list and pointcloud-report. It precisely states the action and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like rna-set_property or pointcloud-report. The description lacks context about prerequisites, exclusions, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. The word 'report' suggests a read-only operation, but it does not explicitly state non-destructiveness, permissions, or what happens if invalid parameters are given. Minimal transparency 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It efficiently states the purpose without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain what the report returns or the format. It only says 'transforms and constraints' without specifying scope (e.g., all bones or selected ones) or return structure. Incomplete for a tool with no structural guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention 'bone' or 'armature' at all, leaving the schema titles as the only guidance. No added meaning, so it fails to help the agent understand parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports pose bone transforms and constraints. It distinguishes itself from siblings like rig-report (generic) and rig-constraints (constraints only) by specifying 'pose bone' scope and both transforms and constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using this tool to inspect pose bone data but does not explicitly state when to use it over alternatives like rig-report or rig-constraints. No exclusions or alternative guidance is provided, so it's adequate but lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Report' implicitly suggests a read-only operation, but it does not disclose any safety guarantees, potential side effects, or error conditions (e.g., what happens if the armature does not exist). The description is too minimal to inform the agent about behavioral expectations 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. Every word contributes to the purpose, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks critical context: there is no output schema, no mention of the return structure (e.g., whether it returns a list, formatted text, or data), and no prerequisites (e.g., needing an active armature). While it lists the content categories, it omits enough details to fully prepare an agent for invocation and interpretation of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description gives no explanation of the 'armature' parameter. It only states it is an armature object to inspect, but does not clarify expected format (e.g., name, path, type) or any constraints. The description fails to 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies exactly what the tool reports: rest bones, pose bones, constraints, and child meshes. It clearly distinguishes itself from siblings like rig-list_bones (which likely only lists bones) and rig-pose_report (pose-specific). The verb 'report' and resource 'armature' (implied by parameter) make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a comprehensive rig report, but it does not explicitly state when to use this tool versus more focused alternatives like rig-list_bones or rig-pose_report. No exclusions or alternative recommendations are provided, leaving the agent to infer relative utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "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, but it only states the action without explaining side effects, coordinate system, or that it modifies the armature in edit mode. It does not mention what happens if the bone doesn't exist or how the change affects children or rest pose, leaving significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It clearly communicates the essential purpose and action without any redundant words, making it highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and the complexity of editing armature bones, the description is too sparse. It omits critical context such as coordinate systems, whether it operates in edit mode, the impact on the rig, and how it relates to other rig tools. This leaves the agent with insufficient information to invoke the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it adds no detail beyond the schema's titles (which already say 'New bone head position [x, y, z]'). It does clarify that 'head and/or tail' are optional, but that's already implied by the schema's optional fields. No coordinate space or format details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) on a specific resource (existing bone) and the object of change (head and/or tail position). It distinguishes from sibling tools like rig-add_bone (which adds bones) and rig-set_pose_bone (which likely sets pose transforms) by focusing on the edit-mode head/tail of an existing bone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as rig-set_pose_bone or object-transform_set. The description gives no context about prerequisites (e.g., being in edit mode) or exclusions, so an agent must infer usage solely from the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It mentions it sets location, rotation, and/or scale, but does not disclose whether it overwrites existing values, whether rotation_mode defaults to XYZ, or any side effects on the bone's transform. It is not misleading, but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient. It front-loads the core purpose without fluff, though it could be slightly more structured by listing the parameters in detail, but as is, it is appropriately sized for its limited content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, 2 required, and no output schema. The description only covers the three optional transform arrays, leaving the required parameters (armature, bone) and the rotation_mode parameter undocumented in the description. Given the moderate complexity and lack of annotations, a more comprehensive description is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description only lists the three main properties (location, rotation, scale) but does not mention the required parameters (armature, bone) or the rotation_mode parameter with its default and enum values. The schema titles provide some context, but the description adds little beyond what a user could infer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a pose bone's location, rotation, and scale, using a specific verb ('Set') and resource ('pose bone'). It distinguishes from siblings like rig-set_bone_transform (which likely sets overall bone transform) by focusing on pose bones, though it doesn't explicitly contrast with that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for editing a pose bone's properties but does not specify when to use this over alternatives like rig-set_bone_transform or rig-add_bone. It lacks context about prerequisites (e.g., armature must exist, bone must be a pose bone) and does not mention that rotation_mode is optional with a default.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Report sequence strips', which implies a read-only operation but does not explicitly state it, nor does it mention any side effects, output format, or limitations. This is minimal and leaves behavioral expectations unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancy or extraneous content. It is appropriately front-loaded and easy to parse, achieving maximum conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is the only source of behavioral context. It fails to specify what the report contains (e.g., names, properties), how results are returned, or any prerequisites. For a simple tool, the description might be minimally adequate, but it lacks sufficient detail to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so according to the rubric, the baseline score is 4. There is no parameter information to add beyond what the empty schema shows, and the description does not need to compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports sequence strips in the active scene, using a specific verb ('Report') and resource ('sequence strips in the active scene'). It distinguishes itself from other report tools (e.g., particles-report, physics-report) by targeting the sequencer context, though it lacks details on the nature of the report (e.g., list, summary).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions 'active scene' but offers no context on prerequisites, typical use cases, or exclusions. Users must infer that it's for inspecting sequencer strips without any additional 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?
Since no annotations are provided, the description must disclose behavioral traits. It only states the operation ('Set') without conveying side effects, reversibility, required permissions, or response behavior. This is inadequate for a mutation tool, as the agent cannot 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence with no redundant words. It is effectively front-loaded and directly states the core action, earning points for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that sets an RNA property, the description lacks essential context: what properties are available, constraints on values, or any relation to reading properties (e.g., sequencer-report). It leaves the agent with insufficient information to use the tool effectively, especially given the absence of an output schema or annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fails to explain the meaning or relationship of the parameters (name, property, value). The schema titles provide minimal hints, but the description does not compensate by describing how these parameters interact or how to format the JSON value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the resource (one RNA property on a sequence strip), which is specific and distinguishes it from sibling tools like sequencer-strip_add and sequencer-strip_remove. It also implies a single property, adding precision to 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is provided about when to use this tool versus alternatives such as rna-set_property or other sequencer tools. It does not mention prerequisites, limitations, or scenarios where other tools would be more appropriate, leaving the agent without guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without disclosing side effects, such as whether the material must exist, if the node is added to a specific location in the tree, or any error behavior. The description is too brief to inform the agent about safety or mutation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is 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 essential operation without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description is too sparse. It doesn't explain the required bl_idname format, how the material is referenced, or any constraints, making it difficult for the agent to invoke correctly without further info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% because the description mentions none of the parameters. The schema provides some titles and an example for 'type', but the description adds no additional meaning or clarification, 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a shader node to a material node tree.' It uses a specific verb (add) and resource (shader node) with context, distinguishing it from related tools like shading-add_image_texture and shading-link_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the description but not explicit. It doesn't mention when to use this tool vs alternatives like shading-add_image_texture or shading-set_principled, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects and return behavior. It only states the reporting scope; it does not explicitly confirm read-only behavior, describe the output format, or note what happens when object/material are empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single 11-word sentence, front-loaded with the verb and resources. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what a report contains and how it is returned. It also lacks parameter usage details and any context about active selection vs. named material, leaving the tool under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only titles and 0% description coverage, so the description should clarify how object and material interact. It mentions the resources but does not explain defaults, whether both are required, or how omitted values are resolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Report' and names the three resources: a material, object material slots, and the shader node tree. This distinguishes it from sibling tools like shading-list_materials, which presumably only lists materials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose shading-report over shading-list_materials, shading-set_principled, or properties-report. There are no usage conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only says 'Set...' without disclosing whether parameters are partially updated, what happens if the material lacks a Principled BSDF node, or how the target material is resolved from the object/material fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no redundant words or filler. It is appropriately concise for the stated purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has seven optional parameters, no output schema, and no annotations. The description leaves material resolution, partial-update behavior, and failure modes implicit, so it is not complete enough for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and seven optional parameters, the description should compensate by explaining parameter semantics or target resolution. It only labels the parameters as 'Principled BSDF parameters', relying entirely on the input schema's titles for meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and names a specific resource ('Principled BSDF parameters on a material'), making its function clear. It is differentiated from sibling tools like shading-set_node_input and shading-create_material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as an existing Principled BSDF node or material, nor does it exclude cases where shading-set_node_input would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. 'List image datablocks' reveals only the core action and does not mention output format, scope, or that it is a read-only enumeration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the verb and object. It is immediately scannable and appropriately sized for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the returned list contains and its scope. The three-word phrase gives insufficient context for an agent to know whether to expect names, IDs, or additional metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty input schema is fully covered and there is no parameter semantics burden on the description. The baseline for 0 parameters is 4, and this description does not need to add parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a clear resource 'image datablocks', making the tool's basic purpose evident. It loosely differentiates from siblings like textures-load and textures-report, though it does not explicitly scope the listing or distinguish from the report tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as textures-report. The description implies a listing operation but does not state context, exclusions, or alternative tool choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 explaining behavior. It states the overwriting nature of the action, but does not disclose whether the text data-block must already exist, whether replacement is irreversible, what happens to other text block properties, or what the result of the operation is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It immediately conveys the core action and target resource, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating operation with no annotations, output schema, or parameter descriptions, the one-sentence description is insufficient. It does not explain preconditions, side effects, or error conditions, leaving important operational context unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds little beyond the schema titles. While 'name' and 'body' are reasonably clear from their titles, the description does not clarify allowed formats, behavior for missing blocks, or how body replacement differs from appending.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Replace a Text data-block body' uses a specific verb and resource, clearly indicating the tool overwrites the body of a text data-block. This semantically distinguishes it from sibling tools like text-append, text-read, or text-save, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as text-append or text-save. The intended use is only implied by the word 'Replace' and the parameter names, with no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a key behavior—the search does not open a modal UI—and implies read-only search. However, it does not state what is returned, whether operators are executed, or how matching 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, front-loaded sentence with no filler words. It states the resource (bpy.ops commands) and the key behavioral qualifier in under a dozen words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter search tool, the description is minimally adequate but incomplete: no annotations, no output schema, and no mention of return values or query semantics. It answers what the tool searches, but little about how to use it or what results look like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description adds no parameter-level meaning. The schema titles ('Maximum results to return' and 'Command search query') give some context, but the description neither compensates nor clarifies query syntax, matching behavior, or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a search operation over Blender's bpy.ops commands and adds a distinctive qualifier ('without opening modal UI'). It does not explicitly name alternatives such as api-search or rna-search, so it misses the top end of sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this search versus sibling tools like rna-search, api-search, or capabilities-search, and no exclusion criteria. The 'without opening modal UI' phrase implies it is a non-invoking search, but that is not an explicit when-to-use instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 alone must disclose behavioral traits, but it only says 'Report MovieClip and tracking state' without details about read-only behavior, output format, or scope. While report implies a read operation, the description does not mention return structure, possible side effects, or prerequisites, so transparency is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no redundant elements. Every word contributes to stating the tool's core function, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has no parameters and appears simple, the description does not explain what the report contains, what 'MovieClip' or 'tracking state' include, or how this report differs from the many related tracking report tools. Without an output schema, the description also leaves the return value unspecified, making its present information incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the schema description coverage is 100%, so the baseline is 4. The description adds no parameter-specific details, but none are needed because the tool takes no arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Report MovieClip and tracking state' uses the specific verb 'Report' along with a resource ('MovieClip and tracking state'), clearly indicating the tool's intent. It is distinguishable from similar siblings like tracking-marker_report and tracking-track_report by mentioning 'MovieClip,' though it doesn't explicitly spell out how it differs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as tracking-track_report, tracking-marker_report, or tracking-clip_load. There are no 'when to use' or 'when not to use' instructions, leaving the agent to infer appropriate usage from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the deletion action but does not mention that the operation is destructive/permanent, what happens if the named layer does not exist, or how it interacts with the active UV layer 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It immediately communicates the action, target, and selection criterion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema or annotations, the description is too sparse. It fails to explain the optional 'object' parameter, default target behavior, or error cases, leaving an agent inadequately informed to use the tool correctly in anything beyond the default case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only restates the name parameter via 'by name' and provides no explanation of the optional 'object' parameter or its default behavior. The description adds essentially no meaning beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and names the exact resource ('a UV layer') with the selection method ('by name'). It clearly distinguishes this tool from siblings like uv-layer_create and uv-layer_set_active by indicating it is the deletion operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the action and resource, but the description provides no explicit guidance on when to choose this over alternatives, no prerequisites (e.g., the layer must already exist), and no caveats such as consequences of deleting the active UV layer.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 the active UV layer' without detailing side effects, failure behavior, or requirements. This is minimal transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It is appropriately concise 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description lacks critical context for an AI agent: no mention of error handling, behavior when the layer doesn't exist, effect on the active object, or return values. The description leaves significant gaps for a mutation tool in a UV context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, but it only references 'name' without elaborating on its format or constraints. The optional 'object' parameter is not mentioned, and the description adds no meaning beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set the active UV layer by name' with a specific verb and resource. It distinguishes from siblings like uv-layer_create (creates a new layer) and uv-layer_delete (removes a layer), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is given. The description does not mention when to use this tool over alternatives, prerequisites (e.g., layer must exist), or any conditions. The agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies mutation of UV islands but does not clarify side effects (e.g., modification of existing UVs, scaling or moving islands), selection requirements, or reversibility. This is a significant gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff. It is front-loaded and appropriately sized for the operation, delivering the core purpose instantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutability and lack of annotations or output schema, the description is under-specified. It omits preconditions (e.g., selected object), detailed parameter behavior, and any note about how the packing affects existing UV islands, making it incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (the tool description mentions neither parameter). The schema itself provides titles for 'margin' and 'object', but the description adds no semantic value or usage hints, leaving the agent to infer parameter roles solely from the schema's brief titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Pack), the resource (UV islands), and the target outcome (fit the [0,1] UV space). It is specific and distinguishes this tool from UV unwrapping or scaling tools like uv-unwrap, uv-smart_unwrap, and uv-average_islands_scale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, with no mention of prerequisites, typical scenarios, or why an agent might prefer packing over other UV 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 carries the full burden of behavioral disclosure. It only says 'Import an OpenVDB volume file'—it doesn't explain whether this creates a new object, overwrites existing data, requires certain permissions, or what happens on failure. The sparse description fails to illuminate side effects or post-conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It efficiently communicates the core purpose without redundancy, earning high marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description should explain the resulting state or relation to other volume tools (e.g., whether it creates a volume object that can be listed by 'volume-list'). It only states the action, omitting crucial context about the import's effects, making it incomplete for an LLM agent to safely invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not elaborate on the 'name' or 'path' parameters beyond what is obvious from their titles. For a simple import, the path is self-explanatory, but the description adds no extra value to parameter understanding, leaving the agent to infer usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action 'Import an OpenVDB volume file', which clearly distinguishes this tool from siblings like 'volume-create_empty' and 'io-import'. The verb 'import' and the resource 'OpenVDB volume file' are precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives (e.g., when creating an empty volume vs importing a file). There is no mention of prerequisites, exclusions, or alternative tools, so the agent is left without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that it lists objects and data-blocks but does not clarify whether this is a read-only operation, what data is returned, or whether it has any side effects. It implies a non-destructive action but fails to explicitly state that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that exactly conveys the tool's purpose without any extraneous words. It is front-loaded and efficient, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description is minimal but lacks context about what 'volume objects and data-blocks' means in the broader domain. It does not clarify the return format or how this list might be used, which could leave an agent uncertain about the output's nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this, so the description need not explain parameter semantics. The baseline for 0 params is 4, and the description accurately reflects the parameterless nature. No additional parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List volume objects and data-blocks' clearly identifies the action (list) and the resource (volume objects and data-blocks), and it is specific enough to distinguish from sibling tools like volume-create_empty and volume-import. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or when a user might prefer volume-report or volume-set instead. There is no context about listing vs. reporting volume data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose that this is a write operation affecting the scene's timeline. It only says 'set' without mentioning side effects or whether it modifies the scene 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, one sentence, with no redundant words. It clearly conveys the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with four straightforward parameters, the description is minimally adequate. It lacks usage context and edge cases, but the core purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond the schema property titles. It lists parameter names but provides no explanation of units, constraints, or how they interact. Since schema descriptions are absent, this is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets scene timeline range, current frame, and frame rate. It distinguishes from similar tools like anim-set_frame (which only sets current frame) and anim-set_interpolation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It does not explain when to use this tool versus alternatives, such as when to set the timeline range vs. only setting a single frame. No context 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.
- 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 that it runs redo but does not explain side effects, such as what happens if there is nothing to redo, whether it is reversible, or how it affects the session state. The description is too minimal to be transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It front-loads the key information and is appropriately sized for a parameterless action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is minimal but adequate. However, it lacks context about what 'redo' means in Blender (e.g., redoes the last undone operation) and does not specify any limitations. This is a gap that could confuse an agent unfamiliar with the domain, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. Since there is nothing to describe, the description adds no parameter information but also does not need to. The baseline for zero parameters is 4, and the description does not conflict with this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run Blender redo for the active session' clearly identifies the action (redo) and context (Blender, active session), distinguishing it from siblings like app-undo. It is not a tautology and conveys the resource and operation effectively, though the verb 'run' is generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like app-undo. The description does not mention that redo should follow an undo, nor does it specify any conditions or prerequisites. Usage context is only implied by the name 'redo'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It only states the action 'enable or disable' without disclosing any side effects, such as whether disabling nodes affects rendering output, or whether it requires a specific selection or mode. The behavior is plain but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, immediate and precise, with no redundant words. It is highly efficient and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a very simple tool (one boolean parameter), the description is minimally adequate, but it lacks crucial context such as whether this affects the entire compositor or just selected nodes, and whether it has effects on rendering. The absence of an output schema and annotations makes the incomplete description more noticeable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single boolean parameter 'enable' with a title, but the description does not explicitly connect this parameter to the operation. It implies toggling but never mentions the parameter name or its role, failing to add beyond the schema's limited title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (enable or disable) and the resource (scene compositor nodes), and it is distinct from sibling tools like compositor-add_node or compositor-link, which handle different aspects of compositor operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. It does not specify when to use this tool versus alternatives, such as whether it applies to the active scene or globally, or under what circumstances one would enable or disable compositor nodes.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 disclosure burden. The verb 'report' implies a read-only inspection, but the description does not explain what information is returned, any side effects (or lack thereof), or error behavior. It offers only minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one short, focused phrase. It is front-loaded and free of waste. For a zero-parameter tool, this level of conciseness is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a trivial no-parameter report tool, but it is minimal. There is no output schema and no annotation, and the description does not state what the report contains or how the result will be presented, leaving some ambiguity about tool expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so no parameter-specific documentation is required. Per the rubric, zero parameters gets a baseline of 4, and the description does not need to explain any parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Report scene compositor node tree' gives a clear verb and resource, specifying exactly what is reported. It distinguishes the tool from compositor mutation siblings like compositor-add_node and compositor-link, though it does not clarify the exact form or content of the report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other report tools or compositor operations. The read-only nature is implied by the verb 'Report' and contrasted with compositor mutation tools, but no explicit usage context or exclusion is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the score is order-free (order-independent) and deduped, and that it does not use a judge or images, which are useful behavioral traits. Still, it lacks details such as side effects (likely none), behavior with defaults, error conditions, or the exact output structure beyond 'fraction.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that packs in key qualifiers without fluff. It is front-loaded with the core purpose and includes qualifiers but omits details that are better conveyed elsewhere. Slightly above average because it uses space effectively, though a tad cryptic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has two optional parameters and no output schema, the description provides a foundational idea (readiness fraction) but does not specify what the actual returned value looks like (e.g., a number, a list of gate statuses). It also doesn't explain 'order-free' or 'deduped' icons in the context, leaving some ambiguity about the exact scoring mechanics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description gives no guidance on the two parameters ('object' and 'asset_class'). Schema coverage is 0%, and while the schema includes titles like 'Mesh object to score (defaults to active)', it does not explain how these inputs affect the scoring or how to choose asset_class values, leaving the agent without crucial semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the tool as a 'scorecard' that reports the fraction of all objective gates passed, with qualifiers 'order-free + deduped' and 'no judge, no images' that distinguish it from visual feedback tools. It uses a specific noun ('scorecard') and describes the resource type, but lacks an explicit action verb like 'compute' or 'report'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers implied guidance: it is the 'objective' scorecard without judge or images, suggesting it should be used for automated readiness checks. However, it does not explicitly name alternative tools (e.g., feedback-capture, feedback-lookdev) or state when not to use it, leaving some ambiguity about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions it produces a 'flat silhouette' and 'proportion/symmetry' feedback, but does not disclose important behaviors such as whether the tool modifies the scene, renders images, or requires specific object selection. For a feedback tool, it's unclear if it returns analysis data or captures images. This is a significant gap for an evaluation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, one sentence. It front-loads the key concept (flat silhouette) and adds a memorable tagline ('the form eye'). No wasted words, but the tagline adds little functional value. It is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 3 parameters with zero schema description coverage and no output schema. The description gives no details on return values, parameter behavior, or workflow nuances. For a feedback tool that likely outputs evaluation results, the description is incomplete. The tool appears related to many feedback siblings, and no distinctions or operational details are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, the description does not mention parameters at all. The input schema includes 'res' (resolution), 'object', and 'preset' (with enums), but none of these are explained in the description. The preset enum has a useful title, but description adds no meaning beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating a flat silhouette from preset angles and analyzing proportion/symmetry. It also distinguishes it from siblings like feedback-quality, feedback-topology, and other feedback tools by describing itself as 'the form eye.' This provides a specific verb+resource+scope, differentiating it from the broader feedback family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage context (form evaluation via silhouettes) but does not explicitly state when to use this tool versus alternatives like feedback-quality or feedback-orientation. No explicit exclusions or alternative mentions are present. The phrase 'the form eye' hints at a specific use case, but guidelines are not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 mentions the use of Blender's default node group but does not disclose side effects, error behavior, prerequisites, or how it interacts with existing modifiers. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's purpose. It contains no fluff or redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the core action but lacks context about prerequisites, error conditions, or relationship to existing modifiers. It is minimally viable but leaves gaps in operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter details. It does not explain the meaning or behavior of 'name' or 'object' beyond what their titles suggest. The agent must rely solely on property names and schema titles, with no elaboration from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Create a Geometry Nodes modifier') and distinguishes it from generic modifier tools like modifiers-add and node tools like geometry_nodes-add_node. It clearly states what the tool does with a specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding a Geometry Nodes modifier with the default node group, but provides no explicit when-to-use vs alternatives or exclusions. There is no mention of alternatives or conditions for use, making it only implicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It correctly identifies this as a destructive operation by mentioning the force requirement, but it doesn't elaborate on other behaviors like whether the operation is reversible, whether child collections are recursively deleted, or if there are safety checks beyond the force flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that conveys the core purpose and a key constraint. It's front-loaded with the action and includes the most important usage detail. No fluff, though it could be slightly longer to cover more behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter delete tool with no output schema. The description covers the main purpose and the only key caveat (force requirement). However, given the destructive nature, it could add more context about irreversible changes or what happens to child elements, and it lacks any exclusions or conditions for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It only explains the 'force' parameter's purpose indirectly by stating it's required for non-empty collections, but it doesn't explain what 'collection' means or provide format details. The schema titles give some info ('Allow deleting a non-empty collection' and 'Collection to delete'), but the description adds minimal extra value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete a collection' with a specific resource (collection), and the force requirement adds important scope. It's distinguishable from sibling tools like outliner-collection_rename and outliner-object_unlink, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by explaining when force is required (when the collection contains objects or child collections), which guides the agent on when to use this tool and what parameters to set. However, it doesn't explicitly state when NOT to use it or mention alternatives like clearing the collection first or using outliner-orphans_purge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description implies a read-only operation (listing) but does not explicitly state that it has no side effects or is safe. No additional 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no unnecessary words. It is appropriately concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is brief but leaves ambiguity about 'high-value Outliner categories'. It could be more complete by specifying what categories are considered high-value, but it is not severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema covers everything. However, the description could clarify what 'high-value' means or what categories are included, but since there are no parameters, this is not a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (zero-user datablocks), but 'high-value Outliner categories' is vague and could be more specific. It distinguishes from sibling tools like outliner-tree or outliner-find.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or any prerequisites. The description does not mention any context or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the safety burden. It does disclose that force is always required, signaling a deliberate confirmation guard before purging. However, it does not state that the purge is destructive, irreversible, or what happens if force is false, leaving important behavioral consequences implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the verb, resource, and critical guardrail are all in twelve words. No filler exists, though the force clause could be more explicit. It earns a high conciseness score despite being sparse on broader context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive mutation tool with no annotations and no output schema, the description is too thin. It omits when to use the tool, what counts as an orphan, whether the action is reversible, and what the result will be. The presence of sibling tools like outliner-orphans makes the missing 'preview first' guidance especially noticeable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lone 'force' parameter. It adds that force is always required, which is useful, but it does not clarify that force must be set to true, and it conflicts with the schema marking force as optional with default false. This ambiguity makes the parameter semantics under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Purge') and resource ('orphan datablocks'), clearly indicating a destructive cleanup operation. The semicolon clause about force reinforces the operation's intent without confusing the purpose. It is also distinct from sibling tools like outliner-orphans, which likely only lists/reports orphans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as outliner-orphans or other outliner tools. It does not mention that orphans should be reviewed first, nor does it explain the appropriate cleanup workflow. The only usage hint is the force requirement, which is a precondition rather than contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It mentions the action (set restrictions) but does not disclose effects on referencing scenes, whether changes propagate to linked duplicates, or if there are side effects on dependencies. Lacks transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that accurately summarizes the tool's function. It is not padded with unnecessary details. However, it could benefit from a bit more context, which might be added without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (4 boolean parameters) and no output schema, the description is adequate for basic usage. However, the lack of annotations and absence of usage guidance reduce completeness. For a tool that modifies object state, more behavioral and contextual information would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. However, the parameter titles (Renderable, Visible in viewport, Selectable) are self-explanatory. The description adds no extra meaning beyond the schema. Since parameters are simple booleans, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to set object-level visibility and selection restrictions (viewport, render, selectable). While it doesn't explicitly differentiate from siblings, the name and description make it distinct from collection-level or view layer tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to adjust visibility for a specific object rather than a collection or view layer. However, it doesn't explicitly state when not to use it or mention alternatives like outliner-collection_visibility_set. 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool removes a particle system, which implies destructiveness, but it does not explicitly warn about irreversible side effects, potential errors (e.g., if the name does not exist), or any permissions required. No mention of what happens to the object or other particle systems. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words. It is front-loaded with the key action and resource, and every word carries meaning. For a simple operation like this, the brevity is appropriate and achieves maximum efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a mutation tool with no annotations and no output schema. It does not explain error handling, prerequisites, or consequences of removal. While the operation is conceptually simple, the agent lacks information about whether the removal is permanent, whether it can fail due to missing objects or names, or what the response will be. This under-specification could lead to incorrect invocation or unexpected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description must clarify parameters. It mentions 'named' (corresponding to the name parameter) and 'from an object' (corresponding to the object parameter), which adds some context beyond the schema titles. However, it does not provide syntax examples, constraints, or clarify that the name must match an existing particle system. The bare titles 'Particle system name' and 'Object to edit' already convey the basic meaning, so the description adds only marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove), the resource (named particle system), and the target (from an object). It distinguishes itself from sibling tools like particles-add (add) and particles-set (modify) by specifying that it removes an existing named particle system. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives. It does not mention scenarios for removal, prerequisites (e.g., the particle system must exist), or exclusions. Sibling tools like particles-set or particles-report are not referenced, so the agent has no explicit context for selecting this tool. The intended usage is only implied by the verb 'remove'.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 must make behavioral traits clear. It only says 'List particle systems on an object,' which implies a read operation but does not disclose what the response contains (e.g., names only, full properties, empty result behavior) or how an invalid object is handled. For a simple read tool this is minimal, but the burden is high without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is fully front-loaded and contains no irrelevant information. It states the operation and the target in one breath, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description alone must explain the tool's function and expected return value. While 'List particle systems on an object' conveys the essence and is probably enough for a simple list, it leaves out what is actually returned (system IDs? names?) and does not address edge cases like objects with no particle systems. It is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% because the 'object' parameter has no attached description beyond its title. The tool description reuses 'object' but does not clarify the accepted format (e.g., name, UUID, path) or whether it must be an active/selected object. The description adds almost no meaning beyond the schema's bare parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List particle systems on an object' uses a specific verb ('List') and a specific resource ('particle systems'), with clear scope ('on an object'). This clearly distinguishes the tool from mutation-oriented particle tools like particles-add/remove/set, and from report-style tools like particles-report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention how it relates to particles-report or particles-list, nor does it indicate any prerequisites (e.g., object selection) or when it would be preferable to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only listing operation but does not explicitly state that it makes no changes, nor does it describe output format, pagination, or any side effects. The phrase 'list' suggests non-destructive behavior, but lacks detail on what exactly is returned (e.g., names, IDs, properties) or whether it lists everything from all scenes or just the active one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. It is front-loaded with the verb and resource, and every word contributes meaning. There is no excessive detail or ambiguity in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is adequate but minimal. It does not explain the scope of the listing (e.g., current scene, all scenes) or the format of the returned data. Given the low complexity, it's a minimum viable description, but the lack of context about scope and output limits its completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100% (trivially). According to guidelines, a baseline of 4 is appropriate for 0 parameters. The description adds minimal semantics by specifying that the output includes 'objects and data-blocks', which clarifies the two categories being listed, but does not provide additional context beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing point cloud objects and data-blocks. It uses a specific verb ('List') and identifies the resource, distinguishing it from sibling tools like pointcloud-report (which likely provides detailed reports) and pointcloud-set (which modifies properties). However, it could be more explicit about the scope (e.g., all point clouds vs. current scene) and doesn't mention filtering or sorting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this tool is for enumerating point clouds while pointcloud-report might give more detail, or that pointcloud-set is for modifications. No context about prerequisites or typical use cases is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses only that files are listed; it does not state whether this is a safe read-only operation, how project detection works, whether files are scanned from disk, or what format/sorting the response will use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single declarative sentence that front-loads the action and scope with no filler or redundancy. For a parameterless list tool, this is appropriately sized and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a short description, the agent knows what to call and why, but not what exactly counts as 'files' or what the returned list contains. This is a minimum-viable definition, not a rich one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema covers 100% of them, so the description does not need to add parameter semantics. Per the rubric, a zero-parameter tool gets a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') and resource ('files') with a concrete scope ('active or detected Blender project'). It distinguishes the tool's intent among siblings like project-report or outliner-tree, though it does not explicitly name alternatives or define what qualifies as a 'file'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, exclusion criteria, or mention of alternatives. The scope 'active or detected' implies context, but the description never tells an agent when to prefer project-files over project-report, project-settings, or outliner-tree.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects and behavior. The word 'Report' implies a read-only action, but the description does not explicitly state whether calling it modifies state, what 'detected' means, or whether the tool can be expensive or dependent on the current scene 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler or repetition. It is front-loaded and efficiently communicates the tool's scope in just a few words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and minimal structure, so the description is the only source of information. It identifies two report categories ('Blender project state' and 'project editor areas') but does not specify exactly what information is returned, how the state is presented, or what 'active or detected' means, leaving a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, so there are no parameter details to cover. The baseline for zero-parameter tools is 4, and the description at least clarifies what the tool reports even though it does not need to describe individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and names the resources ('Blender project state' and 'project editor areas'). It is clear enough, but does not sharply distinguish itself from sibling project-related report tools such as project-files, project-settings, or 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It states the general purpose but does not mention exclusions, priorities, or relationships to sibling tools, so an agent gets no help choosing between project-report and similar report/context tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'sets' a property, implying a mutating operation, and mentions JSON-encoding of the value, which is useful. However, it omits critical behavioral details: whether setting is idempotent, whether it can fail on invalid paths, whether it requires pre-existing properties, or any side effects on dependent systems. The description is honest but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and a key constraint. Zero filler, no redundancy. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no annotations and minimal schema descriptions, the description should do more. It doesn't explain what a 'stable Properties path' is, how it differs from a non-stable one, what happens when the property doesn't exist, or whether the value must match a specific schema. With no output schema or annotation support, the agent may be left guessing about error handling and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with titles ('Path to property', 'Value to set'), but descriptions are minimal. The tool description adds only that value is JSON-encoded, which is valuable. The path parameter's semantics ('stable', 'mutable RNA or custom property') are partially described in the schema title but not elaborated. The description does not compensate for the 0% schema description coverage, but the schema itself is self-explanatory for a simple setter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set a stable Properties path; value is JSON-encoded' clearly identifies the action (set) and resource (a stable Properties path), with an important qualifier ('stable') that distinguishes it from generic set operations. While it doesn't name sibling tools explicitly, the focus on 'Properties path' makes the target resource unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like properties-report or properties-object_report. The phrase 'stable Properties path' hints at a specific use case, but it doesn't explain what 'stable' means or when a user should choose this over other property-related tools. The agent is left to infer usage from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure, but it does not mention side effects (e.g., modifies the mesh), constraints (e.g., mode behavior REPLACE/ADD/SUBTRACT), error handling, or prerequisites. The mode parameter is not explained, and there is no indication of whether weights are added or replaced by default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant or extraneous wording. It directly states the action, target, and method, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and omits critical context: it does not mention prerequisites (e.g., the vertex group must exist on the mesh), what the tool returns (if anything), or how it relates to other rigging operations. Without this, an agent may not know if the tool is appropriate for a given scenario or what side effects to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides titles like 'Mesh object to edit', 'Blender vertex group assignment mode', 'Vertex group name', 'Weight to assign', and 'Comma-separated vertex indices'. These are reasonably descriptive but lack details (e.g., enum values for mode, weight range). The description does not add any extra meaning beyond the titles, so it does not elevate clarity beyond the schema's basic coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Assign vertex weights to a named vertex group by vertex index' uses a specific verb ('assign') and clearly identifies the resource (vertex weights in a named vertex group) and the targeting method (by vertex index). It distinguishes from sibling tools like rig-set_bone_transform (bone transforms) and rig-parent_with_auto_weights (automatic parenting), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention when manual weight assignment is appropriate instead of automatic methods, or any prerequisites (e.g., vertex group must exist). Lacks explicit when/when-not 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, the description carries the full burden of behavioral disclosure. It mentions a trust condition but does not explain what reloading entails, side effects, or whether it re-executes or re-imports scripts. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundant wording. It is appropriately compact for a tool with no parameters and a simple action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The operation is simple and parameterless, but the description leaves ambiguity about what exactly is reloaded and the relationship to other script tools. It includes a useful trust prerequisite but is otherwise minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so there are no parameter semantics to explain. The absence of parameter information is acceptable, and no additional detail is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action verb ('reload') with a clear resource ('Blender scripts') and adds a condition ('when Python execution is trusted'). It distinguishes itself from sibling tools like script-run_file, though 'Blender scripts' remains somewhat broad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite ('when Python execution is trusted') but gives no explicit guidance on when to use this tool versus alternatives such as script-run_file or script-report. It does not state when not to use it or what scenarios call for reloading.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 explaining behavior. It only says 'Report' and lists content categories, without disclosing whether the tool is strictly read-only, what output format to expect, or whether it may be expensive or limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundant wording. Each listed item adds concrete scope information, making it an efficient representation of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter report tool, the description provides the primary content areas but omits return format, read-only guarantees, or any behavioral caveats. Since there is no output schema and no annotations, this is a minimum-viable description rather than a fully complete one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters and 100% vacuous schema coverage, so parameter-level explanation is not needed. The description adds scope detail about the reported areas, which is appropriate but not a substitute for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Report' with explicit target resources ('script-space operators, preferences, paths, and editor areas'), making the action and scope clear. It does not fully define 'script-space' or explicitly contrast with narrower sibling tools like script-paths, so it falls just short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of sibling tools such as script-paths, script-run_file, or other domain reports. There are no stated exclusions, prerequisites, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits itself. It only mentions the default label behavior and that it is an undo step, but fails to mention potential side effects (e.g., permanent loss of changes since the checkpoint), required prerequisites (e.g., existence of a checkpoint), or failure behavior. This is insufficient transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the core action, followed by a parenthetical for the default and a summary of behavior. Every word adds value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional parameters and no output schema. The description gives the essential function and default behavior, but lacks context on prerequisites (e.g., needing a checkpoint), failure cases, and whether it affects only the specified object or the active one. Adequate for basic use, but not fully complete given the lack of annotations and schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It explains the 'label' parameter's default ('most recent if no label') but does not explain the 'object' parameter's default (which the schema title says is 'active'). It also does not clarify what
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Restore' with a clear resource 'object from a checkpoint', and it also mentions default behavior ('most recent if no label') and that it acts as 'one undo step'. This clearly distinguishes it from siblings like session-checkpoint (which creates checkpoints) and app-undo (which undoes the last 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor any sibling tools like session-checkpoint or app-undo. The phrase 'one undo step' hints at a relationship to undo, but there is no clear context or direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It only states the add operation and does not disclose stack insertion order, duplicate handling, type constraints, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that states the action and target without unnecessary words. It earns its place and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the base purpose and the schema defines the parameters, but with no annotations, no output schema, and weak parameter semantics, the agent is left inferring important behavioral details. It is minimally viable but not fully contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not elaborate on the 'object', 'type', or 'name' parameters. It only places the operation in context without explaining effect type selection or object identification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Add a shader effect to a Grease Pencil object's stack.' This clearly distinguishes the operation from shaderfx-set, shaderfx-remove, and shaderfx-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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as shaderfx-set or shaderfx-types, and no exclusions or prerequisites are mentioned. The usage context is only implied by the verb 'add'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral expectations. It states 'report' implicitly suggesting a read-only operation, but does not explicitly confirm safety, side effects, or output format. This lack of explicit transparency about potential side effects or return structure is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It efficiently communicates the tool's scope without fluff, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple report tool with no parameters and no output schema, the description sufficiently captures the essential context (what is reported). It could be more detailed about the exact contents of the report, but given the simplicity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is trivially complete. The description does not need to explain parameters, and it adds no additional meaning beyond the empty schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reports active topbar context, workspace, scene, and search capability, making its primary purpose evident. It distinguishes itself from related tools like 'topbar-command_search' by focusing on overall context rather than a specific command 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternative report tools (e.g., 'scene-info' or 'ui-state'). The description implies it is for retrieving topbar state, but lacks direct comparison or situational advice, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It does not state that the operation modifies and likely overwrites existing UV coordinates, whether it requires a specific edit mode, or whether the change is reversible. This is a significant omission for a mutating UV operator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler. It immediately states the operation and target and earns every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema tool, the description plus schema title provides the minimum viable understanding: selected faces, UV map, sphere projection, and the optional object override. However, it misses side effects, mode requirements, and operational context, so it remains only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description does not explain the optional "object" parameter. The schema title says "Mesh object to project (defaults to active)", which helps, but the description itself adds no parameter semantics or clarification beyond the schema field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ("Sphere-project") plus a target ("selected faces") and recipient ("UV map"), clearly identifying the operation. It also distinguishes this tool from sibling projection and unwrap tools such as uv-cube_project or uv-smart_unwrap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that selected faces are the input but gives no guidance about when to use sphere projection versus alternative UV mapping methods, required modes, or selection prerequisites. It does not name alternatives or provide when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 only states the action, failing to mention what happens if the keyframe doesn't exist, whether deletion is irreversible, or any error conditions. This is insufficient transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 11 words, front-loading the verb and using no filler. Every word is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no annotations or output schema, the description is minimal. It lacks guidance on edge cases, prerequisites, or return values, making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It does not mention any parameters; however, the schema's parameter titles provide some guidance (e.g., 'Property path, e.g. location'), so a small amount of meaning exists. Still, the description adds no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and clearly identifies the resource as 'a keyframe on an object property at a frame', effectively distinguishing it from sibling tools like anim-insert_keyframe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (deleting keyframes) but does not explicitly state when to use it over alternatives or mention any exclusions. No comparison with sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, reversibility, idempotency, or whether the module must currently be enabled. This leaves the agent without insight into the tool's operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that is front-loaded and contains no filler or redundant content. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and a single parameter, the description is too minimal. It does not explain what happens after disabling, whether the module must exist, or how to discover candidate module ids. The sibling tool app-addons might be relevant but is not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'module' parameter with title 'Add-on module id', and the description adds almost no meaning beyond that. It says 'installed' but does not explain how to obtain valid module ids, expected format, or relationship to listed add-ons. With 0% schema description coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Disable') with a clear resource ('installed Blender add-on module'), making the tool's function immediately obvious. It also distinguishes itself from the sibling tool app-addon_enable by explicitly stating the disabling action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the name and description: use this when you need to disable a Blender add-on. However, it provides no explicit guidance on prerequisites, when to prefer this over other tools, or how to locate the correct module id before disabling.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 disclosure burden, but it only says 'Run Blender undo', which is essentially the operation itself. It does not mention what happens if there is nothing to undo, whether the undo affects saved files, or how it interacts with the undo stack.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to conveying the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument, no-output tool, the description is mostly sufficient: it identifies the action and scope. However, adding a phrase about whether the action is limited to the current undo history or how it interacts with 'app-redo' would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the schema openly defines an empty object, so there is no parameter semantics burden for the description. The baseline of 4 applies because no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action, 'Run Blender undo', and scopes it to 'the active session', making the purpose unambiguous. It effectively distinguishes itself from the 'app-redo' sibling tool by naming the undo operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as 'app-redo' or session-revert. The description only states what the tool does, without any contextual preconditions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavior. It does not mention side effects (though none expected), output format, or whether it is read-only. The description is minimal and lacks explicit transparency about what the listing entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the necessary information without any superfluous words. It is well-structured and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple list operation, but it does not clarify the output format (e.g., names, IDs, active camera indicator). Without an output schema, this information would be helpful. However, the core functionality is conveyed adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is effectively 100%. The description adds no extra meaning beyond the schema, but since no parameters exist, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List') and resource ('scene cameras and active camera'), making its purpose immediately understandable. It distinguishes well from siblings like camera-create or camera-set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as camera-report or camera-set_active. There is no mention of context, prerequisites, or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It states the tool 'reports' information, implying a read-only operation, but does not explicitly confirm the absence of side effects or modifications. It also omits details about permissions, error handling, or whether the report is a summary or detailed output. This lack of transparency could lead to assumptions about safety or capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently enumerates the reported items. It avoids redundancy and extraneous details, maintaining a clean and focused structure. This exemplary conciseness ensures clarity without sacrificing necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters, no output schema), the description is largely complete in listing the content of the report. However, it does not specify the format or structure of the report, nor clarify the meaning of 'available areas' (e.g., screen areas, workspace areas). While not critical, addressing these ambiguities would enhance completeness for a user unfamiliar with the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema accurately reflects this with 100% coverage. The description does not need to explain any inputs, and the absence of parameters is clear from the schema. Since there are no parameters to misinterpret, the semantics are straightforward and complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports active object, selected objects, mode, mesh select mode, and available areas. This is specific and distinguishes it from sibling context tools, though it could be more explicit about the output format. Overall, the purpose is evident and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other context-related tools like context-areas or context-set_active. It lacks any indication of appropriate use cases, prerequisites, or alternatives. Users must infer its role from the name and listing of reported items, which is insufficient for clear 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 must disclose side effects or requirements. It only says 'Switch Blender interaction mode' and 'optionally activating an object first', but omits details like whether the mode switch fails if no object is active, or how the select parameter influences behavior. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the primary action and a key optionality. No wasted words or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters (including an optional object and a boolean select), a straightforward purpose, and no output schema or annotations, the description leaves significant gaps—particularly around the select parameter's function and any prerequisites or side effects. It is complete enough for a simple mode switch but not fully helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It only glosses over the 'object' parameter via 'optionally activating an object first' and does not mention the 'select' parameter at all. The mode enum is self-explanatory but no additional meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: switching Blender's interaction mode, and mention of optionally activating an object first differentiates it from sibling tools like context-set_active or context-select_objects. It is specific with a verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It hints at usage by noting the optional object activation, but does not explicitly contrast with other context tools or state when to prefer this over alternatives. There is no clear when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 (convert non-mesh to mesh) but does not disclose side effects: what happens to the original object when keep_original=false (likely deleted or replaced), whether the conversion is destructive, any prerequisites (e.g., object must be convertible), or performance implications. The description lacks this essential context for a potentially destructive mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core purpose. It is efficient with no wasted words. However, it may be slightly under-specified given the missing behavioral and parameter details, but as a concise purpose statement it earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, one required, no annotations, and no output schema, the description is incomplete. It does not explain conversion limitations (which geometry types are supported), the effect of keep_original (whether the original is deleted or preserved), or the return value (success message or new mesh name). For a tool that is likely destructive and has multiple options, the description lacks critical operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. However, the description adds no parameter information. The schema shows three parameters: name, object (required), keep_original. The description's mention of 'non-mesh geometry object' somewhat clarifies the purpose of the object parameter but provides no guidance on name (optional converted mesh name) or keep_original (keep source object and create a copy). Since parameter info is entirely absent in the description, and schema coverage is 0%, a 3 is generous but reflects that the object parameter's role is implied by the description, and the other two are self-explanatory from their titles/defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Convert a non-mesh geometry object to a mesh' uses a specific verb (convert), a clear resource (non-mesh geometry object), and states the intended result (to a mesh). It distinguishes from siblings like geometry-create_curve or geometry-report by focusing on conversion to mesh, and complements the geometry_node tools which modify meshes via nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when a non-mesh geometry needs to become a mesh. But it does not explicitly state when not to use (e.g., not for mesh conversion of already-mesh objects, or alternatives like modifiers or geometry nodes). The context of Blender's geometry domain is implied but not elaborated. A 3 is appropriate as it provides clear context but lacks explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, required permissions, or whether existing node connections are affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or redundancy. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema, and the description provides only a minimal high-level action. It does not cover practical context such as how the node type is specified, how the modifier is resolved, or what happens if certain parameters are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level explanation. Schema description coverage is 0%, and while the schema titles are somewhat helpful, the description does not compensate by clarifying parameter usage, default behavior, or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('add') and resource ('a node') with the target context ('Geometry Nodes modifier group'), clearly distinguishing it from sibling tools like shading-add_node or geometry_nodes-link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding nodes to geometry node groups, but it does not explicitly state when to use this tool over alternatives, nor does it mention prerequisites like the existence of a modifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects. It only says 'import' but does not mention whether it replaces the current scene, adds objects, or any other behavioral implications. This leaves the agent uncertain 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that captures the core functionality without redundancy. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward import tool with only two parameters and no output schema, the description is adequate but could benefit from a note on typical behavior (e.g., adding to current scene vs. replacing). It doesn't cause confusion but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by explaining that format is inferred from the extension when AUTO is used, which is not obvious from the schema alone. However, it does not elaborate on the path parameter or the specific format implications beyond the enum list already present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (Import) and resource (mesh/scene file), with a specific detail about format inference. This distinguishes it from io-export which is the obvious counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Does not specify when to use this tool versus alternatives like io-export or asset preparation. It implies import, but offers no guidance on when it is appropriate or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden. It states 'apply transforms' and 'export', but does not disclose that the tool writes or overwrites an output file, whether the object is permanently modified, or how formats are handled. This leaves important side effects unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded, and free of waste. It efficiently conveys the main action without filler, which is appropriate for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, no output schema, and 0% schema description coverage, the description is under-specified. It does not explain formats, path, y_up, or how transforms interplay with the export. The description provides insufficient context for a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only loosely relates to 'apply_transforms'. It omits the meanings of fundamental parameters such as object, path, format, y_up, and apply_modifiers, leaving a material gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation: optionally apply transforms to one object, then export that object. The phrase 'just that object' differentiates it from broader sibling tools like io-export, and the intent is specific and understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case, exporting a single object after transforms, but provides no explicit when-to-use guidance or exclusion relative to sibling tools. It doesn't name io-export as an alternative for whole-scene exports, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavior. It states the operation (set a coordinate) but does not reveal whether it mutates the lattice in place, requires a specific mode or selection, affects the deformed object, or has side effects. This leaves 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no unnecessary words. It communicates the core purpose efficiently and does not waste space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too minimal. It does not explain how to specify the lattice object, what the deformed coordinate represents, whether the lattice must be selected, or what happens after setting. It lacks essential context that an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only paraphrases the 'co_deform' parameter ('deformed coordinate') and vaguely refers to 'one lattice point', but does not clarify what 'index' means beyond the schema title, nor what format 'object' should take. The parameter titles already provide this minimal meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set one lattice point's deformed coordinate' uses a specific verb (Set) and resource (lattice point's deformed coordinate), clearly distinguishing it from the sibling 'lattice-set' (which likely sets lattice-wide properties) and 'lattice-report'. It precisely conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage to modify a specific lattice point's coordinate, but provides no explicit context about when to use it versus alternatives like lattice-set or lattice-report. It does not mention exclusions, prerequisites, or selection requirements, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does reveal that omitting the parameter reports all scene lights, which is a key behavior. However, it does not explicitly state that this is a read-only or non-destructive operation, nor does it describe any side effects or output format, leaving a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. Both clauses are essential: the primary action and the default behavior. It is front-loaded with the action verb and maintains clarity, making it perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description is adequate but not complete. It conveys the core functionality but omits details about what 'report' returns, how errors are handled, or whether it works only on selected lights. Given the presence of many sibling report tools, a bit more context would help, so a 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'light' is only defined by its title and default in the schema, with 0% coverage from the description. The description adds meaning by explaining that omission triggers reporting all lights, which goes beyond the schema. However, it does not explain the valid values or behavior for invalid names, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Report' and the resource 'light(s)', and specifies the scope: one light or all if omitted. It distinguishes implicitly from lighting creation/modification tools but does not explicitly differentiate from similar report tools like light-list or particles-report, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like light-list or other report tools. The description only explains the parameter behavior, not the context or exclusions, so it fails to help the agent choose correctly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose that the tool modifies the mesh, nor any side effects, permissions, or irreversible changes. With no annotations, it carries the full burden, but it only states the action without behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information, perfectly sized for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a straightforward mesh operation, mentioning 'selected faces' as context. However, it does not mention any return values or prerequisites beyond selection, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides titles and defaults for both parameters, so the description adds no extra meaning. Since schema coverage is high, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Inset the selected faces', which is specific and distinguishes it from sibling tools like extrude 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like extrude or bevel. Lacks context about prerequisites (e.g., must be in edit mode) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says it bakes maps but does not mention side effects (e.g., overwriting existing maps, modifying target materials, creating new images), performance implications, or error conditions. It lacks transparency about what happens during the bake or what the tool modifies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the operation and output. It contains no redundant words or fluff and is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema, no annotations), the description is too sparse. It does not mention prerequisites like target UVs, the requirement of a source with high detail, what happens to existing maps, or whether the tool generates new images or modifies in-place. The tool likely has significant side effects, but the description does not cover them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters; schema description coverage is 0%. The schema titles are informative (e.g., 'Comma-separated maps to bake', 'Cage extrusion / ray distance'), so the schema carries the burden. Since the description adds no value beyond the schema and does not compensate for the low coverage, a score of 2 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: baking normal/AO maps from a high-poly source to a low-poly target. It specifies the verb (bake), the resources (source and target meshes), and the output (maps). It is distinct from sibling tools like object-transform_set or object-duplicate, and no other tool in the list appears to perform texture baking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (high->low detail baking) but does not explicitly state when to use it versus alternatives or what prerequisites are needed (e.g., target must have UVs, which is in the schema title but not the description). It also doesn't mention when not to use it or any caveats like requiring a cage or ray distance setup. There is no exclusion or alternative 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 the behavioral burden. It discloses the main side effect (creating hulls), the spatial scope (object bounds), and the naming behavior (Asset_COL_##), but it does not mention whether existing hulls are replaced, whether the source object must be selected, or what scene-level changes occur beyond creating named objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every phrase adds content: creation, collision hulls, split-box method, object bounds, and naming convention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, yet the description does not explain the resulting scene state, how the generated axes/count map to hulls, or how this tool relates to the nearby collision_proxy_create sibling. It is sufficient for recognizing the tool but not for invoking it with confidence in all parameter combinations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining parameters. It only loosely covers object bounds and the naming prefix; 'margin' and the detailed axis/count behavior are left to schema titles. The description adds context but not enough parameter-level meaning to bridge the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('box collision hulls'), and clearly states the method ('split box across an object's bounds') and naming convention ('generic Asset_COL_## names'). This distinguishes it from related sibling tools like object-collision_proxy_create by emphasizing split/box hulls rather than a generic proxy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as object-collision_proxy_create or object-lod_create. The description states what the tool does but does not provide decision context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It does disclose that the proxy is generated from the object's bounds and uses a predictable naming scheme, which is useful. However, it does not mention side effects, whether an existing proxy gets replaced, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundancy. It states the action, target, and naming behavior efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations, no output schema, and 0% schema description coverage, this one-sentence description is under-specified. It lacks usage context, limitations, and parameter semantics, and does not clarify the relationship to the similarly named collision hulls tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain the parameters, but it only indirectly hints at 'object' via 'bounds' and 'name' via the naming convention. The 'margin' and 'shape' parameters receive no meaningful elaboration beyond their schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') with a clear resource ('collision proxy') and states the scope ('around an object's bounds') plus the naming convention ('Asset_COL'). This distinguishes it from siblings like object-collision_hulls_create, which implies a different collision generation approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the similar sibling object-collision_hulls_create or object-lod_create. There are no stated alternatives, exclusions, or context clues for selecting this proxy-creation method over other collision options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention side effects, such as whether the collection is added to the current scene, whether it affects visibility or selection, or any prerequisites like existing parent collection existence. It doesn't state operational constraints or success/failure conditions. For a creation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and target. It contains no fluff and is easy to parse. It effectively communicates the core purpose without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no nested objects), the description is relatively complete in scope but lacks behavioral nuance. For a create operation, it doesn't cover error cases or side effects, which might be important for the agent to understand the impact. However, considering the complexity is low, it's minimally viable but has room to improve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the schema has titles for each parameter: 'New collection name' and 'Parent collection; scene root when empty'. The description adds minimal value by mentioning 'named parent collection' but does not elaborate on name constraints or parent validation. Since the schema is simple and already explains the parameters, the description adds little beyond that. Baseline 3 is appropriate because the schema provides adequate semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a collection' with the location specification ('under the scene root or a named parent collection'). It uses a specific verb plus resource and provides scope, distinguishing it from other outliner tools like renaming or deleting collections. However, it doesn't explicitly differentiate from other creation tools in the sibling list, though the context of outliner-collection is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when creating a collection, and specifies the parent parameter. However, it doesn't mention when not to use it or suggest alternatives. There's no explicit guidance on scenarios like creating nested collections or handling conflicting names, which could be useful. The instruction to use the parent parameter is clear but lacks broader context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action but does not indicate read-only nature, handling of no results, sort order, or any side effects. This is a minimal disclosure, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It is appropriately concise and front-loaded, leaving no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough for basic purpose recognition but lacks details on output, parameter usage, or edge cases. With no annotations and no output schema, this leaves the tool under-specified for an agent to use correctly in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. It does not explain the 'kind' filter or 'limit' behavior, leaving the agent to rely solely on schema titles and enums. This is a significant gap that the description fails to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (search) and the resources it operates on (objects, collections, scenes, view layers) with a specific criterion (by name). This distinguishes it from sibling tools like outliner-tree or outliner-describe, and it is 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies usage for finding items by name, providing clear context. However, it does not explicitly mention when not to use it or alternatives, so it falls short of the highest bar for explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the force requirement for the final collection case but fails to mention whether the operation is destructive, reversible, or what happens to the object's visibility/ownership after unlinking. As a mutation tool, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the primary action and resource ('Unlink an object from a collection'), with a clear conditional caveat. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description carries full burden for behavioral context. It discloses the force condition but omits key details: error behavior (e.g., what if object is not in collection?), side effects (is it reversible?), and whether unlinking removes visibility or just membership. The tool appears to be a mutation, yet no mention of permissions or impact on the object's other collection links.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It adds context for 'force' (required if final collection) but gives no additional meaning for 'object' and 'collection' beyond their generic titles. The schema's force description ('Allow object to have no collection') is vague compared to the tool description's 'final collection' condition, but the ambiguity remains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Unlink an object from a collection'. It specifies the resource (object) and operation (unlink from collection), and distinguishes it from sibling tools like outliner-parent_clear (removes parenting) and outliner-visibility_set (visibility toggles).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key usage condition: 'force is required if it is the final collection', telling the agent when the force flag is needed. However, it does not mention when to use this tool vs alternatives (e.g., moving to another collection, clearing parent) or any prerequisites like the object needing to be a member of the collection.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 read-only action through the word 'report', but it does not explicitly state that no mutation occurs, what output shape to expect, or how invalid or missing particle systems are handled. This leaves too much to inference for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, scannable sentence with no redundant phrasing. It places the main action and object up front, making the intended behavior immediately obvious despite being short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description should provide enough context about return structure and required inputs. It does not describe the behavior of the required 'object' argument or the format of the reported RNA properties, leaving an agent without enough information to fully scope the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description gives only high-level scope guidance for the optional 'name' parameter ('one or all particle systems'). It is silent about the required 'object' parameter, which is enough to be problematic given the 0% schema-description coverage. An agent likely cannot determine what type of object value should be supplied or how it relates to the particle system name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb ('Report') and a concrete resource ('live RNA properties'), and immediately distinguishes the scope ('one or all particle systems'). This differentiates it from sibling tools like particles-add, particles-remove, and particles-set, which clearly do mutation rather than reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the key scope behavior: omit the optional particle system name to cover all systems. However, it never explicitly tells the agent when to use this tool instead of particles-systems or particles-set, and it gives no prerequisites or commands to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 does not disclose side effects (e.g., whether it replaces existing stacks, requires the object to exist, or modifies in place), nor any prerequisites or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is simple and there are no annotations, so the description is minimally acceptable. However, it does not mention return values, side effects, or edge cases (e.g., behavior when an object already has a physics stack), which leaves some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides titles for both parameters ('Physics stack type' and 'Object to edit'), which partially covers semantics. The description does not add further explanation, but the parameter names are fairly self-explanatory, keeping the score at baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Add) and the resource (physics stack) and target (object). It distinguishes from siblings like 'physics-remove' and 'physics-set' by indicating the action of adding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives. It relies on the tool name and sibling context, but lacks explicit guidance such as 'use this to create a new physics stack rather than 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses a key behavioral trait: 'restoring prior scene settings after', indicating the tool temporarily changes settings and restores them. However, it doesn't mention whether the image is saved immediately, if the render blocks, or any side effects for unsaved changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs essential information: the action, the output, and the restoration behavior. Every word earns its place and there's no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 2 enums, and no output schema, the description is minimal. It covers the primary operation and restoration but misses important context like how the temporary settings interact with the parameters (e.g., engine, resolution) or what success/error responses look like. The complexity is moderate, so a bit more detail would be warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source beyond the schema. The description provides no parameter-level explanation; the schema only gives titles ('Destination image path', 'Camera object to use for this render', etc.) without deeper semantics. It doesn't clarify relationships between parameters or usage tips, leaving the agent to infer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Render a still image to disk') and identifies the specific resource (a still image). It distinguishes itself from sibling render-settings/render-set_settings by focusing on the actual rendering operation, but 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (rendering a still frame to disk) but doesn't provide explicit when-to-use/when-not-to-use guidance or mention alternative tools like render-settings. No exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Remove', giving minimal insight into side effects such as permanent deletion, undo behavior, or confirmation requirements. For a destructive operation, this transparency is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's function without extraneous words or ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation (removing a modifier from a strip) and the absence of an output schema or annotations, the description is adequate but does not mention potential errors or side effects, making it only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter titles 'Strip name' and 'Modifier name' are self-explanatory within the schema, providing adequate context. The description adds no additional detail, but schema coverage is sufficient enough to understand the parameters' roles, yielding a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the target ('a strip modifier'), which precisely identifies the tool's purpose and distinguishes it from other sequencer modifier operations like add, list, or set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or conditions. While the intent is obvious from the action, it lacks explicit 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 must carry the full burden of behavioral disclosure. It indicates a read-only reporting action but does not explain what 'live RNA properties' means, whether the operation has side effects, or what the output format is. Minimal behavioral context is provided beyond the verb 'Report'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and scope without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple report tool with no output schema, the description should clarify what properties are reported and how the 'object' parameter is used. It does neither, leaving the agent without enough context to invoke the tool confidently. The phrase 'live RNA properties' is jargon that is not expanded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially explains the 'name' parameter via 'one or all shader effects', but the required 'object' parameter is not mentioned at all. The description adds only marginal meaning beyond the schema's bare titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and resource ('live RNA properties') with clear scope ('one or all shader effects'). It distinguishes itself from siblings like shaderfx-list and shaderfx-set by focusing on reporting properties rather than listing or modifying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting shader effect properties, but does not explicitly state when to use it over alternatives such as shaderfx-list or shaderfx-report. No exclusions or alternative tool names are mentioned, leaving the context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It only says 'list' which implies read-only, but doesn't explicitly state side-effect-free, nor does it describe the output format (e.g., a list of type names). There's no risk of destructive action stated, but no confirmation either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the action verb, and contains zero fluff. It precisely states the purpose without any unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description is adequate. It clarifies the scope ('supported by the running Blender') and the resource ('shader effect types'). It could potentially mention what 'types' means or that the result is a list, but that's implied by 'list'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the baseline is 4. The description clearly explains the sole purpose, which is sufficient given there are no parameters to elaborate. It adds meaning by specifying 'supported by the running Blender', which is beyond an empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'List shader effect types supported by the running Blender' with a specific resource (shader effect types) and context (running Blender). It's not tautological and distinguishes from sibling tools like shaderfx-list, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention that this lists types only, or when to use shaderfx-list for actual effects, or any context like prerequisites. The description is purely declarative with no usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It only states the high-level action without disclosing side effects, such as creating new nodes, replacing existing connections, or requiring a pre-existing material. It also does not mention anything about image loading behavior or UV setup, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. Every word contributes to the core purpose, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that creates and wires nodes, the description is underspecified. It does not explain prerequisites (e.g., whether a material must exist), the effect on existing node connections, or the meaning of the 'target' choices beyond the enum values. Given the complexity of shading operations, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the schema provides titles for all three parameters. The description adds only conceptual context ('image-texture node', 'Principled BSDF target') without explaining parameter meanings or relationships beyond what the schema already states. It 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('wire') and identifies the resource ('an image-texture node to a Principled BSDF target'). It clearly distinguishes from sibling tools like shading-add_node or shading-link_nodes by implying a higher-level composite action for adding and connecting an image texture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (adding an image texture to a PBR input) but provides no explicit when-to-use or alternatives. It does not mention when to prefer this over lower-level tools like shading-add_node and shading-link_nodes, leaving the agent to infer based on naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only mentions 'create image slots' without disclosing side effects (e.g., node tree modifications, possible overwriting, material creation/reuse, object requirements). This is a significant gap for a tool that likely mutates the scene's node graph.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It front-loads the action and scope, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, likely creates a node group), the one-line description is insufficient. It lacks information about prerequisites, return values (no output schema), potential side effects, or error conditions. The description does not stand alone to guide an agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter understanding. It does not mention any of the five parameters (maps, size, object, prefix, material), while the schema only provides brief titles. The description adds no value beyond the schema's minimal metadata.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Create') and the resource ('node-based PBR image slots'), listing the exact map types (BASE_COLOR, NORMAL, ROUGHNESS, AO, CAVITY). This clearly distinguishes it from siblings like shading-add_image_texture or shading-create_material by focusing on a multi-slot PBR setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting up PBR maps but gives no explicit guidance on when to use this tool versus alternatives like shading-add_image_texture or shading-set_principled. No exclusions or alternative recommendations are provided, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description only states the action without mentioning side effects, permissions, or what happens to existing values; lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One clear sentence, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description is minimal but sufficient for a simple setter; does not explain return values or error handling, but no output schema exists; still, given the many similar tools, more context might be needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters clearly; description adds minimal extra info ('from JSON') which is already in schema, so it meets baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (Set) and the resource (shader node input default value) and specifies the source format (JSON), distinguishing it from other shading 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like shading-set_principled or shading-add_node; lacks conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not mention side effects, prerequisites (like edit mode), or how it affects existing UVs (e.g., replaces or blends).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, clear sentence with no redundant words or jargon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool, but description omits prerequisites (e.g., faces must be selected in edit mode, mesh must be active) and consequences (overwrites existing UVs). Adequate for a basic operation but not fully explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides clear titles for both params ('Mesh object to project' and 'Size of the projection cube'). Description adds no extra detail on how cube_size affects the projection or how object selection behaves beyond defaulting to active.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it cube-projects selected faces onto the UV map, distinguishing it from other UV projection methods like sphere or smart unwrap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Does not specify when to choose cube projection over alternatives (e.g., for box-like objects, or when spherical/planar would be better). Lacks any contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Report' suggests a read-only operation, and the description names the reported properties, but it does not disclose return format, units, or scene 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler and the key content is front-loaded. It is slightly terse but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless report tool, the description identifies what is reported. However, with no output schema or annotations, it leaves gaps about the exact return format and what 'background strength' means in the scene context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to document. The description adds context by naming what is being reported, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Report' and identifies the resource: scene world color and background strength. This distinguishes it from the sibling world-set tool, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus world-set or other report tools. The intended use is only implied by the word 'Report'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the in-place nature and the dirty condition, but it does not explicitly state that it discards unsaved changes or that the action is destructive. The lack of detail about side effects is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff. It front-loads the main action and adds a key condition, making it extremely concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool, the description covers the core function but omits details like what happens to unsaved data without force, potential confirmation prompts, or any return value. Given the destructive nature, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by specifying when 'force' is needed ('if dirty'). This clarifies the parameter's trigger condition, which the schema's title alone does not fully convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Empty the scene in-place') and differentiates from siblings like open/save by focusing on the new/empty operation. It also adds a context cue ('keeps the live bridge'), though 'new file' is not explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as app-file_open or app-file_save. The only hint is 'force is required if dirty', which is more about parameter usage than overall context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation by using the verb 'Report', but it does not explicitly state that the tool has no side effects or that it is safe to invoke. Without an annotation like readOnlyHint, the description carries the entire burden of transparency, and it only partially fulfills this by hinting at non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that lists the exact items to be reported. It avoids any redundant words or unnecessary details, achieving high clarity with minimal text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description lists the specific fields reported, it does not mention the output format, how the information is structured, or any additional context such as whether the report is human-readable or machine-parseable. It also lacks examples or notes on when this tool is most useful, leaving some ambiguity about its practical application.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema description coverage is 100% trivially. There is nothing for the description to add beyond what the empty schema already conveys, making this dimension fully satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: reporting specific Blender application state items (runtime, active file, dirty state, scene, workspace, render engine). It uses a specific verb 'Report' and enumerates the exact fields, leaving no ambiguity about what information is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not mention when to use this tool versus alternatives, any prerequisites, or typical scenarios. It lacks any indication of how to interpret the report or what actions might follow.
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 transparently says 'read-only, no revert' and explains the computation method (mean/min silhouette IoU plus bbox delta). This goes beyond a simple claim, but it omits details like output format or what happens if no baseline exists, though the schema hints at defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key action ('Do-no-harm metric') and immediately provides the computation details. It is efficient and to the point, though it packs a lot of technical terms, which may reduce readability. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a read-only metric with one optional parameter and no output schema, the description explains what it computes but does not specify the return value or how the metric is reported (e.g., returning a number, a message). It also assumes familiarity with terms like 'silhouette IoU' and 'bbox delta' without elaboration. It is adequate but leaves gaps for 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.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter 'object', and the description itself does not mention or explain this parameter. The schema's title provides some context, but the description adds no clarity about how to specify the object or what values are valid, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes a do-no-harm metric using silhouette IoU against a stored baseline, which distinguishes it from other feedback tools like feedback-quality or feedback-silhouette. The verb 'metric' and specific resource ('current form vs baseline') make the purpose clear, though the technical jargon might be opaque to some agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions it is read-only and a do-no-harm metric, which implies safe usage, but it does not explicitly state when to use this tool versus alternatives like feedback-silhouette or feedback-capture. There is no mention of prerequisites (e.g., having an intake baseline) or exclusions, so guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. 'Report' implies a read-only operation, which is useful, but the description does not explain what form the report takes, whether it reflects live state, or what exactly 'areas' and 'operators' mean. It provides only minimal behavioral context beyond the obvious non-mutating implication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundancy. It efficiently states the verb and the reported content, making it appropriately concise for a parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple—no parameters, no output schema, no annotations—so the description is partially adequate by stating what is reported. However, it lacks any clarification about the response format, the meaning of 'Info editor areas,' or how 'available report operators' are listed, leaving room for misunderstanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so no parameter documentation is needed. Baseline for zero-parameter tools is 4, and the description does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource—'Info editor areas and available report operators'—and uses 'Report' as an action verb, which distinguishes it from sibling domain-specific report tools like particles-report or constraints-report. It is not fully crisp, though, because 'Info editor areas' is somewhat ambiguous and 'available report operators' is a meta-level concept that is not clearly defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as info-messages, api-report, or the many other domain report tools. There are no explicit exclusions, prerequisites, or alternative tool recommendations, leaving the agent to infer usage intent from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The word 'report' implies a read-only or inspection behavior, but the description does not disclose what the output contains, whether any side effects occur, or how 'data and point state' are structured. This is minimal transparency beyond the stated purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and every word contributes to the tool's purpose. There is no redundancy or wasted prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter report tool, the description is minimally viable: it identifies the target resource and what will be reported. However, with no output schema and no annotations, the description does not fully clarify the response shape, the scope of 'data and point state,' or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only has an 'object' parameter whose title is 'Lattice object to inspect,' and schema description coverage is 0%. The description does not add meaningful parameter guidance beyond repeating 'lattice object,' leaving possible ambiguity about what kinds of object references are accepted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('report') and names the exact resources covered ('lattice object, data, and point state'), making its purpose clear. It also distinguishes itself from sibling tools like lattice-create, lattice-set, and lattice-point_set, which imply mutation rather than inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the user should call this when they want to inspect lattice-related state. However, the description does not explicitly state when to prefer this over alternatives such as lattice-set or lattice-point_set, nor does it provide exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral detail is 'without applying it', which clarifies that the modifier is not applied to the object. However, it does not disclose potential side effects like permanent deletion, effects on the dependency graph, or whether undo is available. No annotations exist to supplement this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential information without redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal operation, the description covers the core action and the key distinction (not applying). It does not mention return values or error handling, but these are likely covered by the tool's nature. The object parameter default is specified in the schema, rounding out the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides clear titles for both parameters ('Name of the modifier to remove' and 'Object owning the modifier (defaults to active)'), giving full coverage. The description adds the 'stack' context but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove), the resource (modifier), and specifies the context (from the stack) while distinguishing it from applying. This is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus other modifier operations (e.g., modifiers-add, modifiers-set). It mentions 'without applying' but does not elaborate on scenarios where removal is preferable or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for revealing side effects. It only mentions coordinate space; it does not state that the armature must be in edit mode, what happens if a bone with the same name exists, or whether the operation mutates the armature in place. For a mutation tool, this lacks critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It delivers the core purpose and a critical coordinate-space clarification efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is too sparse. It omits vital context such as the need for edit mode, duplicate-name handling, and what the tool returns or changes. The coordinate-space note is helpful but not enough for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds the key semantic that head/tail are in armature-local space, which is not in the schema. However, it does not add further meaning for the 'name' or 'armature' parameters, which remain described only by their schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds an edit bone to an armature, using a specific verb ('Add') and resource ('edit bone'). The parenthetical 'head/tail in armature-local space' further distinguishes it from sibling tools like rig-add_armature or rig-set_bone_transform, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description and tool name: use this when you need to add a new bone to an armature. However, it does not explicitly mention when to avoid it or point to alternatives such as rig-add_armature for creating the armature itself or rig-set_bone_transform for modifying an existing bone, so guidance is indirect.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 disclose behavioral traits. The verb 'List' implies a read-only operation, but it does not mention what happens if the strip does not exist, whether it returns an error, or the format of the output. It adds 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no superfluous words. It is appropriately sized for the tool's simplicity and immediately conveys the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema), the description is minimally sufficient but lacks details about return format, error behavior, or any prerequisites. It does not clarify whether modifiers are listed as a report or in some other structure, leaving some gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'name' with title 'Strip name', but schema description coverage is 0%. The description does not elaborate on the parameter's meaning, valid values, or formatting. It only indirectly implies the parameter refers to a sequence strip, which adds little value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List strip modifiers on a sequence strip'. It uses a specific verb and resource, and distinguishes itself from sibling tools like sequencer-modifier_add/set/remove by focusing on the listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when to list modifiers (e.g., before modifying) or any comparison to the sequencer-report tool. The description is purely declarative without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and behavior. 'Snapshot' suggests a non-destructive read, but it does not clarify whether the object is modified, how the checkpoint is stored, or what happens on rollback. It adds minimal context beyond the tool name, lacking important details 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that gets straight to the point, front-loading the primary action and purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with optional parameters and no output schema, the description is minimal but adequate to understand the core function. However, it lacks context about the checkpoint lifecycle, how rollback works, or when to create a checkpoint, leaving gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the parameters. While the schema titles provide some basic meaning (label auto-generated, object defaults to active), the description adds no extra value for parameter usage or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it snapshots mesh data and transform for rollback, using specific terms. It distinguishes from sibling tools like session-revert and session-list_checkpoints by focusing on the creation of a checkpoint rather than reverting or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies using it before an edit to enable rollback, but there is no explicit guidance on when to use it versus alternatives, no mention of session-revert or list_checkpoints, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states the action without disclosing side effects, such as whether existing connections are overwritten, the operation's reversibility, or any implicit requirements on the material's node graph. This leaves ambiguity about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that states the core purpose without any fluff. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple linking operation, the description plus schema is mostly complete. However, it could benefit from noting that it operates on an existing material and that the nodes must already be present, though this is implied by the parameters. Overall, it adequately conveys the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides clear titles and descriptions for all five parameters (e.g., 'Source node name', 'Destination input socket name or index'), covering 100% of them. The tool description adds no additional meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Link two shader node sockets') with a specific verb and resource. It is distinguishable from sibling tools like shading-add_node or shading-set_node_input, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It lacks context like prerequisites (e.g., nodes exist, material is selected) or situations where linking is preferable to other node operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. 'List' implies read-only and no side effects, but this is not explicitly stated. The description is minimal and does not mention any potential effects, permissions, or limitations, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, precise sentence with no redundant words or filler. It is perfectly concise and well-structured for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the sibling tools (speaker-create, speaker-report, speaker-set), the description adequately covers the tool's function within the context. It implies returning a list of speakers. However, it does not specify output format or any optional details, but this is acceptable for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema is empty (100% coverage trivially). The description does not add any parameter-related information because there are none to describe. Per the rubric, baseline for high schema coverage is 3, and no additional meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List speaker objects' clearly states the action (list) and the resource (speaker objects), distinguishing it from sibling operations like speaker-create, speaker-report, and speaker-set. It is concise but could be more specific about what a 'speaker object' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not clarify whether to use this over speaker-report for listing all speakers, or if it supports filtering. This lack of usage context may lead to ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description must convey behavioral details. It mentions 'report' implying read-only, but does not explicitly state side effects, permissions, or limitations. This is insufficient for a tool with no other metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose without any filler. It is efficiently structured and communicates the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool takes no parameters and has no output schema, the description adequately covers what the tool reports. It lists three specific aspects (availability, active window, capability flags), which provides sufficient context. Could potentially clarify 'availability' but overall it is complete for a simple report tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameters, so the description does not need to explain parameter meanings. Since there are zero parameters, the schema coverage is inherently high, and the baseline for this dimension is 3. The description adds no parameter-specific information, which is acceptable given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: reporting Blender UI availability, active window, and foreground-only capability flags. It uses a specific verb ('Report') and identifies a distinct resource (UI state), which differentiates it from sibling tools that handle other Blender aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It lacks explicit context such as 'use when you need to check UI status' or any comparison to 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 transparency burden. It says 'Set' but does not disclose whether the operation is partial, reversible, requires an existing world, affects rendering immediately, or returns any confirmation. This is a common but noticeable gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler. Every word contributes to identifying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with only two optional parameters, the description is minimally adequate. However, because there are no annotations and no output schema, the description could have noted preconditions or value conventions (e.g., color values, strength bounds) to make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mostly echoes the parameter titles: 'world color' and 'background strength'. It adds the useful 'and/or' point, but it does not explain what the color array should contain, typical value ranges, defaults, or how both parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') plus a clear resource ('scene world') and the exact fields it modifies ('color and/or background strength'). It distinguishes this from sibling reporting tools like world-report and from other world actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when you want to change the world color or background strength. However, it does not explicitly compare against alternatives, mention prerequisites such as an active world, or state when this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. The verb 'list' implies a read-only, non-destructive operation, which is acceptable but adds no further detail about potential side effects, performance, or output format. This is minimal but sufficient for a simple list tool, hence a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose without any redundant wording or unnecessary elaboration. Every word earns its place, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description is reasonably complete. It conveys the core function clearly. However, it does not mention what fields or information the profiles contain, nor does it indicate whether results are paginated. Given the simplicity of the operation, this is acceptable, but a bit more context could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. The baseline score of 4 applies because the absence of parameters is clear from the schema, and the description correctly implies a parameterless operation. No additional parameter clarification is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List Layer 2 game-asset class profiles', which clearly identifies a list operation on a specific resource (asset class profiles). It distinguishes from sibling tool asset_class-describe, which presumably focuses on a single profile. However, the term 'Layer 2' is not explained, leaving some ambiguity about the exact domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like asset_class-describe. There is no mention of prerequisites, intended use cases, or exclusions. The description simply states what it does, leaving the agent to infer appropriate usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It only states the basic creation action and does not disclose side effects (e.g., what happens to the previous active camera) or any prerequisites. This is insufficient for a tool with 9 configurable parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the main verb and includes the key optional behavior, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters) and absence of annotations, the description is too sparse to be considered complete. It does not explain how the camera is added to the scene, the meaning of unspecified parameters, or any constraints, leaving agents without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description fails to compensate for the 9 parameters. The only implicit reference is to the 'active' parameter, which provides minimal semantics beyond what the schema already indicates with its title. The description adds little value over the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a camera and optionally sets it as the active scene camera, using a specific verb ('Create') and resource ('camera'). This distinguishes it from siblings like camera-set or camera-set_active, which imply modification rather than creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for creating a new camera, implying it should be used when a new camera object is needed. However, it does not explicitly mention alternatives for editing existing cameras, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral context. It states the return is a 'typed parameter schema' which informs the agent about the nature of the response. It does not mention any side effects or require special permissions, but for a schema retrieval tool, this is reasonable. It adds value by indicating the output is a schema, not actual data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is 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 understanding. This is a model of efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is adequate but not exhaustive. It lacks details on how the schema is structured (e.g., whether it includes types, enums, defaults) which could be useful, but for a straightforward schema lookup, it covers the essentials. The missing output schema means the description should hint at the response format, which it does by mentioning 'schema'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must define the single parameter 'id'. It explains that 'id' is an operator id with an example ('mesh.bevel'), which adds meaning beyond the raw schema. However, it does not clarify the format or where to find valid ids, which is a minor gap given only one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving the full typed parameter schema for an operation. It specifies the resource (operation schema) and the verb (get), and provides a clear distinction from siblings like capabilities-search and capabilities-invoke, though not explicitly naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: before calling an operation, consult its schema. However, it does not explicitly state when not to use it (e.g., for listing all operations) or mention alternatives like capabilities-search for discovery, but the context of 'before calling it' is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. The verb 'List' implies a non-destructive read operation, which is transparent enough for a simple listing tool. However, it does not disclose what qualifies as 'available' or whether the output includes all areas or only those with existing overrides. It adds minimal context beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. Every word adds value: 'List available editor areas for context overrides' is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no params and no output schema, the description adequately conveys its function. It does not explain the output format, but given the low complexity, that is acceptable. The phrase 'for context overrides' provides useful context about its purpose, making it sufficiently complete for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description correctly contains no parameter details. The baseline 4 applies because there are no schema-driven parameters to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists available editor areas for context overrides. The verb 'List' and resource 'editor areas' clearly indicate a read-only enumeration. However, it does not explicitly differentiate from sibling tools like context-info, which may also list context-related information, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the purpose is clear, there is no mention of when to prefer this over context-info or other context tools, nor any exclusions or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 term 'Read' indicates a non-mutating operation, and specifying 'local and world bounds' conveys what is returned. However, with no annotations and no mention of error cases or prerequisites, the description carries only partial behavioral burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant information. It is front-loaded and efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does but omits details about the return structure, error behavior, or relationship to alternative read tools. Since there is no output schema, the agent lacks sufficient context to reliably interpret the result or handle edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'object' parameter beyond its title 'Object name', and the tool description does not elaborate on accepted formats or examples. With 0% schema description coverage, the description fails to compensate, leaving ambiguity about what an 'object' reference looks like.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and clearly identifies the resource as 'an object's local and world bounds'. It distinguishes from sibling object-related tools like object-transform_get by focusing on bounds rather than transforms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need an object's bounds) but does not explicitly mention alternatives or exclusions. Given the clear purpose, an agent can infer usage, but no direct guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It merely says 'set restrictions,' which is vague and does not disclose whether existing settings are overwritten, if the operation is reversible, or if any side effects occur (e.g., affecting linked collections). The verb 'set' implies mutation but gives no safety or behavior details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the key action and scope. It contains no fluff or repetition, making it highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with four boolean/string parameters and no output schema, the description is minimally adequate. It does not explain error behavior (e.g., missing collection), whether the tool creates or updates collections, or any interplay with other outliner tools. Given the lack of annotations, a bit more context would be helpful but is not critically deficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions the three boolean aspects (viewport, render, selectability) and the target 'collection', which aligns with the schema. However, it does not add meaning beyond the schema titles—no defaults, format expectations for 'collection', or explanation of how each flag behaves (e.g., whether unset flags are left unchanged). With 0% schema coverage, more compensation was expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: setting collection-level viewport, render, and selectability restrictions. It specifies the resource (collection) and the aspects (viewport/render/selectability), distinguishing it from sibling tools like outliner-visibility_set (likely object-level) and outliner-layer_collection_set (layer assignments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for collections ('collection-level') but does not explicitly state when to use this vs alternatives or any exclusions. It lacks guidance on prerequisites (e.g., whether the collection must exist) or comparisons with related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the burden. It discloses the operation's effect (unset/reset) and restricts scope to resettable RNA properties, but it does not state consequences for invalid/missing paths, reversibility, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that conveys action, resource, and method without filler. Every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema or annotations, the description gives the core operation and path semantics. It is minimally complete, but it omits failure behavior, expected return/confirmation, and how to discover valid stable paths.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates partially by explaining that the path is a stable Properties path identifying a custom/resettable property. However, it provides no syntax, examples, or details on how to format the path beyond the schema title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Unset') with a clear resource ('custom property or resettable RNA property') and the mechanism ('stable Properties path'). This distinguishes it from sibling tools like properties-set, properties-get, and properties-report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to choose this tool over properties-set or properties-get, and there is no explicit context for resettable vs custom properties. The purpose is implied by the verb but alternative usage is not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Create a new armature (skeleton) object'. It does not describe side effects such as whether the armature is added to the active scene, selected, or any other scene modifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no superfluous information, directly conveying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic action but omits details about the armature's initialization, such as whether it is created in the active scene or if it is selected afterward. Given the context of a 3D software, this might be assumed, but it is not explicitly stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters ('Name for the new armature object' and 'World location of the armature [x, y, z]'), so the description adds no additional meaning. The schema coverage is 100%, placing it at baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (armature object), and it is distinct from other rig tools like rig-add_bone which handles bones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, though the purpose is self-explanatory. It lacks mention of prerequisites or scenarios where other tools would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for transparency. It does not disclose any behavior such as read-only nature, side effects, or what exactly is returned (e.g., group names only, weights too, formatting). This leaves room for 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no superfluous words. It is concise and well-structured, immediately conveying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description adequately conveys the main action. However, it omits potential details such as whether it lists all groups including empty ones, or if it requires a valid mesh name. Still, it is complete enough for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single 'mesh' parameter with a title 'Mesh object to inspect'. The description adds no extra clarification about the parameter's format, required identifiers, or how it affects the output. Schema coverage is minimal, and the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to list mesh vertex groups and their assigned weights. This is specific and distinguishes it from related tools like rig-list_bones or rig-vertex_group_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspection but does not explicitly state when to use this tool versus alternatives. It lacks guidance on situations where listing vertex groups would be preferred over other rig or report tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as 'read-only', which is transparent about side effects. However, since there are no annotations to complement, it does not elaborate on behavior under edge cases (e.g., missing object parameter or undefined materials). This is sufficient for a simple list 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose and read-only nature. There is no redundancy or unnecessary detail, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lists materials, but the description does not indicate the output format or structure (e.g., names, indices, or full data). Since there is no output schema, the agent must infer the return value. For a simple list, this might be acceptable but is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'object' has a clear title 'Limit to one object's material slots', which explains its purpose. However, the description itself does not explicitly state the effect of omitting the parameter (likely lists all materials). The schema coverage is 0% but the title provides reasonable meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists materials in the file, with a read-only intent. This distinguishes it from other sibling tools that list different resources (e.g., objects, cameras, lights) or perform actions. The verb 'list' and resource 'materials' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It merely states the action without explaining scenarios (e.g., when you need all materials vs. those on a specific object). No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal that the operation modifies every keyframe on an object's f-curves, which is useful, but it does not mention that existing interpolation settings will be overwritten, that object defaults to active, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It earns its place by naming the operation, target, and scope, making it highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter, the description covers the core operation, but it lacks usage guidance, parameter depth, and behavioral caveats. There is no output schema, so return values are not required, but the absence of annotation support and alternative-tool context leaves it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It adds a bit of context about f-curves and keyframes, but it does not explain the interpolation enum values or elaborate on the object parameter beyond what the schema title already says. The description largely restates the schema's property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Set interpolation for all keyframes on an object's f-curves.' It clearly distinguishes this tool from animation siblings like anim-insert_keyframe or anim-set_frame by focusing on interpolating existing keyframes across f-curves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'all keyframes' implies this is for batch-changing interpolation on existing f-curves, but there is no explicit guidance on when to use it versus anim-keyframes, anim-set_timeline, or other animation tools. Context is implied rather than stated, and no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'report' without disclosing whether this is read-only, what data is returned, or any side effects. It does not explicitly state it is non-destructive or provide details about the report format, leaving significant ambiguity for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and default behavior. There is no wasted wording; every part adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter), but without an output schema or annotations, the description fails to explain what 'report' actually entails—what camera properties are returned, whether it lists the active camera or a named one, and any error cases. It is minimally complete but leaves critical details unexplored.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description indirectly explains the 'camera' parameter by stating it defaults to the active scene camera, which clarifies the optional default behavior. However, it does not explain what values are acceptable (e.g., object names) or how they are referenced, so the schema coverage is 0% and the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Report one camera' with a specific verb and resource, and it distinguishes itself from sibling tools like camera-list by indicating it reports a single camera rather than listing all. The phrase 'defaulting to the active scene camera' further clarifies scope and differentiates it from camera-set_active.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by stating it defaults to the active scene camera, implying when to use it (when you need info about a single camera, often the active one). However, it does not explicitly mention alternatives like camera-list or when not to use it (e.g., when you need all cameras), so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does convey that the search spans all of Blender and returns ranked results, which is useful, but it does not describe result format, output shape, or any limitations. For a read-only search tool this is acceptable but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds value: scope ('ALL of Blender'), action ('Search'), input ('keyword'), and behavioral cue ('ranked (start here)').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but has no output schema and no annotations, so the description should ideally clarify what the ranked results look like or how they can be used. It gives enough for an agent to invoke it, but omits some contextual details around result handling and fallback strategies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level meaning beyond what the input schema already provides. Schema description coverage is 0%, so the description was expected to compensate, but it mentions neither query, kind, limit, nor domain explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') with a clear resource ('ALL of Blender for a capability by keyword') and notes ranking behavior. It positions itself clearly against siblings like api-search or rna-search by emphasizing broad capability discovery across all of Blender.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
'(start here)' implies this is the intended first step for discovering capabilities, but it does not explicitly state when to prefer alternatives like capabilities-describe, api-search, or rna-search. The usage context is implied rather than explicitly contrasted with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation by stating 'Return', but does not explicitly disclose side effects, performance considerations, or what exactly is included in the output. The list of components adds some transparency about the content, but it does not describe the structure or format, nor potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose ('Return the logical scene tree') and immediately specifies the content. Every word contributes meaning, with no fluff or repetition. It is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is quite complete: it names the tool's output and its key elements. It could be improved by mentioning the output format (e.g., JSON, hierarchy structure), but given the low complexity and lack of annotations, it provides sufficient context. The description does not rely on external information, and the lack of an output schema means it must describe the result, which it does adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (empty schema). Per the rubric, the baseline is 3 for high coverage, and the description does not need to add parameter information since there are none. The description does not attempt to explain parameters, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the logical scene tree, enumerating its components (scenes, view layers, collections, objects, hierarchy). This distinguishes it from sibling tools like outliner-view_layers which specifically handle layers, or outliner-collection_visibility_set which manages visibility. The verb 'Return' and specific resource make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when to use this tool versus alternatives such as outliner-view_layers or outliner-find. It lacks any context about prerequisites, scenarios, or exclusions. While it is clear what it does, it does not guide the agent in choosing between related outliner 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. It hints at read-only behavior ('summarize') but doesn't disclose specifics like whether it returns a high-level overview or detailed lists, or if it includes other scene elements like lights or cameras. It's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential purpose. No wasted words, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is reasonably complete but could be richer. It doesn't specify what 'summarize' includes (e.g., names, properties, counts) or whether it affects the scene (likely not, but not explicitly stated). Given its simplicity, it meets the minimum viable bar.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since there are 0 parameters and schema coverage is 100% (empty), the description doesn't need to compensate for params. The baseline is 4 for 0-param tools, and the description confirms it's a simple report action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool summarizes the current scene's objects and materials, which is specific enough. However, it doesn't explicitly distinguish itself from sibling tools like 'properties-report' or 'shading-report' which might also provide scene-related summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to get a scene summary) but doesn't explicitly contrast with alternatives or mention when not to use it. Siblings like 'project-report' or 'context-info' might overlap, yet no guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry behavioral disclosure. It reveals a trust prerequisite and the use of Blender's script operator, but does not describe execution side effects, failure modes, or security implications beyond the trust note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no fluff—every word contributes. The key action, mechanism, and a critical condition are all packed into one concise phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, the description is minimal but covers the core action and a key trust condition. Missing aspects include how errors/output are surfaced and any safety caveats beyond 'trusted'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the only parameter (path) has only a title, not a real description. The tool description adds little beyond the title by merely saying 'Python file'; it does not specify path format, required extension, or how to reference files.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run'), names the resource ('Python file'), and identifies the mechanism ('Blender's script operator'), with a condition ('when Python execution is trusted'), making it clear and distinct from related tools like script-reload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies a use case—running a Python file via the script operator—and attaches a trust condition, but it does not explicitly compare to alternatives such as system-execute_python or specify when not to use it. The guidance is present 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 carries the full burden and does disclose the destructive action and its target. However, it does not mention whether removal is permanent/undoable, what happens if no strip matches, or any side effects on dependent strips.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb and resource, with zero unnecessary words or repetition. Highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive operation with no output schema and no annotations, the description covers the action, target, and selection method sufficiently. It could mention side effects or error behavior, but the low complexity reduces the burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description references the sole parameter by saying 'by name', which maps directly to the schema property. But it adds no extra constraints, examples, or failure semantics, and schema description coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and a clear resource ('sequence strip') along with the selection method ('by name'). This clearly distinguishes it from sibling tools like sequencer-strip_add and sequencer-strip_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, prerequisites, error behavior when the name doesn't exist, or whether multiple strips can match. Usage is only implied by the action verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral annotations are provided. The description implies a read-only operation, but it does not explicitly state that it has no side effects or require specific permissions, which would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and to the point, with no unnecessary words. It effectively communicates the tool's purpose in a single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a straightforward listing operation, but it does not mention what the output will contain (e.g., list of shader effect names, properties). This could be clarified, though it is not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'object' is described as 'Object to inspect', which is minimal but sufficient for a simple list operation. It does not elaborate on acceptable formats or potential defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (list) and the resource (shader effects on a Grease Pencil object), distinguishing it from sibling tools like shaderfx-add and shaderfx-remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as shaderfx-report, which might also provide similar information. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden and does reveal a key side effect: missing materials are created automatically. It leaves unspecified whether existing assignments are replaced, what default material is created, and what errors may occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with an essential parenthetical; every word contributes. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation, the core operation and auto-create behavior are communicated, but the absence of annotations and output schema, plus missing detail about replacement behavior or return state, leaves notable gaps. It is minimally viable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it mostly restates the schema titles: object receives material, material is a name created if missing. It adds no guidance on object identification, material name syntax, or existing assignment behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('assign') and resource ('material to an object'), and the parenthetical 'creates it if missing' clearly distinguishes this from sibling tools like shading-create_material. The operation and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical implies this tool is appropriate even when the material does not yet exist, so an agent can use it instead of pre-creating a material. However, it does not explicitly name alternatives or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the responsibility for behavioral disclosure. It states the tool 'list' columns, implying a non-destructive read operation. However, it does not disclose edge cases, such as behavior when no object is selected or when the component is unspecified, nor does it describe the output format. The description is minimal but not misleading; it conveys the core behavior of listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly front-loaded with the primary purpose. It contains no filler or redundant information, making it appropriately concise and easy to parse. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with two parameters and no output schema, the description is adequate but not comprehensive. It does not explain what the columns represent beyond noting they come from geometry attributes, nor does it specify the return format. However, given the tool's simplicity and the presence of sibling tools like spreadsheet-rows, the description provides enough context to understand the tool's role, though it could benefit from more detail about the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters, but schema description coverage is 0%, meaning the schema relies on titles (e.g., 'Object name; defaults to the active object' and 'Geometry domain/component: POINT, EDGE, FACE, or CORNER') for meaning. The tool description does not elaborate on these parameters or their semantics, leaving the agent to infer from the titles alone. This is insufficient given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'List spreadsheet columns' with a specific source: 'derived from object geometry attributes'. This distinguishes it from sibling tools like spreadsheet-rows (which lists rows) and spreadsheet-report (which likely provides a general report). The verb and resource are explicit, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs spreadsheet columns, but it does not explicitly contrast with alternatives like spreadsheet-rows or spreadsheet-report. There is no mention of when to prefer this over other spreadsheet tools, nor any exclusions. For a simple read-only listing, the purpose is sufficient, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses one non-obvious trait (works even while the main thread is busy) but lacks details on read-only nature, output format, or side effects. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with a parenthetical qualifier. Every word earns its place, and it avoids redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description is somewhat complete but lacks detail on what the returned progress data looks like (e.g., list of operation IDs, statuses). Given the lack of output schema, it would be better to describe the response shape. Still, it's adequate for a polling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter information, but none is needed. Baseline for 0 parameters is 4, and there's no extra value to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists in-flight and recent operations with progress, using a specific verb and resource. It distinguishes from sibling tools like system-health and system-cancel by focusing on the operation list, though it doesn't explicitly differentiate among them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking operation status but provides no explicit guidance on when to use it versus alternatives. The note about working while the main thread is busy offers context but doesn't mention any exclusion or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the burden of disclosing behavior. It states 'read-only', which indicates non-mutating behavior, and lists the output items. However, it doesn't disclose potential errors (e.g., non-mesh object), the exact structure of the report, or any prerequisites beyond the optional object parameter. This is basic but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It clearly lists what the tool reports and its read-only nature, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only report with one optional parameter and no output schema, the description lists the key output categories but omits details about report format, error behavior, or what 'layers' and 'island count' precisely entail. It's adequate but leaves gaps for an agent deciding whether the tool fits a need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'object' parameter at all, and schema description coverage is 0%. The schema's title ('Mesh object to inspect (defaults to active)') provides some meaning, but the description fails to compensate for the low coverage or reinforce the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an analytic UV report for a mesh, listing specific outputs (layers, has_uvs, island count) and explicitly marking it read-only. This distinguishes it from sibling UV action tools like uv-unwrap or uv-pack_islands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for inspecting UV data without modification, but it doesn't explicitly state when to prefer this over uv-layers or other UV report tools, nor does it mention alternatives or exclusions. It's reasonably clear that it's for reading UV info, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, but the description explicitly adds the read-only trait and scopes the operation to the file. It does not describe return format or empty-file behavior, but for a zero-parameter list operation this is a reasonable level of disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence states the action and resource, with the read-only qualifier appended parenthetically. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial zero-parameter read-only list tool, the description is sufficient: it states what is listed and that it is read-only. It would be more complete with explicit output shape or usage guidance, but low complexity keeps the gap small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters and the schema is empty with 100% coverage, so there is no parameter burden for the description to carry. The baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('actions in the file'), making the core operation clear. However, 'actions' is somewhat ambiguous and no contrast is made with sibling tools like anim-report or anim-keyframes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With many sibling animation list/report tools, the description does not explain when to choose this one over anim-report, anim-keyframes, or similar.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 explicitly mentions 'read-only', which is a key behavioral trait, but does not elaborate on return format, error handling, or side effects. The read-only disclosure is helpful but minimal, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the tool's purpose. It wastes no words and efficiently conveys the core functionality, earning full marks for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (read-only report of two data points) and the absence of an output schema, the description adequately states what the tool returns. It does not discuss prerequisites or error conditions, but these are implied for a simple inspection tool. The description is reasonably complete for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single optional parameter 'object' with a title specifying its purpose, but the tool description does not mention this parameter at all. Schema description coverage is 0%, and the description fails to compensate by adding any parameter context. The schema title provides some value, but the description adds nothing, resulting in a low score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an animation report for an object, specifying what it reports (frame range, f-curve count). It distinguishes itself from sibling anim-* tools which are primarily operational (set frame, insert keyframe), making the read-only report purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting an object's animation data, but provides no explicit guidance on when to use this tool versus alternatives like anim-timeline or anim-keyframes. No exclusions or alternative recommendations are given, making the contextual guidance weak but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries burden. It states main behavior (save current file, or to path if unsaved) and implies path is ignored if already saved. However, it does not disclose overwrite behavior, error handling, or other side effects. It's minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, clear and concise, front-loaded with action. No unnecessary details, easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal annotations, description is adequate for a simple save operation, but there are many sibling save tools, and it doesn't explicitly differentiate. It covers the essential behavior but lacks nuance about edge cases or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the path parameter with a clear title, and description indirectly explains its usage in the unsaved case. Description does not directly name the parameter but adds context on when it's needed. Since schema coverage is 0%, description compensates somewhat, but not fully as it doesn't specify format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (save) and resource (current file), with a conditional for unsaved files. It distinguishes from siblings like save_as by implying it saves without changing the file's location except for unsaved files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description gives context on when to use (save current file, with path if unsaved) but does not explicitly mention alternatives or when not to use it, such as comparing to save_as or save_copy. It's not misleading, but no exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose whether the operation is destructive, whether it modifies the object in place or creates a new one, or any side effects. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that conveys the core purpose and mode options without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description is minimal. It does not mention return values, object modification behavior, or potential impacts (e.g., UVs, materials). While adequate for a simple tool, it lacks context that would help an agent understand consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptive titles for all parameters, so coverage is high (baseline 3). The description adds slight context about mode logic but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (retopologize a mesh) and the objective (face budget), and distinguishes it from other mesh tools by its specific purpose. No sibling tool offers retopology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides guidance on the two modes (voxel+decimate vs decimate-only) and when voxel might be unsafe, which helps in selecting the mode. However, it does not explicitly state when to use this tool over alternative mesh simplification methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral implications. It states the action and that a shrinkwrap modifier is involved, but does not explicitly mention whether the modifier is applied non-destructively or if the operation is reversible. The 'apply' parameter hint is in the schema, but the description does not elaborate on side effects or mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It efficiently communicates the core functionality without unnecessary elaboration, making it easy for an agent to parse and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple modifier operation but lacks specifics about return values, potential errors, or requirements (e.g., if the target must be a mesh). It does not mention whether the modifier is created directly on the object or if the operation returns a status. Given the tool's moderate complexity, more detail on expected outcomes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed per-parameter descriptions (e.g., 'Apply the shrinkwrap modifier immediately'), so the tool description does not need to repeat them. However, it adds context by explaining the overall purpose, which helps an agent infer how the parameters (object, target, offset, apply) interact. This adds value beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: snapping a mesh's vertices to a target object's surface via a shrinkwrap modifier. It specifies the resource (mesh), the operation (snap), and the mechanism (shrinkwrap modifier), effectively distinguishing it from other object-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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternative mesh modification tools. It does not mention prerequisites, ideal scenarios, or contrast with similar operations (e.g., other modifiers or snapping methods). Without explicit usage context, an agent may not know 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.
- 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 and does state the key behavioral trait: the operation is read-only. It also discloses what data will be returned (bones with head/tail positions). It does not cover failure behavior or coordinate-space details, but for a simple list operation this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that states the action, resource, output details, and safety profile. Every word earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only listing tool, the description covers the essential purpose and output content. There is no output schema to supplement return-value details, but the gap is minor given the low complexity and clear scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter, 'armature', with only a title ('Armature object to inspect') and no description coverage. The tool description does not clarify how the armature should be identified—whether by name, path, reference, or active object—leaving the required input meaning ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), clearly identifies the resource ('an armature's bones'), and states the output content ('head/tail positions'). It also flags the operation as read-only, which distinguishes it from sibling mutation tools like rig-add_bone and rig-set_bone_transform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use this tool versus alternatives such as rig-report or rig-pose_report. The read-only tag implies inspection, but no exclusions, prerequisites, or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the core behavior (polling check) but does not disclose that it does not execute the operator, whether it is read-only, or how the temporary override context behaves. Still, 'poll' connotes non-destructive availability checking, so it is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One tightly front-loaded sentence conveys the essential purpose without waste. It earns its place and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no annotations, a single sentence is inadequate. The description lacks return-value expectations, error handling, or any guidance on how parameters interact to create the polling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only hints at 'explicit editor area context.' It adds no meaning for key parameters like idname, object, select, mode, or require_area; the schema titles alone are insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Check') and names the exact resource/behavior ('whether a Blender operator polls') with a qualifier ('in an explicit editor area context'). This clearly distinguishes the tool from siblings like ui-operator_invoke (executes) and context-poll_operator (likely current context).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this is for checking operator availability under an explicitly constructed editor area context. It does not explicitly name alternatives or exclusion conditions, but the context is specific enough for an agent to infer when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey safety and side effects. The verb 'Report' implies a read-only operation, but it does not explicitly state that no modifications occur. It also omits details about return format or units, leaving some behavioral ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that lists exactly what is reported. Every word adds value, and there is no fluff or redundancy. It is front-loaded and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple report tool with no parameters and no output schema, the description covers the essential information: what data is returned. It is complete enough for an agent to understand the tool's function, though it could mention units or whether frames are 0-based or 1-based.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline is 4. The description adds no parameter-specific information, but none is needed. It correctly focuses on the tool's output rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports scene timeline range, current frame, and frame rate, which is a specific, concrete action. It distinctly differentiates from sibling tools like anim-set_timeline and anim-set_frame, which perform mutations, and from anim-report, which likely provides a broader overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention scenarios like checking playback boundaries or frame position, nor does it contrast with anim-report or anim-keyframes. There is no context about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. However, it only states the action without revealing side effects (e.g., overwriting existing preferences, persistence scope, or potential irreversible changes). The description adds no information beyond what the tool name suggests, leaving the agent unclear about the impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancy. It front-loads the key information and does not waste words. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, output schema, or collaborators to consider, the description is sufficient to convey the core functionality. It could optionally mention persistence side effects, but given the low complexity, the one-liner is mostly complete. The distinction from app-preferences_summary is implicit but clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no fields to explain. The baseline for 0 params is 4. The description does not need to add parameter details, and it correctly focuses on the action. It adds minimal semantic context beyond the schema, but that is acceptable given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Save') and the resource ('current Blender user preferences'), making it distinct from siblings like app-preferences_summary (which reads preferences) and app-file_save (which saves files). The verb+resource pattern is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to persist current user preferences) but provides no explicit guidance on exclusions or alternatives. For a simple tool, the context is obvious, but it does not mention any scenarios where it should not be used or contrast with similar save operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It does mention the core behavior (does not remove existing collection membership), but it omits other relevant details such as whether the object/collection must already exist, if the operation is idempotent, or any side effects like updating parent links. This is a basic but not thorough disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that conveys the essential action and constraint. No filler or redundancy; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, no annotations, and only two parameters, the description covers the primary action but lacks context about prerequisites, error conditions, or the broader outliner hierarchy. It is minimal but not entirely insufficient; still, it could benefit from mentioning typical usage or expected behavior when memberships already exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. However, it provides no additional information beyond the schema's titles ('Object to link' and 'Target collection'). It does not clarify parameter formats, required identifiers, or how they relate to the linking operation, leaving agents guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Link an object into a collection') and specifies the key constraint ('without removing existing collection membership'), making it distinct from sibling tools like outliner-object_unlink or outliner-object_move. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use case by noting that existing membership is preserved, which suggests when to use this over alternatives that move or unlink. However, it does not explicitly name any alternative tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals that world transform is preserved by default, which is a meaningful side-effect of reparenting. It could be more detailed about failure modes or hierarchy side-effects, but the core behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that directly states the operation and its key default behavior. Every word earns its place; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with three parameters and no output schema, the description is minimally viable. It communicates the core action and default transform behavior, but incomplete parameter identification and lack of usage alternatives leave gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds little parameter meaning. 'object' and 'parent' are not explained beyond their titles, and 'preserving world transform by default' only restates the keep_transform default. No guidance is given on how to reference objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Set an object's parent' clearly identifies the operation. The added clause 'preserving world transform by default' further distinguishes it from related operations like outliner-parent_clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied by the action itself: when you need to reparent an object, this is the natural tool. However, it does not explicitly mention alternatives such as outliner-parent_clear or outliner-object_link, nor when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 adds two key constraints (force requirement and last-layer restriction), which is useful. However, it does not explain what happens on success/failure, side effects like confirmation prompts, or scope of deletion. The value added is moderate but minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that conveys the essential purpose and a key constraint. It avoids unnecessary detail and front-loads the action. Every word is meaningful, making it highly concise with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema, so the description need not explain return values. It covers the core delete action and the critical 'force' constraint, but it leaves ambiguity about what 'force' exactly does (it is only described as 'Confirm render organization change' in the schema) and does not explain the consequence of attempting to delete the last layer. For a destructive operation, this is borderline complete but lacks clarity on the force parameter's necessity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentiones that force is required, but the schema lists force with a default of false and does not mark it as required. This is a contradiction with the schema, and the description adds no further detail about the 'name' parameter or the meaning of force beyond the schema's title. The information is sparse and slightly misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete a view layer) and identifies the resource (view layer). It distinguishes from sibling tools like outliner-view_layer_create and outliner-view_layers by explicitly naming the delete operation, 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides important usage context by stating that force is required and the last layer cannot be deleted. This gives the agent criteria for invoking the tool, though it does not explicitly mention alternatives like when to use view_layer_create instead. The guidance is clear enough for a delete operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the operation is a read, which implies non-mutating behavior, but it does not go further. Since there are no annotations, the description carries the burden, yet it says nothing about output shape, failure modes, or whether the read only returns values or also metadata. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately communicates the operation and provides illustrative examples. There is no fluff or redundant repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—one required parameter, no output schema, and a focused read operation—the description is nearly sufficient. It could be more complete by mentioning what is returned or how errors are handled, but the core usage is clear enough for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a title for the single 'path' parameter; the description adds meaningful examples of valid path structures and the 'object:' syntax. This compensates for the 0% schema-level description coverage, though it does not explain percent-encoding details, which are left to the schema title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Read') with a specific resource ('a stable Properties path') and concrete examples such as 'object:Cube/location' and 'object:Cube/idprops/foo'. This distinguishes it from sibling mutation/report tools by emphasizing stable-path reads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus siblings like properties-report or properties-object_report. There is no when-to-use or when-not-to-use context, and no alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for disclosure. It clearly indicates a mutating operation (parenting plus automatic weight generation), but it does not mention side effects such as whether existing vertex groups are overwritten or if an Armature modifier is added. This is acceptable but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the core operation. There is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description sufficiently covers what the tool does and what it operates on. It could mention prerequisites or side effects, but the low complexity means the current level of detail is mostly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions, only titles, and the tool description does not elaborate on the two parameters. However, the titles 'Mesh object to skin' and 'Armature object to bind the mesh to' plus the parameter names make the intent reasonably clear, so the low coverage is partially mitigated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Parent a mesh to an armature with automatic skinning weights'. It uses a specific verb and resource, and 'automatic skinning weights' distinguishes this tool from generic outliner parenting or pure weight-assignment rig tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you want to bind a mesh to an armature using automatic skinning weights. However, it does not explicitly name alternatives or explain when not to use it, such as when manual weight painting or simple parenting is more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly states 'read-only', which is a key behavioral trait, but it does not disclose error handling (e.g., behavior on invalid path), return format, or any limitations. This is a minimal disclosure, leaving some ambiguity for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded with the action and resource, making it immediately understandable. This is an ideal length for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, read-only operation), the description covers the essential purpose and path context. However, it omits details about return values, error behavior, and whether properties can be nested, which would be useful for an agent but not critical for a basic getter. The example in the schema title fills some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no description field), so the description must compensate. The description mentions 'by path under bpy.data' and the schema's title gives an example ('objects.Cube.location'), but the description adds little beyond that. It does not explain path syntax, expected value types, or edge cases, though the example is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read'), the resource ('data property by path under bpy.data'), and the read-only nature. This differentiates from sibling tools like rna-set_property (write) and rna-describe (describes properties), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for reading properties but does not explicitly mention when to choose this over alternatives (e.g., rna-describe or rna-search). It provides an example path but lacks explicit 'use this for...' or 'avoid when...' guidance, so it meets only the basic contextual bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions ranking by relevance, which is a behavioral detail. However, it does not explicitly state read-only behavior, error conditions, or side effects. Since no annotations are provided, the description carries the burden; it gives minimal but not comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It efficiently communicates the purpose and key behavior without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a search tool: it states what is searched, what is matched, and how results are ordered. While it does not detail the return format or edge cases, the context is adequately complete given the schema and the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptive titles for all four parameters (query, kind, limit, category), achieving high schema_description_coverage. The tool description adds no additional parameter explanation, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: searching the live Blender API for operators or types matching a query, with results ranked by relevance. It specifies the resource (API) and the action (search), distinguishing it from other tools like api-search or rna-describe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering API elements but does not explicitly contrast with alternative search tools (e.g., api-search, rna-describe). It lacks guidance on when to prefer this tool over others, reducing clarity for an agent choosing among similar capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 for behavioral disclosure. The verb 'List' implies a read-only operation, but the description does not disclose output format, ordering, whether default paths are included, or any prerequisites. It is minimally adequate but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy. It front-loads the action and clearly names the resource, making it concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless listing tool, the description gives the core purpose and output area. However, since there is no output schema, a little more detail about what 'script search paths' encompasses (e.g., user scripts vs. system paths) would improve completeness. Still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The description does not need to explain parameter semantics, and no meaningful parameter information is missing. Baseline 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the exact resource ('Blender script search paths and configured script directories'). It clearly distinguishes this tool from siblings like script-run_file or script-report by focusing on the path listing aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when this tool should be preferred over alternatives, nor any mention of when not to use it. The description only states what it does, leaving the agent to infer use cases from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects. It says 'reload from disk' but does not explicitly state that unsaved changes will be lost, which is a critical safety behavior for a revert operation. The statement 'force is always required' hints at a confirmation step but does not describe the destructive nature fully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the purpose and includes the key usage condition iconcisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a single parameter, the description covers the basic action but lacks a warning about discarding unsaved changes. While the tool is simple, the destructive nature of reloading should be highlighted for safety. The description is adequate but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the single parameter 'force' by stating it is always required, which the schema does not convey (default false). This clarifies that the must be set to true for the tool to function, which is valuable beyond the schema's title and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Reload the current file from disk'. This is specific and distinguishes it from save/open operations among siblings. The verb 'reload' and resource 'file from disk' are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage condition: 'force is always required', indicating that the tool will only work when force is set to true. It does not explicitly state when to use vs alternatives, but the purpose is clear enough that the context implies discarding unsaved changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the raw operation, the description discloses that the file becomes active, a behavioral side effect not present in annotations (which are absent). This adds useful context for understanding the tool's side effects, though it doesn't mention potential overwriting or error conditions. Given no annotations, the description carries the burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single sentence to effectively communicate the tool's purpose and key behavioral nuance. Every word adds value, with no unnecessary details or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately covers the main use case and the critical side effect of making the file active. It could mention what happens if the path is invalid or if the file already exists, but given the tool's simplicity, this is likely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' is clearly outlined by the schema's title ('Absolute output .blend path'), but the description adds minimal additional meaning beyond restating 'absolute path'. Since schema coverage is 0% and the description does not compensate with extra parameter details (e.g., file extension requirements), the added value is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific action verbs ('Save') and clearly identifies the resource ('current file') and destination ('new absolute path'). It also distinguishes itself from siblings like app-file_save and app-file_save_copy by noting the file 'becomes active', clarifying the operational distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (saving to a new path and making it active) but does not explicitly mention when not to use it or compare with alternatives. It provides enough context for a knowledgeable user but lacks explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 transparency. It discloses the rendering behavior and color mapping, which is useful context beyond the tool name. However, it does not mention whether the render respects the current viewport, what the output format is, or potential side effects, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action ('Render a topology overlay') and packs the complete color legend and wireframe detail into the remainder. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—3 optional parameters, no output schema, no annotations—the description adequately captures the essential visualization semantics. The schema titles cover defaults for res/view and the active-object default for object. A slightly richer note about applying to the given object or view would improve completeness, but it is not a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description does not explain any of the three parameters (res, view, object). While the schema parameter titles are somewhat self-explanatory, the tool description itself adds no parameter-level meaning, so the agent receives no compensation for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Render' with the resource 'topology overlay' and details the exact color legend (n-gons red, tris orange, quads grey) plus wireframe. This clearly distinguishes it from sibling feedback tools like feedback-uv, feedback-wire_shaded, or feedback-orientation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when topology diagnostics are needed, as it explicitly shows how n-gons, tris, and quads are color-coded. It does not explicitly name alternatives or provide exclusion conditions, but for a visual feedback renderer the intended use is quite clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It adds useful behavioral context by stating that format can be inferred from the output path and that either the scene or selected objects are exported. However, it does not disclose side effects such as file overwriting, required directory permissions, or what happens when the destination already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence. Every word adds value: the verb, the resource scope, and the critical format-inference behavior. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no annotations, and no output schema. The description and schema together are enough for a straightforward export call, but the description alone does not explain file-overwriting behavior, return type, or typical workflows. It is adequate for basic use but lacks the deeper contextual insurance expected for a file-writing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does help by linking 'path' to format inference and by clarifying that the export scope may be the whole scene or selected objects, which indirectly maps to the 'objects' parameter. It does not provide detail for 'y_up', 'apply_modifiers', or the exact formatting of the objects parameter, relying mostly on schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource: 'Export the scene or selected objects.' It also adds a meaningful scope distinction from siblings like io-import by stating that the format can be inferred from the path, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use it for exporting either the full scene or selected objects, and that no explicit format is needed when the path implies it. It does not explicitly name alternative tools or provide exclusion criteria, but the context is clear enough relative to the io- and export-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The description clearly states the tool toggles shading, implying a mutation of object state. However, it does not mention if the operation is reversible (toggle implies yes), requires object selection, or has any side effects. Without annotations, more detail would be beneficial, but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero fluff. It is highly concise and effectively front-loaded with the action. It earns its place by providing clear purpose without any waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with two optional parameters, no output schema, and no annotations. The description is adequate for understanding the basic function, but it lacks context on prerequisites (e.g., must be a mesh object), potential failure modes (e.g., object not being a mesh), and any side effects beyond toggling. Given the simplicity, a 3 is appropriate as it covers the essentials but misses some operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must explain parameters. The description provides minimal information about parameters: the object defaults to active, and the 'smooth' parameter defaults to true Determination. However, it does not elaborate on what 'smooth' means beyond the schema's title. Since schema titles already explain the parameters well (e.g., 'Smooth shading when true, flat when false'), the description adds the default behavior, which is helpful for a 0% coverage scenario.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Toggle smooth/flat shading on the object'. It uses a specific verb ('toggle') and resource ('shading'), and clearly distinguishes it from sibling tools like 'mesh-recalc_normals' or 'shading-*' tools, which deal with materials and shaders. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is for toggling shading on a mesh object, which is clear enough. However, it does not specify when to use this vs alternatives (e.g., when to use 'mesh-recalc_normals' instead), nor any exclusions like only meshes. There is implicit guidance but no explicit 'when not to use'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden; 'List' clearly signals a read-only operation and the scope behavior is disclosed. However, it does not describe return format, handling of missing bone names, or whether only bones with constraints are included, leaving agents partially in the dark.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One 10-word sentence, front-loaded with the verb 'List', and every word adds scope or resource specificity. There is no filler and no redundant restatement of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list tool this is mostly adequate, covering the target resource and filtering scope. Yet with no output schema and no annotations, the description omits return-value hints and edge-case behavior (missing bone, armature without pose bones), which a listing tool should anticipate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and parameters have only title text, so the description must compensate. It does so meaningfully by explaining that omitting 'bone' yields the whole armature's constraints, directly mapping to the optional parameter; however, it does not clarify the expected format for the required 'armature' value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States the action ('List') and resource ('pose bone constraints') with explicit scoping ('on one bone or the whole armature'), providing a specific verb+resource+scope. The 'pose bone' qualifier distinguishes it from generic sibling tools like constraints-list and from rig-report/rig-pose_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or alternative guidance is given. The verb 'List' implies a read-only inspection use-case, distinguishing it from mutating siblings like rig-constraint_add/remove, but the description never names alternatives or exclusions despite many overlapping report/list tools existing.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. 'List' strongly implies a read-only operation, which is useful, but the description does not disclose whether the response is hierarchical, filtered by the current context, or limited to geometry data. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and the full scope of resources. Every word contributes, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what kind of result is returned, such as a nested hierarchy or flat list with geometry details. The description names the entities but leaves the response shape and scope (e.g., active workspace vs. all) implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter explanation is not needed. Per the baseline for no-parameter tools, this is fully adequate; there is nothing for the description to add beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and names concrete resources: windows, screens, workspaces, areas, regions, and UI geometry. This clearly distinguishes it from siblings like app-workspaces or context-areas, which target narrower or different UI concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: call this when you need an inventory of Blender UI elements. However, it does not explicitly state when to prefer this over related tools like ui-state, app-workspaces, or context-areas, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the critical behavior that force is needed when the file is dirty, which is a key side effect. However, it does not mention potential errors (e.g., missing file) or whether the operation replaces the current scene, leaving some behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the primary action and then adds the crucial condition. There is no redundant text, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and no output schema or annotations, the description covers the essential behavior and the only notable edge case (dirty file). It could be more complete by mentioning error handling, but for the simplicity of the operation, it is adequately informative without being verbose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides titles for path and force, but the description adds meaning by specifying 'absolute path' and clarifying that force is required when the file is dirty, which goes beyond the schema's simple 'Discard unsaved changes'. This adds valuable context to parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens an existing .blend file by absolute path, which is a specific verb+resource combination. It distinguishes from siblings like app-file_new and app-file_revert by focusing on opening existing files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a usage condition (force required if file is dirty) but does not explicitly contrast with alternatives such as app-file_revert or app-file_new. The when-to-use context is implied rather than explicitly stated, leaving some ambiguity about when to prefer this tool over other file operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals useful behavioral information: it creates a copy and leaves the active file path unchanged. Still, it does not clarify overwrite behavior, error handling, or the return value, leaving some important trait undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the action and key side effect without padding. It is front-loaded and every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core operation and its distinguishing side effect. The main missing detail is overwrite/conflict behavior, but given the tool's low complexity, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema property is titled 'Absolute output .blend path', which already explains the parameter's purpose. The description adds no further mapping details, and with 0% schema description coverage, it provides minimal compensation, but the single path parameter is largely self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('save a copy') and resource ('current file'), and immediately distinguishes itself from related tools with 'without changing the active file path'. This clearly sets it apart from app-file_save_as, 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without changing the active file path' provides clear contextual guidance for when to use this tool over sibling save operations. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a full guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It accurately states that the tool changes the selection state of all scene objects, but it does not discuss edge cases like hidden objects, locked objects, or whether the invert operation is based on the current selection. This is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence that names the tool's main purpose in plain language. Every word contributes to understanding the operation and scope, with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter selection tool with no output schema, the description plus the parameter enum is nearly complete. It explains the action and target ('all scene objects'), and the schema supplies the exact enum values and default. It could be slightly more complete by noting whether only visible or selectable objects are affected, but that is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the parameter is a self-explanatory enum with values SELECT/DESELECT/INVERT and a default of DESELECT. The description paraphrases these actions but does not add meaningful detail beyond the schema, such as default behavior or interaction rules. It is sufficient but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase and resource: 'Select, deselect, or invert selection for all scene objects.' This clearly identifies both the operation and its global scope, and distinguishes it from sibling tools like context-select_objects or mesh-select_all by emphasizing 'all scene objects.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when you want to change selection state for every scene object. It does not explicitly name alternatives or when-not-to-use scenarios, but the 'all scene objects' qualifier implies the intended scope versus more selective tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'List' implies a read-only operation, but it does not explicitly state that it has no side effects, nor does it describe the output format. For a simple listing tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action ('List') and object ('modifier types'). There is zero unnecessary detail, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is sufficient. It specifies the scope ('supported by the running Blender') but does not mention the return format (e.g., a list of strings). However, this is minor and the description adequately covers the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to explain parameter semantics. Per the baseline for 0 params, a score of 4 is appropriate, as no additional explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'modifier types', with the context 'supported by the running Blender'. This distinguishes it from sibling tools like modifiers-list (which lists modifiers on objects) and modifiers-add. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case (discovering available modifier types) but does not explicitly state when to use it versus alternatives like modifiers-list. There is no exclusion or direct comparison, but the purpose is clear enough to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explicitly mentions the default transform preservation, which is a key side effect. However, it does not elaborate on what happens when keep_transform is false or other potential consequences, but for a simple unparent operation it is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, precise sentence that conveys the action and default behavior without any unnecessary words or repetition. It is perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple operation, the description provides enough context for an AI to understand the purpose and default behavior. It does not explain error handling or edge cases, but given the simplicity, it is sufficiently complete for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters and their titles already convey most of the meaning (object, keep_transform = Preserve world transform). The description reinforces the default but adds little beyond what the schema provides, aligning with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (clearing an object's parent) and adds the key detail about preserving world transform by default. It is specific and distinguishable from sibling tools like outliner-parent_set and outliner-object_unlink.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies when to use the tool (when you need to remove a parent-child relationship), it does not explicitly contrast with alternatives like parent_set or object_unlink. It lacks explicit guidance on when not to use it, so it is adequate but not highly informative.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. 'List' clearly implies a read-only operation, but the description does not elaborate on any special behavior, such as whether a particular view layer must be active or what the output structure looks like. It is adequate but minimal for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb 'List' and object. No filler or repetition. It earns its place fully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description effectively communicates the output (view layers and restriction trees) and scope. It lacks an explanation of the exact structure of 'layer-collection restriction trees', which could confuse agents unfamiliar with Blender, but overall it is sufficient for a simple query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so the parameter baseline of 4 applies. The description adds no parameter information because there are none to describe. The schema already fully covers the parameter space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'List' with a clear resource 'view layers' and further specifies 'their layer-collection restriction trees', which distinguishes it from sibling tools like outliner-tree or outliner-describe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description: it is for listing view layers and their restriction trees. However, there is no explicit guidance on when to use this versus alternatives, nor any exclusions or context about when this tool is preferable to outliner-tree or outliner-find.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 full responsibility for behavioral disclosure. 'Report' implies a read-only, non-destructive operation, but the description does not explicitly confirm the absence of side effects, permission requirements, or any limitations. It adds minimal behavioral context beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase 'Report active render settings' that conveys the purpose without any unnecessary words. It is perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, straightforward reporting action), the description provides sufficient context. It clearly states what the tool returns (active render settings) and is complete for its minimal scope, though it does not elaborate on the exact settings or return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which sets a baseline score of 4. The description does not need to explain parameters, and it does not. No additional meaning is required since there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Report' with a clear resource 'active render settings', making it distinct from sibling tools like 'render-set_settings' (which implies setting) and 'render-still' (which renders an image). It unambiguously identifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While it is implied that one would use it to query current render settings, there is no explicit mention of alternatives or when not to use it. The usage context is 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 provided, the description must carry the behavioral burden. It states the mutating action (clear) but does not mention potential side effects, prerequisites (e.g., pose mode), or whether it affects only selected bones or all. It is not misleading but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter and no output schema. The description fully defines its behavior and requirements for a typical use case, making it complete without needing additional details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'armature' parameter. Although the schema itself provides a clear title, the description fails to compensate for the lack of parameter explanation, as required by the rubric for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (clear), the resource (pose bone transforms), and the outcome (back to rest values), distinguishing it from related rig tools like rig-set_pose_bone or rig-pose_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you want to reset all pose bone transforms to rest. It provides clear context but does not explicitly mention alternatives or when not to use it, which is acceptable for a simple operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. The verb 'Describe' strongly implies a non-mutating read-only operation, which is reassuring. However, it does not explicitly state that no modifications occur or describe any potential side effects (even if none exist). With no annotations, this minimal assurance yields a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource, then provides examples for context. Every word earns its place; there is no redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description sufficiently explains the input format. However, it does not mention what the return value looks like (e.g., a formatted text description), which would be helpful since no output schema exists. Despite this minor gap, the tool is easy to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a title explaining the expected format ('op:<cat>.<name>' or 'type:<TypeName>'), and the description reinforces this with concrete examples. This adds clarity beyond the bare schema and leaves little ambiguity for the single 'path' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Describe' with a clear resource 'Blender operator or type via RNA', and gives concrete path examples ('op:mesh.bevel', 'type:Object'). This clearly distinguishes it from siblings like rna-search (find) or rna-call_operator (execute).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via path format examples, but does not explicitly say when to use this instead of alternatives like rna-search or outliner-describe. There is no mention of exclusions or preferred contexts, making it adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden of behavior. It discloses that stdout is captured and that a 'result' variable can be returned, which is essential for agent expectations. However, it does not mention error handling, side effects, or security implications, though these might be inherent to a code execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two clauses, avoiding any filler. It front-loads the action and immediately states the output contract, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic code execution tool, the description covers the essential inputs (code) and outputs (stdout, result). It does not explain use cases, but the tool is self-explanatory given its simplicity. The lack of an output schema means the description must convey return info, which it does. Missing error handling details slightly reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is reported at 0%, meaning the description contributes minimal parameter guidance. The schema's property title itself describes the 'code' parameter, but the overall description does not add semantic details beyond mentioning the result variable. Given the schema already provides a useful title, this meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs Python inside Blender, with a specific verb ('Run') and resource ('Python inside Blender'). It also distinguishes from siblings like script-run_file (which runs an external file) by implying arbitrary inline code execution. The output behavior is explicitly mentioned, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for arbitrary Python execution but does not explicitly state when to prefer this over alternatives like script-run_file or script-reload. No exclusions are given, but the lack of explicit context or alternatives keeps this at a basic level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. The verb 'List' clearly implies a read-only, non-mutating operation, and the description specifies what the output will contain, which is sufficient for this simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool — no parameters, no output schema, low complexity — the description fully covers what it returns and what the agent should expect. No additional context is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is already complete with 100% coverage. Per the baseline for zero-parameter tools, the description does not need to add parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action — 'List' — and a specific resource, 'craft domains', while also specifying the exact output ('how many operations each exposes'). This distinguishes it from sibling capabilities tools like capabilities-tools or capabilities-search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not say when to use this tool vs capabilities-tools, capabilities-describe, or capabilities-search, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 of disclosing behavior. It explicitly notes 'read-only', which is a key safety behavioral trait, but it does not elaborate on return format, error handling, or any limitations. This is sufficient for a simple inspect operation but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short yet includes the verb, resource, and a safety qualifier. Every word earns its place, but it is slightly terse, missing a touch of elaboration on what 'modifier stack' yields (e.g., names, details). Still, it is efficient and structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter and no output schema, the description provides adequate context. It clearly states the action and object, and the read-only hint covers the main behavioral concern. It does not describe the return format, but for a list of modifiers, this is a minor omission given the surrounding sibling tools that imply typical output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one optional parameter, and the schema description coverage is 0%, so the tool description must compensate. The description 'of an object' signals the parameter's role, and the schema title 'Object to inspect (defaults to active)' adds default behavior, but the tool description itself does not describe the parameter meaning or default. It provides marginal benefit beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('modifier stack of an object'), and the parenthetical '(read-only)' clarifies safe operation. It clearly differentiates from mutation siblings like modifiers-add or modifiers-apply by focusing on read-only inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The '(read-only)' qualifier provides clear context that this tool is for inspection, not modification, which distinguishes it from mutation tools. However, it does not explicitly name alternative tools or state 'use this when you need to inspect modifiers without changing them,' so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states a read-only operation by using 'List', and the qualifier 'loaded' adds context that only currently loaded clips are included. However, it does not disclose any potential side effects, performance implications, or state requirements beyond the obvious. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple list operation and contains all essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is fully adequate. It clearly states what is listed and that it concerns loaded clips. No additional context is required for an agent to select or invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter specifics, but none are needed since the schema is empty and coverage is 100% (trivially). The description's reference to 'loaded' implicitly scopes the operation, adding slight semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List loaded movie clips' uses a specific verb ('List') and a specific resource ('loaded movie clips'), which clearly distinguishes it from sibling tools like tracking-clip_load (which loads clips) and tracking-report (a broader report). The purpose is unambiguous and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (if you want to see loaded clips, use this tool) but provides no explicit guidance on when to use it versus alternatives such as tracking-report or tracking-clip_load. No exclusions or context are given, so it relies on the name and domain to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. The verbs 'list' and 'report' clearly communicate a non-destructive query behavior, and no side effects are hidden. It does not describe return format or ordering, but for a zero-parameter read tool this is not 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, parallel clauses with no filler or redundant detail. It is front-loaded with the primary action and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial zero-parameter query tool, the description covers the two things the agent needs to know: what it lists and what it reports. It does not specify output shape or whether the active workspace is separately highlighted, but the complexity is low enough that this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema is fully covering by vacuity. The 0-parameter baseline of 4 applies since no parameter descriptions are needed or possible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states two concrete behaviors: listing workspaces and reporting the active workspace. This distinguishes it from sibling workspace actions like app-workspace_set by focusing on read/query operations rather than modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the verbs 'list' and 'report,' but the description does not explicitly say when to prefer this tool over alternatives or when not to use it. No alternatives such as app-workspace_set are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the safety disclosure burden and does so via the explicit '(read-only)' qualifier. It also clarifies the 'all objects' behavior when the object parameter is omitted. It could add more about return shape or ordering, but for a simple list operation the key behavioral trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every clause adds value: the action, the resource, the optional scoping, and the read-only nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only listing tool with no output schema, the description is reasonably complete. It covers the action, scope semantics, and safety. It does not describe the return format or checkpoint details, but those are not critical for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the tool description must explain the parameter. It does state that the object is optional and that omitting it lists checkpoints for all objects, mirroring and reinforcing the schema title. With only one optional parameter, this is sufficient compensation for the lack of schema-level documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'List stored checkpoints for an object, or all objects'. It also distinguishes this from siblings like session-checkpoint and session-revert by framing it as a listing operation, not a create/revert action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by noting the optional object parameter and the read-only nature, but it does not explicitly state when to prefer this tool over session-checkpoint or session-revert. There is no guidance on prerequisites or context, though the simple tool shape makes the implied usage fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently states that it lists add-ons and includes their enabled and loaded state, indicating a read-only operation with no side effects. This is sufficient for a simple listing tool, though it doesn't specify whether built-in vs. third-party add-ons are included or if there are any filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that fully conveys the tool's function without any redundancy or unnecessary detail. It is efficiently structured and front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema, no annotations), the description fully covers what the tool does and what it returns. There are no missing behavioral aspects or edge cases that need documentation for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. The description correctly adds no parameter details since none exist. Per the rubric, a baseline of 4 is appropriate for tools with no parameters, as no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available Blender add-ons with enabled and loaded state' clearly states the action (list), the resource (Blender add-ons), and the specific data provided (enabled and loaded state). This distinguishes it from sibling tools like app-addon_enable or app-addon_disable, which perform mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for inspecting add-on states but does not explicitly compare to alternatives or specify when to use it (e.g., before enabling/disabling). While the purpose is obvious from the name, there is no explicit guidance on when to choose this over related tools like app-addon_enable or app-preferences_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool's behavior precisely: what output to expect for each invocation style. While it doesn't explicitly state it's read-only or side-effect-free, the verb 'Navigate' and the nature of returning maps/schemas clearly imply a safe, non-destructive operation, and the behavior is fully described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with purpose, and uses a compact notation to convey three modes. Every word earns its place—no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior for this simple tool with two optional parameters. It explains the three call patterns and what each returns. Minor gaps: it doesn't specify what happens if both domain and name are provided, nor the exact structure of the domain map or schema, but those are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It explains both parameters: domain is a 'Craft domain from the no-args map' and name is an 'Exact tool name for a full input schema', even providing examples. This is helpful and goes beyond the schema titles, though the schema titles already give some context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Navigate THIS server's tools' and specifies three distinct modes (no args, {domain}, {name}), precisely defining the tool's purpose. It distinguishes from siblings like capabilities-search and capabilities-describe by focusing on browsing/hierarchy rather than searching or specific descriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage patterns: 'no args -> domain map; {domain} -> its tools; {name} -> one schema'. This guides when to call with different parameters. However, it doesn't explicitly compare to alternatives (e.g., when to use capabilities-search instead), so it loses a point for lacking exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that cancellation is 'cooperative' and 'takes effect at the operation's next check', which is critical for understanding the non-immediate nature. It does not mention potential side effects or error cases, but the key behavior is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys all essential information without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the core behavior and source of the id. It lacks details on return values or error conditions, but these are less critical for a cancel-request operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a title and example for op_id, with 0% description coverage. The tool description adds meaning by stating 'by id from system.operations', telling the agent where to source the id. This compensates for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Request cooperative cancellation') and the resource ('a queued/running operation'), and specifies the origin of the id ('by id from system.operations'). This distinguishes it from sibling tools like system-operations and system-health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates the target state ('queued/running') and references where to find the id ('system.operations'), giving clear context. It doesn't explicitly mention when not to use it (e.g., for completed operations), but the state restriction implies 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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/OhaoTech/niua-blender-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server