Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the full burden of behavioral disclosure. It simply says 'Export the scene as FBX' without detailing side effects such as file creation, overwriting behavior, or whether the operation is asynchronous (relevant given the presence of job-related sibling tools). The description adds minimal behavioral context beyond the core action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, stating the core action first and the parameter guidance second. Both sentences serve a purpose and there is no fluff. It could be slightly more informative without becoming verbose, but as written it is efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

In the context of a named export operation with no annotations and an output schema (unknown content), the description is incomplete. It lacks information about potential long-running behavior (relevant given job tools), file overwrite semantics, and any prerequisites. An agent would need additional context to use this tool reliably in complex workflows.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. The sentence 'Provide the output file path' clarifies that the `filepath` parameter is the destination path, which is a meaningful addition over the bare schema. However, it does not explain format requirements (e.g., extension, absolute vs. relative) or any constraints. It provides basic semantics but not comprehensive guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Export the scene as FBX') with a specific resource (the scene) and format (FBX). This distinguishes it from sibling export tools like blender_export_gltf and blender_export_obj. The phrase 'as FBX' is unambiguous and directly tells the agent 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus the other export tools (gltf, obj). The description does not mention any conditions or alternatives. An agent is left to infer that FBX is chosen based on format preference, but no explicit guidance or exclusions exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the export operation and the need for a file path, but does not disclose side effects such as file overwriting, whether the export runs asynchronously as a job, or whether the Blender scene 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no filler, and the key action and output format are front-loaded before the parameter instruction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter export tool, the description is minimally viable: it names the operation and the required input. However, with no annotations and no parameter documentation, it leaves practical gaps such as file extension behavior and whether export is a background job, which the sibling job tools suggest may be relevant.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the bare filepath property. It adds only that the filepath is the output destination, which is largely redundant with the property name, and it does not clarify extension conventions (.gltf vs .glb), path absoluteness, or directory requirements.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Export') and resource ('the scene') and explicitly names the target format ('glTF/GLB'), which clearly distinguishes this tool from sibling export tools like blender_export_obj and blender_export_fbx. An agent can immediately identify when this tool is the right one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: choose this tool when the scene should be exported as glTF/GLB. However, it gives no explicit guidance about when to prefer this over the sibling export tools (OBJ/FBX), nor any exclusions or context such as texture embedding or binary vs. JSON output.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 does not disclose whether it overwrites existing files, requires a loaded scene, creates directories, or has any side effects. For a mutation tool that writes a file, this is a significant gap 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with zero waste. The primary action is front-loaded, and the required parameter is explicitly referenced. This is appropriately concise for a simple export tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and an output schema (per signals), the description is minimally adequate but lacks contextual guidance for selecting it among siblings and does not detail side effects or prerequisites. An agent could call it, but a richer description would improve correct usage in varied scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description mentions the filepath parameter ('Provide the output file path'), which aligns with the schema, but adds no meaning beyond that. It does not clarify path formats (absolute vs relative), allowed extensions, or overwrite behavior. The schema already had the parameter title, so the description provides minimal incremental value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Export the scene as OBJ') with a specific resource (the scene) and format (OBJ). It distinguishes from sibling export tools (gltf, fbx) by explicitly naming the format, so an agent can tell it apart without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use OBJ over the alternative export formats (gltf, fbx). It simply states the action without explaining the context, trade-offs, or exclusion criteria. An agent would have to infer the appropriate choice from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 redoes an operation, but it does not clarify that this mutates Blender state, what happens when there is no operation to redo, or whether it can fail or be a no-op.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence that front-loads the action and target. There is no filler or redundant wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-argument command, the description captures the core intent, but it leaves out practical context such as redo-stack availability, failure behavior, and the fact that the operation changes the Blender scene state.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and schema description coverage is 100% by virtue of the empty properties object. There is nothing for the description to add about parameter meanings or formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states exactly what the tool does: it redoes the last undone operation in Blender. It uses a specific verb and resource, and it is clearly distinct from the sibling blender_history_undo by direction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'last undone operation' implies that this should be used after a prior undo, but the description does not explicitly state when to use it versus blender_history_undo or mention edge cases like having no redo history.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the burden. 'Undo the last operation' conveys the core state-changing behavior but lacks any detail on side effects, history constraints, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence, no filler, and the core behavior is front-loaded. It is as concise as a zero-parameter undo tool needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, parameterless undo operation paired with blender_history_redo, the description fully covers when and what it does. No further context is needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is nothing additional the description needs to explain about arguments. The baseline for zero-parameter tools applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('Undo') and identifies the exact resource ('the last operation in Blender'). It is immediately distinguishable from the sibling blender_history_redo tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to call this vs. alternatives such as blender_history_redo, or about scenarios like empty undo stacks or which operations are covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavior. It does disclose that the tool sets a cancel event and that scripts checking it will stop gracefully, which is valuable. However, it does not mention potential side effects, whether the operation is reversible, or error conditions (e.g., job not found). The disclosure is present but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no fluff. The primary action is front-loaded, and the second sentence adds a useful behavioral detail. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one parameter and an output schema exists, so the return format does not need to be described. The description covers the main behavior and the mechanism. Missing details like error handling for already-completed jobs are minor given the tool's simplicity and the presence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the job_id parameter. The description only implies that job_id identifies the job to cancel; it does not explicitly explain the parameter's meaning, format, or how to obtain it (e.g., from blender_job_list). This leaves the parameter under-specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb 'Cancel' and a specific resource 'a running or queued async Blender job', clearly distinguishing it from siblings like blender_job_list and blender_job_status. It also explains the mechanism (setting __cancel_event__), which is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly indicates the tool is for cancelling async jobs, which gives context for when to use it. However, it does not explicitly mention when not to use it (e.g., if the job has already completed) or mention alternatives. It is clear enough for an agent to infer usage, but lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It states it lists jobs but does not disclose whether this is read-only, any ordering, or whether it includes completed jobs. It's a simple read operation, so the lack of detail is acceptable, but it doesn't explicitly assure 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise sentence that front-loads the verb and resource. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a list operation with an output schema. It specifies what fields are returned, and since there are no parameters, nothing else is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is trivially 100%. The description adds no parameter-specific information because none exist, and that's appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists async Blender jobs and specifies the fields (IDs, statuses, creation timestamps). This distinguishes it from sibling tools like blender_job_status (which likely retrieves a single job) and blender_job_cancel (which cancels).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing all jobs but does not explicitly mention when to use it versus sibling tools. For example, it doesn't state that blender_job_status should be used for a specific job. However, the purpose is clear enough that an agent can infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavior disclosure. It explains that the call returns status values, timestamps, result, stdout, stderr, and error, and that it is a polling call after an async launch. It could more explicitly say it is read-only and does not modify the job, but the wording makes that reasonably clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences: the action, the return shape, and the use trigger. Every sentence adds information, and the most important guidance appears early.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter status tool with an output schema, the description covers the parameter, the return contents, and the intended polling scenario. It is complete enough for correct invocation, though it would benefit from an explicit note about read-only behavior and job-result persistence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only labels the parameter as 'Job Id', so the description adds useful meaning by tying job_id to an async job started by blender_python_exec_async. It does not explicitly state that job_id is returned from that tool, but the relationship is strongly implied and sufficient for a single-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and resource ('async Blender job'), and it clearly distinguishes this from sibling tools by addressing a single job's status rather than listing or canceling jobs. The link to blender_python_exec_async makes the intent unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use the tool: poll after starting a job with blender_python_exec_async. It does not explicitly exclude alternatives or name a sibling like blender_job_list, but the guidance is clear and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are providedhare, and the description does not disclose side effects such as replacing an object's current material, requiring the object/material to exist, or modifying the scene state. A one-line description is too thin for a mutating operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no filler or redundant restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the tool's simplicity, the description omits identifier formats, prerequisites (both entities must exist), and effects (e.g., assignment replaces existing material). With no annotations and no parameter detail in the schema, the description is not self-sufficient for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only gives string names 'object' and 'material' with no descriptions. The description adds only 'existing' and does not clarify whether parameters are names, IDs, paths, or how to reference the object/material in the Blender scene.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Assign') with a clear resource ('material') and target ('object'), and the qualifier 'existing' distinguishes this from material creation. It clearly separates the tool from siblings like material_create and material_set_color.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'existing material' implies this is for assigning already-created materials, not creating new ones, but it does not explicitly state when to prefer this over alternatives or exclude other actions. Guidance is only implied, not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It says a material is created but does not disclose whether the new material is auto-assigned to any object, whether it becomes active, whether names must be unique or get suffixed, or any side effects. Only the color value range (0-1) 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core action and the optional modifier second. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. For a mutation tool with zero annotations, however, the description omits behavioral essentials such as uniqueness handling, auto-assignment, and prerequisite state, leaving meaningful gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description usefully explains the color format ([r, g, b] or [r, g, b, a], values 0-1), which the schema does not. However, the 'name' parameter and its default ('Material') are left entirely to the schema, so the description only partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Create a new material') that is clearly distinct from siblings like blender_material_list, blender_material_assign, and blender_material_set_color. It does not explicitly name a sibling, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus blender_material_set_color or when a material must already exist before assigning it. The only hint of context is the optional color, which is a parameter note rather than usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation, which is a useful signal, but the description does not mention any side effects, potential errors, or return format. For a simple list tool, this is minimally adequate but lacks explicit behavioral guarantees.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no filler words. It is appropriately front-loaded with the verb and resource, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is extremely simple with no parameters and an output schema present. The description fully conveys the tool's purpose, and the output schema covers return values. Nothing an agent needs to correctly invoke this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema description coverage is 100% (empty properties). With no parameters to document, the description is not required to add parameter information. The baseline of 4 applies here as no compensation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states an explicit verb ('List') and resource ('all materials in the Blender file'), making the tool's purpose unambiguous. It clearly distinguishes from sibling material tools like create, assign, set_color, etc., which involve different actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context (listing materials) but does not explicitly mention when not to use it or alternatives. However, given that it is the only material-listing tool among siblings, the intended usage is obvious. No exclusions or alternative references are stated, but the read-only nature is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 confirms this is a mutation of an existing material's color but omits whether the material must exist, whether it errors or creates one, and whether the change is undoable (a relevant concern given the sibling blender_history_undo).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and followed by the one piece of format detail that matters. Nothing is wasted and it is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. However, for a two-parameter mutation tool with zero annotation support, the missing preconditions (does the material need to exist?) and the undefined 'name' parameter leave gaps an agent would have to discover by trial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does this well for 'color' by specifying the accepted formats ([r,g,b] or [r,g,b,a]) and the 0-1 value range, but leaves 'name' completely unexplained — presumably a material name, but the agent must infer this.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (set) plus resource and property (base color of a material), which is immediately actionable. It implicitly distinguishes itself from siblings like blender_material_set_texture and blender_material_assign, though it never names or contrasts them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no alternatives mentioned, and no prerequisites stated. It does not say whether the material must already exist, whether 'name' refers to an existing material, or what happens if it does not.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description has the full burden of behavioral disclosure. It only states the action ('set') and the required input, but provides no details about side effects, prerequisites (e.g., whether the material must already exist), error behavior for invalid file paths, or whether the operation is reversible. This is a significant gap for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with zero redundancy. It front-loads the action and immediately specifies the required input, achieving maximum clarity in minimal words. There is no waste or unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple mutation tool with two parameters, the description is too sparse. It does not state prerequisites (e.g., the material must exist), nor does it explain the meaning of the 'name' parameter. While an output schema exists, its content is unknown, and the description does not cover error cases or expected behavior. Many critical details are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides some meaning for 'filepath' by saying 'provide the file path to the image,' but it does not clarify what 'name' refers to (likely the material name), leaving that parameter completely unexplained. This partial compensation is insufficient for the agent to use parameters correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'set an image texture as the base color of a material.' It distinguishes itself from siblings like blender_material_set_color by explicitly mentioning texture rather than color, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives. It does not mention blender_material_set_color, nor does it explain when a texture is appropriate over a simple color. The usage context is entirely implied, leaving the agent to infer when to select this tool from the siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full responsibility for behavioral disclosure. It states the fundamental action and valid mesh types, but it does not mention side effects, such as whether the object is added to the active scene/collection, whether it overwrites an existing object with the same name, or whether it activates the new object. This leaves the operation's real-world consequences under-disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long and front-loads the primary action. It uses a clean, efficient structure: stating the operation first, then the supported variations. There is no clutter, redundant phrasing, or unnecessary detail, making the structure concise and effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has four optional parameters, zero schema descriptions, and no annotations, the description leaves substantial gaps in behavioral and parameter semantics. Though an output schema exists, it does not resolve the missing side-effect information, prerequisite guidance, or parameter semantics. The description is too sparse to fully support a correct invocation in all cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It does provide meaning for mesh_type by listing allowed values (cube, sphere, cylinder, plane, cone, torus), but it gives no semantic insight into name, size, or location. For example, it does not clarify size units, location frame of reference, or behavior of null defaults, so the parameter domain is only about 1/4 discussed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Create a new mesh object in Blender') and enumerates the supported mesh types, which makes the tool's core purpose unambiguous. However, it does not explicitly distinguish itself from the sibling tool blender_object_duplicate, which also creates an object in the scene, so the differentiation is left to the agent's inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance about when this tool should be chosen over alternatives, such as blender_object_duplicate for duplicating existing objects or blender_material_create for creating materials. It also omits any mention of the current scene state or prerequisites for correction, so the agent is left without contextual guidance on its appropriate use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not disclose whether deletion is permanent, whether it affects child objects, whether undo is available, or what happens if the object does not exist. For a destructive operation, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the action and resource. It earns its place with no wasted words, though it could add a brief note on irreversibility without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no annotations and no output schema details, the description is too thin. It does not mention whether deletion is recursive, whether it can be undone, or what the return value indicates. An agent needs more context to safely invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but there is only one parameter ('name') whose meaning is self-evident from the description ('by name'). The description adds minimal semantic value beyond the schema, but the parameter is simple enough that the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Delete') and resource ('object from the Blender scene by name'), clearly distinguishing it from sibling tools like blender_object_create or blender_object_duplicate. It lacks explicit differentiation from other deletion-like tools, but no other delete sibling exists, so the 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives, such as blender_object_duplicate or blender_object_get_hierarchy. It does not mention prerequisites (e.g., object must exist) or consequences (e.g., irreversible). Usage context is entirely implied by 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.

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 'duplicate' without explaining what happens to the original, whether the duplicate is selected, or what default name is used when new_name is omitted. This is a significant transparency gap 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the core action front-loaded Alert. No fluff or repetition of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fails to explain the role of the required 'name' parameteraine, the naming behavior when 'new_name' is omitted, or any effects (e.g., selection, undo stack). An agent would have to infer the source object naming convention from other tools or trial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds only minimal meaning beyond the schema: it clarifies that a new name is optional. It does not explain that `name` identifies the source object to duplicate or how duplicate names are handled. With 0% schema coverage, this leaves a required parameter semantically ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('duplicate') and resource ('an object in the Blender scene'), plus the optional naming behavior. It is clearly distinct from siblings like create/delete, though it does not explicitly state that 'name' identifies the source object.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives such as blender_object_create or blender_object_delete, nor any prerequisites or selection requirements. The context of use is implied but not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations to lean on, so the description carries the full burden. It discloses the key behavioral switch (subtree vs. full hierarchy) and implies a read-only operation. It does not spell out naming/format rules or error behavior, but for a hierarchy getter the essential 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core purpose, then the conditional behavior. No filler or redundancy. The most important information appears first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with an output schema, the description covers the essential behavior and parameter semantics. It could mention what happens for a nonexistent object or whether the subtree includes children recursively, but that gap is minor given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only declares a nullable 'name' with no description, but the tool description explains exactly how it changes behavior: providing it returns the subtree, omitting returns the whole hierarchy. This adds meaning well beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: "Get the parent/child hierarchy of objects." It also names the exact conditional behavior (subtree vs full scene), which makes its purpose unmistakable and visually distinct from sibling tools like list or material tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description tells the agent exactly when the optional parameter matters: providing a name returns a subtree, omitting it returns the full scene hierarchy. It does not explicitly exclude alternative tools, but the two-branch guidance is clear enough for selection and invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 labels the operation as 'Get' (implying a non-destructive read), but it does not mention behavior if the object does not exist, what coordinate space the values are returned in, or whether it reflects the current scene state. These are meaningful gaps for a Blender mutation-heavy environment.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is 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, and every word contributes. There is no filler, repetition, or redundantly restating the title or inputs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter getter, the description gives the purpose, but the surrounding ecosystem (27 Blender tools including creating/deleting/translating/rotating objects) makes it valuable to say 'scene objects ' or point to a listing tool. Since an output schema is present, return-value documentation isn't required, so a 3 is appropriate: adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides only a bare string parameter 'name', so the description's 'by name' adds minimal semantics by tying the parameter to the object identifier. It still does not explain name format, uniqueness, or how to discover valid names, which is needed when schema coverage is 0%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and precisely names the resource ('Blender object') plus the exact data fields ('position, rotation, and scale'), and shows the input key ('by name'). This lets an agent distinguish it from siblings like blender_object_get_hierarchy or blender_scene_list_objects with no extra effort.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is clearly implied: call this tool when you need an object's transform values, using the object's name as input. However, there is no explicit 'when to use vs alternatives' or mention of how to obtain the required name (e.g., using blender_scene_list_objects), leaving some guidance gaps.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 adds useful detail about the angle format and degree default, but it does not explicitly state what happens if degrees is false or clarify that this overwrites the object's existing rotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no filler. It front-loads the primary action and immediately provides the essential input format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter tool with an output schema, the description is adequate but minimal. It gives enough to invoke the call, but lacks explicit coverage of radians when degrees is false and any behavior around invalid or missing objects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains rotation as [x, y, z] angles and notes the degree default, which maps to the degrees parameter. However, the name parameter is not explained, and degrees: false semantics are only implied rather than stated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Set the rotation of an object.' This clearly separates it from sibling transform operations like translate and scale, and the input format [x, y, z] angles reinforces the action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to use this tool versus alternatives such as blender_object_translate or blender_object_scale. The description only states what it does, not when it should be selected.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility for behavior disclosure. It only states that the operation sets scale; it does not clarify whether the scale is relative or absolute, whether local or world transforms are affected, or whether children are impacted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences deliver the operation and the required input format with no filler. The key information is front-loaded in the first sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple setter with only two parameters and an output schema, this is mostly sufficient. The main gaps are behavioral details like absolute vs relative scaling and failure behavior, which matter because no annotations are provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds the useful clarification that scale is provided as [x, y, z], which the bare schema does not convey. However, it omits semantics such as units, scale factor meaning, and whether values apply in object or world space.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb and resource: 'Set the scale of an object.' This is distinct from the sibling transform tools by naming 'scale' as the target property, though it does not explicitly contrast itself with translate or rotate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool over rotating or translating, and no mention of whether the scale is absolute or cumulative. The description implies usage through the parameter format but does not state context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so the description carries the full behavioral burden. It never states the coordinate space (world vs. local vs. parent-relative), units, whether the move is undoable, or what happens on an out-of-range value. For a mutation tool with zero annotation coverage this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero waste, with the action front-loaded and the parameter rule immediately after. Ideal size for this tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. However, for a 3-parameter transform tool with no annotations and 0% schema coverage, the core ambiguity of the coordinate space is left unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does partially by defining 'location' as absolute and 'offset' as relative plus their mutual exclusivity. It says nothing about the coordinate frame, units, or expected vector length for either parameter, leaving real ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Move an object.' An agent can immediately tell this is the translation tool and not rotate/scale/duplicate. It does not name any sibling explicitly, but the resource is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit parameter-mode guidance: use 'location' for absolute positioning, 'offset' for relative movement, never both. Missing any when-to-use-vs-alternatives guidance (e.g., versus blender_python_exec for complex transforms), but the mode selection rule is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses the execution environment (bpy, mathutils, args dict), the __result__ return convention, and that stdout/stderr and duration are captured. It does not mention permissions, side effects on the open scene, or timeout behavior, which for an arbitrary-code-execution tool would be worth stating.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then the input contract, return shape, transport options, and the async alternative in dense, waste-free sentences. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 7-parameter code-execution tool with an output schema (so return format need not be restated), the description covers the essentials an agent needs to invoke it. The three undocumented parameters (blend_file, factory_startup, timeout_seconds) are the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and there are 7 parameters, so the description must compensate and largely does: it explains code, script_path, args, and the transport enum with both mode meanings. blend_file, factory_startup, and timeout_seconds are left undocumented, so it falls short of full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Execute a Python script in Blender's context') plus the synchronous execution scope, which cleanly separates it from blender_python_exec_async named in the same description. An agent can identify the tool's job without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit mutual-exclusion guidance ('provide either code or script_path, not both'), explains the transport choice with the meaning of both enum values, and routes long-running work to blender_python_exec_async. When-to-use and alternatives are both covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so: it discloses immediate job_id return, main-thread blocking on the default bridge transport, the __cancel_event__.is_set() cancellation hook, and the headless alternative. This is rich behavioral context beyond a bare signature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Five tight sentences, front-loaded with purpose and lifecycle, then usage guidance and the transport caveat. Every sentence adds a distinct fact; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return shape need not be explained, and the description still states that a job_id is returned immediately. Lifecycle, cancellation, and the blocking/headless tradeoff are all covered, which is what an agent needs to call this safely and correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and there are 7 parameters, so the description must compensate. It documents the transport enum values and the practical effect of each ('bridge' blocks the UI, 'headless' runs a separate background process), and delegates the shared arguments to blender_python_exec. The only gap is that the shared parameters are not restated, which the explicit delegation largely covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb and resource ('Start a long-running Python script in Blender asynchronously') with the key differentiator against the synchronous sibling blender_python_exec stated up front. An agent can distinguish it from blender_python_exec and the job-management tools from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the polling and abort siblings (blender_job_status, blender_job_cancel) and gives concrete use cases (fluid baking, rigid body simulation, heavy scene generation). It also states the transport tradeoff and routes to transport='headless' for a non-blocking path.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden, and it does disclose that 'headless' spawns a separate background Blender process while 'bridge' targets the live session. However, it says nothing about whether rendering is blocking or returns a job handle, nor about timeouts or failure modes for a long-running render.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and followed by the mode-selection detail. Every clause carries information; nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, but the presence of sibling job tools (blender_job_status, blender_job_list, blender_job_cancel) suggests renders may be asynchronous, and the description never says whether this call blocks or hands back a job id. That is a meaningful omission for a 7-parameter render tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for 7 parameters, so the description must compensate. It names output path, frame range, engine, transport, and the role of blend_file, but leaves factory_startup and the frame_start/frame_end split undocumented, so it only partially fills the gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Render an animation') and is immediately distinguishable from the sibling blender_render_still. The follow-on sentence clarifies the two operational modes without muddying 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes between transport='bridge' (live add-on session) and transport='headless' with a blend_file (separate background process), which is the key decision an agent must make. It does not state when to prefer this tool over blender_render_still, though that distinction is self-evident from the names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It reveals the transport model and engine choices, but omits key operational facts: that rendering writes/overwrites a file at output_path, whether headless requires blend_file to exist, and that this is a blocking or job-producing operation. Useful but incomplete for a no-annotation 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three front-loaded sentences with no filler; the core action comes first and the transport fork follows. Tight and appropriately sized, though it could be organized to state the mode-selection rule even more prominently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. However, with 7 undocumented parameters and no annotations, the description should say more about side effects (file writing), factory_startup, and headless prerequisites. It is adequate for the main path only.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate and it partially does, naming output_path, resolution, engine, transport, and blend_file. It even adds engine value examples (BLENDER_EEVEE, CYCLES) the schema lacks, but it ignores factory_startup entirely and gives no format/default detail for the others.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Render the current scene as a still image'), and the word 'still' implicitly separates it from the sibling blender_render_animation. An agent can distinguish it from the other render/export siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent between the two transport modes: bridge for the live add-on session, headless with blend_file for a separate background process. That is real when-to-use guidance for a key fork. It stops short of stating when not to use this tool or how it relates to blender_render_animation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the burden. 'Get information' implies a read-only operation)Skip, but the description does not explicitly disclose side effects, error behavior, or the fact that no scene state 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

