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, and it only covers parameter formats. It never states whether the object is persisted to the scene, what happens on a name collision, whether the operation is undoable, or whether it requires an active/live Blender connection. For a scene-mutating tool this is a substantial 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 purpose sentence is front-loaded and the primitive list, though long, is high-value enumerable data. The location/scale/rotation unit clause is compact and earns its place; only minor tightening is possible.

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, and the primitive/unit documentation covers the core calling path. But for a 6-parameter mutation tool with zero schema coverage and no annotations, the missing name/collection_name semantics and absent usage context leave it adequate rather than 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 usefully enumerates the 13 valid primitive_type values (better than the schema, which declares only a default) and specifies that location/scale are 3D floats and rotation is in degrees. However, name and collection_name remain completely undocumented in both places.

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 ('Creates a new 3D primitive or entity in the Blender scene') and the object classes it produces. It implicitly contrasts with blender_modify_object/blender_inspect_object through the word 'creates', but never names a sibling or draws the boundary explicitly, so it falls short of a 5.

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

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

There is no when-to-use guidance, no prerequisites (e.g. whether a Blender session must be running), and no mention of alternatives such as blender_modify_object for editing existing objects. The agent must infer all routing from the name alone.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the execution environment ('bpy' runtime) and the captured outputs (stdout, stderr, a variable named 'result'), which is genuinely useful. However, it says nothing about the safety profile of arbitrary code execution — whether scene changes are irreversible, whether the script can crash Blender, timeouts, or whether errors raise versus return.

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 compact sentences with no filler, and the core action is front-loaded ahead of the use-case list. The final 'Ideal for...' sentence is somewhat generic but still earns its place as routing guidance.

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, and the single required parameter is simple. The description covers purpose, environment, and capture behavior; the remaining gap is the absence of any warning about the destructive potential of arbitrary script execution.

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 single 'script' parameter has no schema description, so the description must compensate. It partially does by defining the execution context (bpy) and the 'result' capture convention, which shapes how the script string should be written, but it adds no format, size, or content constraints.

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 verb and resource: executing an arbitrary Python script in Blender's 'bpy' runtime. The listed use cases (procedural modeling, rigging, custom automation) implicitly separate it from the narrow siblings like blender_create_object, though no sibling is named 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?

'Ideal for procedural modeling, complex operations, rigging, or custom automation' gives a usage context, but these categories overlap with dedicated siblings such as blender_create_object and blender_manage_modifiers. It never states when to prefer this escape hatch over a structured tool, nor any exclusion.

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 behavioral burden. It reveals that exports can be scoped to selected objects or the entire scene, which is useful. However, it does not disclose what happens on failure, whether it overwrites existing files, permission requirements, or the fact that filepath must be provided. It adds some context but is incomplete for a mutation tool.

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

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

The description is extremely concise and front-loaded: the first sentence states the core action, followed by two bullet-like lines clarifying key parameters. Every sentence adds value without 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?

Given the tool has an output schema, return values need not be explained. The description covers the main parameters but omits any mention of the required 'filepath' parameter or potential error conditions. For a tool with no annotations and 0% schema description coverage, the description is adequate but not thorough enough to fully guide 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?

Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The description compensates by explaining the 'format' parameter (listing gltf, glb, fbx, obj) and the 'selected_only' boolean flag. However, it does not describe the required 'filepath' parameter at all, leaving a critical 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 verb (exports) and resource (current scene or selected objects to a 3D asset file). It clearly distinguishes this tool from siblings like blender_create_object or blender_render_viewport. It is clear and specific but lacks explicit differentiation from other export-oriented siblings (if any existed).

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 on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a saved scene or matching file extension) or exclusions. The only implied usage is that it exports, but no context is given for choosing between exporting the whole scene or selected objects.

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 does disclose behavioral traits — 'token-efficient' output and the fields included (names, types, visibility) — and 'Returns' implies a read-only operation. However, it omits the depth-limiting behavior (max_depth defaults to 4, silently truncating the hierarchy), which is meaningful for interpreting results.

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 short sentences with the core purpose front-loaded; little waste. Minor filler in 'if specified,' and the third sentence partly restates what the output schema already enumerates.

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 output schema exists, so return values needn't be explained, and the description adequately covers purpose and content. It falls short on max_depth semantics and on routing guidance against ten sibling tools, leaving gaps an agent would have to guess at.

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 collection_name's effect (filtering the hierarchy by collection) but says nothing about max_depth, which controls traversal depth and therefore what the agent actually receives. Half the parameters are semantically explained.

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 verb and resource: 'Returns a token-efficient hierarchy of collections and objects in the current Blender scene.' An agent can distinguish it from blender_get_scene_info and blender_inspect_object by the outliner/hierarchy scope, though the description never explicitly contrasts them.

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 when-to-use guidance, no prerequisites, and no named alternative. The phrase 'Filters by collection_name if specified' describes a parameter effect rather than a usage condition, and the agent is left to infer that this is the broad-overview tool versus the object-level 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 provided, so the description carries the burden. 'Retrieves' clearly signals a non-mutating read, and it lists the exact categories of data returned, but it says nothing about side effects, permissions, or cost/latency characteristics.

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 that names the operation immediately and then enumerates the returned fields. 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 the description needn't detail return structure, and it still gives a useful preview of what is returned. For a zero-parameter read tool this is essentially complete; only the read-only/side-effect guarantee is left implicit.

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 zero parameters, so the baseline is 4. No parameter meaning can be added beyond the empty schema, and the description correctly does not pretend otherwise.

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 (Retrieves) and resource (scene configuration) and enumerates exactly what is returned: active camera, render engine, FPS, frame range, unit system, object counts. This is enough to distinguish it from siblings like blender_inspect_object or blender_get_outliner, though it does not explicitly name those alternatives.

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?

