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?

With no annotations, the description carries the transparency burden. It clearly states the core behavior (creating a new material) and the optional color initialization, but it does not disclose edge behaviors such as name collisions, whether the material is auto-assigned, or what side effects occur 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.

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

A single, front-loaded sentence states the primary action before giving the optional parameter detail. Every word adds value with no repetition 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?

For a simple creation tool with two optional parameters and an output schema, the description covers the essential purpose and clarifies the color format. Minor gaps remain around duplicate names and whether the material is attached to an object, but these are lower-priority edge 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?

The schema only says color is an array of numbers or null, while the description adds the critical format '[r, g, b]' and value range '0-1'. This directly compensates for the 0% schema description coverage and clarifies the only non-obvious parameter.

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 identifies a specific action and resource: 'Create a new material' and optional initial base color. This differentiates it from sibling tools like blender_material_assign and blender_material_set_color, which target existing materials.

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 when-to-use or when-not-to-use guidance is provided, and no alternative tools are referenced. The intended usage is only implied by the verb 'create'; there is no contextual routing to distinguish it from set_color or assign beyond the name.

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 of disclosing behavior. It states that the operation sets a material's base color, but does not mention side effects, material-existence requirements, or whether existing color/texture values are overwritten.

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, front-loads the action, and adds only the essential color-format constraint. There is no filler or duplication of schema content.

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 two-parameter setter with an output schema and no nested objects, the description covers the critical inputs while remaining compact. It lacks explicit usage/prerequisite guidance, but does not need to explain return values because an output schema exists.

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?

With schema description coverage at 0%, the description meaningfully compensates: it explains that color is an [r, g, b] array with values in the 0-1 range, which is essential for correct invocation. 'Name' is not explicitly clarified, but the tool name and schema property make its role as the material name reasonably clear.

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 names a specific action and resource: 'Set the base color of a material'. This distinguishes it from sibling tools such as blender_material_create, blender_material_assign, and blender_material_set_texture, so an agent can identify it 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?

No guidance is given about when to use this tool versus alternatives or what prerequisites apply (e.g., whether the material must already exist before its color can be set). The intended usage is only loosely implied by the action itself.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It discloses that the operation moves an object and that 'location' means absolute positioning while 'offset' means relative movement. However, it does not mention coordinate space, array length, conflict behavior if both parameters are supplied, or what happens if neither is provided.

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

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

The description is two short sentences with no filler. The main action and the key parameter distinction are front-loaded, and every word earns its place.

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

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

The tool is relatively simple and an output schema exists, so return values do not need description. However, the description leaves gaps around coordinate system, array dimensions, and behavior when both or neither 'location' and 'offset' are supplied. These are relevant for an agent to call the tool correctly.

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

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 add meaning by defining 'location' as absolute positioning and 'offset' as relative movement, which goes beyond the bare parameter names. However, it does not specify the expected coordinate array format, length, or the exclusivity implications clearly enough for fully precise invocation.

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 ('Move an object') and immediately clarifies the two modes of operation: absolute positioning via 'location' and relative movement via 'offset'. This clearly differentiates it from sibling transform tools like rotate and scale.

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 clear usage context by explaining when to use 'location' versus 'offset', which is essential for correct invocation. It does not explicitly mention alternatives like rotate or scale, but 'move' makes the tool's role obvious among the transform 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?