One compact sentence, front-loaded with the verb and object, and every word adds information. There is no redundant boilerplate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The simple zero-parameter tool is adequately described for an agent to select it, and the output schema can supply return-type detail. It could be slightly more complete with an explicit read-only note or a hint about when to prefer it over sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description's job is minimal. It does add value by listing the output fields (name, frame range, render engine, resolution, object count), which effectively explains what the tool targets.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get information') and a clear resource ('current Blender scene'), then enumerates the exact fields returned. This fully disambiguates the tool from object-level siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does 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 siblings like blender_scene_list_objects or blender_object_get_transform. The intended use is inferable from the description, but the tool does not state it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It states the read-only nature implicitly through 'list' but does not explicitly confirm that the scene is not modified, nor does it mention error cases or pagination. For a simple read tool this is adequate, but it adds minimal behavioral context beyond the action itself.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, the main action is front-loaded, and every word earns its place. The filter examples are efficient. There is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter) and the presence of an output schema (which covers return format), the description is nearly complete. It lacks only explicit mention of default behavior (e.g., returns all objects when no filter) and exact accepted type values, but these are minor gaps for a list operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only defines 'type' as string/null with no enum or description, giving 0% coverage. The description adds value by listing example values (MESH, CAMERA, LIGHT, EMPTY, CURVE) and the 'etc.' implies more are valid. However, it does not provide an exhaustive list or specify case sensitivity, so it partially compensates for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('List all objects') on a clear resource ('current Blender scene') and notes an optional filter. It is immediately distinguishable from sibling tools like blender_scene_get_info (scene metadata) and blender_object_get_transform (single object transform), so an agent can tell when to use it without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: to enumerate objects in the scene, call this tool. However, it does not explicitly contrast it with alternatives or state when NOT to use it (e.g., when you need object hierarchy, use blender_object_get_hierarchy). The guidance is implicit rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.