Usage is implied rather than stated: an agent can infer this is a scene-wide orientation call. There is no explicit guidance on when to prefer it over blender_inspect_object or blender_get_outliner, nor any stated prerequisites.

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. 'Inspects' and the read-oriented return list clearly signal a non-mutating operation, but nothing is said about behavior when the object does not exist, name matching (case sensitivity, exactness), or whether the call has any side effects.

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

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

A single well-structured sentence with the verb and scope front-loaded and the returned facets enumerated compactly in parentheses. Slightly list-heavy, but every element earns its place by helping the agent decide whether this tool answers its question.

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 do not strictly need describing, yet the enumeration usefully confirms coverage. With only one required parameter and a read-only role, the description is nearly sufficient; the only real gap is error/not-found behavior and parameter format.

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?

One required parameter (object_name) with 0% schema description coverage, and the description only says 'a specific Blender object' without specifying name format, case sensitivity, or how to discover valid names. It adds a little targeting meaning but does not compensate for the undocumented 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?

States a specific verb (inspects) and a specific resource (a Blender object), then enumerates the exact facets returned: transforms, mesh statistics, modifiers, materials, constraints, hierarchy. This distinguishes it from scene-level siblings like blender_get_scene_info and blender_get_outliner without naming 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?

Usage is implied by the content list — the agent can infer this is the tool to call when it needs per-object detail before modifying or exporting. However, there is no explicit statement of when to prefer it over blender_get_outliner or blender_get_scene_info, and no prerequisites are given.

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 implies mutation and includes a 'remove' action, but never states that removal is destructive, whether it is reversible, what happens to an existing material when reassigned, or any permission/idempotency characteristics. For a write tool with zero annotation coverage this is a meaningful 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 compact, front-loaded with the purpose, and then enumerated per parameter with no filler sentences. The terse parameter list is efficient, though the action values are stated twice (once in prose, once in the action line), which is minor 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. However, with 8 parameters at 0% schema coverage, the description leaves object_name and material_name undocumented and gives no semantics for the 'remove' action, so an agent cannot fully predict behavior for all modes.

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 for six of eight parameters: action values, color as RGBA/RGB float list, the 0.0-1.0 bounds for color/roughness/metallic, and emission as an RGB list with emission_strength as a multiplier. It omits object_name and material_name semantics, keeping it short of a 5.

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 first sentence names a specific verb set (creates, assigns, configures) and a specific resource (a Principled BSDF material on an object), so the tool's purpose is immediately clear. It does not distinguish itself from siblings like blender_modify_object or blender_manage_modifiers, but the resource is narrow enough to be 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 lists the valid action values ('assign', 'create', 'remove') but never explains when to pick each one or what state each requires (e.g., must a material already exist for 'assign' vs 'create'?). There is no guidance on when to use this tool instead of blender_modify_object or blender_create_object.

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 for a mutation tool. It never states that 'apply' bakes the modifier irreversibly into the mesh, that 'remove' destroys the modifier, or that 'add' alters the object's modifier stack. For a 9-parameter mutating tool with zero annotation coverage, these omissions are significant.

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?