With no annotations, the description carries the full burden of behavioral disclosure. It transparently states the execution is synchronous, that it returns captured stdout/stderr and duration, and that it runs either in a live session or a separate headless process. It does not explicitly warn about potential scene modifications (which is implicit in 'execute a Python script in Blender's context'), nor does it mention timeout behavior, but it covers the most important behavioral aspects for a general exec 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 efficient and well-structured. It front-loads the primary action, then explains input selection, environment, return mechanism, transport modes, and alternatives—all in a logical order with no redundant sentences. Every sentence adds value and contributes to a clear mental model.

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 7 parameters, no annotations, and an output schema that is not provided in the input, the description is fairly complete. It covers the execution model, input modes, return values, transport, and the alternative for long tasks. The only gaps are the semantics of blend_file, factory_startup, and timeout_seconds, and potential error handling details, but these are minor given the overall context.

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 the core parameters: code, script_path, args, and transport, plus the '__result__' mechanism. However, it does not explain blend_file, factory_startup, or timeout_seconds, which remain ambiguous from names alone. Since these are not documented in the schema either, the description only partially compensates for the coverage 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 clearly states the tool's purpose: 'Execute a Python script in Blender's context synchronously.' It specifies the verb (execute), resource (Blender), and the primary input (Python script). It also distinguishes itself from the async sibling by name and condition ('For long-running tasks like baking, use blender_python_exec_async'), so an agent can easily differentiate it from other Blender 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 explicitly gives usage conditions: provide either 'code' or 'script_path', not both; explains the 'args' dict; specifies transport options ('bridge' vs 'headless'); and directly names the alternative for long-running tasks. It even mentions the '__result__' convention for return values. This is comprehensive guidance that leaves nothing to inference.

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. It discloses that execution is asynchronous, returns immediately, and supports cancellation detection via '__cancel_event__.is_set()'. It also hints at heavy resource use via 'long-running' and 'heavy scene generation'. However, it does not explicitly warn about potential side effects on the Blender scene or state that it modifies the scene, which is implied by script execution. This is a minor gap given the context.

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, well-organized paragraph that front-loads the core purpose, then covers the workflow, cancellation mechanism, ideal use cases, and a configuration tip. Every sentence adds value with no 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?

For a long-running async execution tool, the description covers the full lifecycle: what it does, how to obtain the job_id, how to poll and cancel, how to detect cancellation in the script, when it is appropriate to use, and a key configuration option. An output schema exists (though not shown) and the description already mentions the immediate return of job_id, which is sufficient. Nothing essential is missing for an agent to use the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meanings. It only mentions transport='headless' and defers to 'Same parameters as blender_python_exec'. This cross-reference is helpful only if the agent already knows the sibling tool's schema. No direct explanation of code, script_path, blend_file, timeout_seconds, or other parameters is provided, leaving the agent to infer or look elsewhere.

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?

Clearly states it starts a long-running Python script asynchronously, distinguishing it from the synchronous blender_python_exec. The verb 'start', resource 'Python script in Blender', and mode 'asynchronously' are all explicit, and the immediate return of a job_id is highlighted.

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?

Provides explicit guidance on when to use it ('Ideal for fluid baking, rigid body simulation, or heavy scene generation'), how to manage the job (poll with blender_job_status, abort with blender_job_cancel), and a specific usage tip (transport='headless' for background process). Clearly routes the agent to the appropriate workflow.

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 discloses the two transport modes and their implications (live add-on session vs separate background process), which is useful behavioral context. However, it doesn't mention whether rendering is blocking or async, how long it might take, or what the output schema contains.

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

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

Two sentences with no fluff. The first sentence states the core action and optional parameters; the second provides the key transport decision. It's front-loaded with the action and scoped efficiently.

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 has 7 parameters, 0% schema coverage, and no annotations, so the description must do heavy lifting. It covers the main parameters and the transport modes, but doesn't explain factory_startup, the meaning of the default output_path '//render_', or what the output schema contains. For a rendering tool that may run long jobs, more context about blocking behavior would help.

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 mentions output path, frame range, and render engine, which maps to output_path, frame_start/frame_end, and engine parameters. However, it doesn't explain transport, blend_file, or factory_startup beyond the transport mention. The description adds some meaning but leaves several parameters unexplained.

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 renders an animation, with optional output path, frame range, and render engine. It distinguishes itself from blender_render_still by specifying 'animation' as the resource, though it doesn't explicitly name the sibling.

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 explicit guidance on when to use transport='bridge' vs transport='headless', which is a key usage decision. It doesn't explicitly state when to use this over blender_render_still, but the animation vs still distinction is implied by the tool name and description.

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

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 two execution modes (bridge vs headless) and that headless requires a blend_file, which is useful behavioral context. However, it does not disclose what happens to the current scene in bridge mode, whether the render is blocking or async, or what the output schema contains. The description adds some value but leaves important behavioral details unstated.

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 with no filler. The core action is front-loaded, and the transport guidance is packed efficiently. It could be slightly more structured (e.g., separating parameter notes from usage modes), but it 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 has 7 parameters, no annotations, and an output schema, but the description covers only the main action and transport modes. It does not explain factory_startup, the meaning of the default output path '//render.png', or what the output schema contains. For a render tool with two distinct execution modes, the description is adequate but not 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?

Schema description coverage is 0%, so the description must compensate. It does mention output path, resolution, and render engine, which maps to output_path, resolution_x/resolution_y, and engine. However, it does not explain transport, blend_file, or factory_startup beyond the transport/blend_file usage note. The description adds partial meaning but leaves several parameters (factory_startup, resolution defaults) unexplained.

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 ('Render') and resource ('the current scene as a still image'), and distinguishes itself from the sibling blender_render_animation by specifying 'still image'. It also names the two transport modes, which clarifies the tool's scope beyond a generic render call.

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 explicitly tells the agent when to use each transport mode: use transport='bridge' for the live Blender add-on session, or transport='headless' with blend_file='/path/to/file.blend' to render in a separate background Blender process. This is clear usage guidance that also implies the alternative (blender_render_animation) is for animations, not stills.

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.