Purpose is front-loaded in the first sentence and the rest is a compact bulleted map of parameters. The terse fragment style ('width, segments: for BEVEL') is efficient and every line carries information, though the parameter bullets are grouped in a slightly hard-to-scan way.

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, and the parameter mapping is reasonably covered. But for a 9-parameter mutation tool with no annotations, the description is missing usage selection logic and any disclosure of destructive behavior, leaving gaps for an agent to resolve on its own.

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 add real meaning: it maps levels to SUBSURF, width/segments to BEVEL, and target_object/operation to BOOLEAN. However it omits semantic guidance for object_name, modifier_name, and modifier_type beyond examples, so roughly a third of the parameters remain unexplained in both schema and description.

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 first line names a specific resource ('modifiers on an object') and the action values ('add', 'remove', 'apply') clarify the verb class. This distinguishes it from blender_manage_material and blender_modify_object by subject matter, though it never explicitly contrasts with those siblings. Clear enough for an agent to identify the tool's domain.

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 lists the valid 'action' values but gives no guidance on when to use each one, what prerequisites exist (e.g. an existing modifier_name for remove/apply), or how this differs from blender_modify_object. An agent gets the vocabulary but not the decision criteria.

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 concrete mutations performed and a useful unit detail ('rotation in degrees'), which is genuine behavioral context. It says nothing about reversibility, error handling, required permissions, or side effects such as how parenting interacts with world transforms.

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 with a colon-delimited list of operations. No filler and the core purpose leads the statement.

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. The description enumerates the mutation surface for a tool with 0% schema coverage, making it largely sufficient to call correctly. Minor gaps remain around permissions and failure behavior for a mutation tool with no annotations.

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: it maps seven of the eight parameters to their meaning (location, rotation, scale, new_name, visible, parent, collection), leaving only object_name implicit. It still omits format details such as the required array shape for location/rotation/scale, so it falls short of fully replacing the 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 gives a specific verb ('Modifies') and resource ('an existing object in the scene') and enumerates the operations available (transforms, renaming, visibility, parenting, collection move). This implicitly distinguishes it from blender_create_object ('existing' vs new), but no sibling is named 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?

Usage is implied by 'existing object' – an agent can infer this is for changing objects already in the scene rather than creating them. However, there is no explicit when-to-use, no prerequisites, and no reference to alternatives such as blender_manage_modifiers or blender_inspect_object.

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 and does disclose meaningful behavior beyond the schema: the tool degrades gracefully when Blender is closed, reporting offline status plus locally detected .blend files, and it notes the MCP Add-on requirement for live mode. It does not mention rate limits or side effects, but as a read-only probe the residual risk is low.

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 short sentences, front-loaded with the core purpose before the branching detail. Efficient overall, though the return-value enumeration partially duplicates what an existing output schema already documents.

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 zero-parameter connectivity check with an output schema present, the description supplies the essential context (what is checked, the two operating modes). Nothing an agent needs in order to invoke it correctly is missing; return shape is delegated appropriately to the 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify, and it correctly avoids inventing parameter detail.

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+resource — 'Checks the connection status to the Blender Editor' — which is unambiguous. It is clearly distinguishable from all siblings, which read or mutate scene content (get_scene_info, inspect_object, execute_script, etc.); this is the only health/connectivity probe.

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 when the tool is relevant by describing the two outcome branches (Blender open vs. closed), but it never explicitly says 'call this first to verify Blender is reachable before invoking other tools' or names any alternative. Usage is inferable rather than 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 provided, the description carries the full burden. It usefully discloses the side effect (writes a PNG to disk) and the response content (file path and resolution), but says nothing about overwrite behavior, required auth/context, or whether the full render blocks or is long-running.

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 tight sentences with the primary action front-loaded and no filler. Slightly terse given the unstructured parameters, but nothing is wasted.

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-value explanation is not strictly needed, and the description still summarizes the return. However, with zero annotation coverage and zero schema description coverage, the absence of any output_path or default-behavior explanation leaves real gaps for a tool that writes files.

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 both parameters are undocumented in structured data. The description obliquely conveys what full_render does via the two render modes, but never names the parameter, and output_path is entirely unexplained (no default-path or format guidance), so it fails to compensate for the coverage gap.

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

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

The description names a specific verb and resource ('Captures a viewport preview screenshot ... or triggers a full Cycles/EEVEE render'), clearly distinguishing the two modes. No sibling tool in the list performs rendering, so differentiation is implicit and 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 contrasts 'fast OpenGL render' with 'full Cycles/EEVEE render', which implies when each mode is appropriate, but it never explicitly says which mode to choose or when to avoid one. No prerequisite or exclusion guidance is given, leaving the selection to inference.

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