Blender-MCP

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

Annotations are all false, so the description carries the burden. It discloses the return format ('JSON with the light object name and properties') and the supported light types, which adds context. However, it does not mention side effects like whether existing lights are replaced, or any requirements (e.g., a scene must be open). This is adequate but not rich.

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

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

The description is well-structured with clear sections for purpose, arguments, returns, and an example. It is reasonably concise, with every section adding value. It loses one point for being slightly verbose with the formatted 'Args:' and 'Returns:' labels, but overall it is efficient and front-loaded with the primary purpose.

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 complexity (multiple light types, many optional parameters) and the presence of an output schema (not shown but indicated), the description is largely complete. It includes supported types, an example, and return behavior. However, it omits constraints like which parameters apply to which light types (relying on the schema), and it doesn't mention potential errors. Still, for an 'add' operation with good schema coverage, this is sufficient.

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 lists parameter names and mentions type-specific settings but does not explain the meaning of most parameters (e.g., energy units, color format) beyond the example. The example provides some context, but the 'etc.' leaves many parameters unspecified. This is insufficient compensation for the lack of schema-level descriptions in the text.

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 the action clearly: 'Add a light source to the scene.' It also enumerates supported light types (POINT, SUN, SPOT, AREA), which distinguishes it from siblings like blender_create_primitive or blender_set_camera. The verb and resource are specific and unambiguous.

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

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

The description implies when to use the tool: whenever a light source is needed. However, it does not explicitly contrast it with alternatives such as blender_execute_python (which could also add lights) or mention any exclusions. There is no 'when not to use' guidance, so it falls at the 'implied usage' level.

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?

Annotations already indicate this is a mutable operation (readOnlyHint=false). The description adds that it returns JSON about the new object and gives an example. It doesn't disclose potential edge cases like name collisions or unit conventions, but it's not misleading. With annotations reducing the burden, this is adequate.

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 compact docstring with a purpose line, args, return, and example. It is front-loaded with the action and uses no filler. Every part 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?

This is a simple creation tool with an output schema. The description tells agents what it creates and what to expect in return. It doesn't mention all supported primitive types (though the schema enum does) or coordinate conventions, but for typical usage it's sufficient. Given the low complexity, a 4 is appropriate.

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?

Although the schema has detailed descriptions, the context signal says schema coverage is 0%, meaning the description must compensate. The description explicitly lists the key fields (primitive_type, name, location, size) and provides a concrete example, making the parameter semantics clear. It doesn't repeat default values, but the schema covers those.

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 the specific verb 'Create' with the resource 'primitive mesh' and enumerates examples (cube, sphere, cylinder). It is immediately clear that this tool is for adding meshes, distinguishing it from transform/delete and other sibling operations.

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 clearly states the tool's purpose and provides an example invocation. It doesn't explicitly state when not to use it or mention alternatives, but the context is so straightforward that an agent can infer usage. No competing create-primitive sibling exists.

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?

Annotations already indicate destructive and idempotent behavior, and the description reinforces this with "DESTRUCTIVE: permanently removes the object" and adds a specific detail not in annotations: deleting a missing object "returns success with a note." It also discloses the return format (JSON confirming deletion).

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 well-structured, using brief headings (DESTRUCTIVE, Args, Returns, Example). Every sentence adds value, with 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 and the presence of annotations, the description covers the essential aspects: purpose, input structure, safety, idempotent behavior, return type, and an example. It lacks only minor details like permissions or scene-specific side effects, which are unlikely to be needed for this one-parameter 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?

With schema description coverage at 0%, the description compensates by identifying the `params` input as a DeleteObjectInput containing an exact `name`, and the example clarifies usage (name="Cube"). While it doesn't mention case-sensitivity or the required flag, the schema already contains those details, and the example provides a concrete template.

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 exact action: "Delete an object from the scene by name." This specifies the verb (delete), the resource (object), and the method (by name), and it is distinct from sibling tools such as blender_create_primitive or blender_transform_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?

The description establishes a clear usage context: use this tool when you need to remove an object by its exact name. It gives an example and notes idempotent behavior, but does not explicitly contrast with alternatives or state when not to use it.

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

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

Adds context beyond the annotations by stating 'DESTRUCTIVE: arbitrary code can modify or delete anything in the scene' and explaining that `bpy` is pre-imported and data is returned via a `result` variable. These details go beyond the destructiveHint annotation.

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 well-structured with sections for purpose, usage, warning, args, returns, and example. It is concise, front-loaded, and every sentence contributes 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's complexity as an arbitrary code execution escape hatch, the description covers execution context, return protocol, destructive warning, limits, and an example. This is sufficient for correct selection and invocation, especially with the sibling list and output schema as scaffolding.

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 input schema describes the `code` parameter, but the tool description supplements it with the `result` return convention, the 20,000 character limit, and a concrete example. This adds meaningful semantics beyond 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 clearly states 'Execute arbitrary Python code inside Blender' with 'escape hatch for advanced ops', establishing a specific verb+resource. It distinguishes itself from sibling tools by framing it as a fallback for when dedicated tools do not apply.

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

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

Explicitly says 'Use this only when no dedicated tool fits', providing direct when-to-use guidance and implicitly naming alternatives. The example further clarifies appropriate 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable behavioral context: it lists the kinds of data returned (transform, dimensions, material slots, type-specific settings) and the output formats (markdown/json). No contradictions with annotations.

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

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

The description is well-structured with Args, Returns, and Example sections, and every sentence adds value. The only slight redundancy is 'GetObjectInfoInput with the object name and response_format' plus the example, but it remains compact and readable.

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 an output schema exists, the description doesn't need to explain return structure in depth, yet it still does. It covers the main output categories and type-specific data. Missing behavior for nonexistent objects or error cases, but overall complete for a read-only query 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 reported as 0%, so the description must compensate. It names both parameters (name, response_format) and provides a concrete example, but it doesn't elaborate on the meaning of response_format values beyond 'Markdown summary or JSON', which the schema already enumerates. Adequate but not comprehensive.

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 'Get detailed information about a specific object by name'—a specific verb + resource that clearly distinguishes this from sibling tools like blender_list_objects (which lists all objects) and blender_get_scene_info (scene-level info). It further details type-specific data returned for MESH, LIGHT, and CAMERA.

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 to use this tool (when you need detailed info about one named object) but does not explicitly state alternatives or exclusions, such as 'use blender_list_objects to see all objects'. It stops at implied 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds value by specifying the return format options (markdown/json), the exact scene attributes returned, and an example invocation, enhancing transparency beyond the annotations.

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 front-loaded with a clear purpose, followed by a concise return summary and an instructive example. The Args/Returns sections add a bit of redundant structure but remain tight and useful.

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 read-only tool, the description covers inputs, outputs, and example usage thoroughly. No significant gaps remain; the output schema and annotations further supplement understanding.

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?

Although the schema coverage signal is 0%, the description explicitly documents the 'params' argument and the response_format choices with an example. This compensates well for any lack of schema-level parameter explanation.

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 'Get an overview of the current Blender scene' and enumerates the returned fields (scene name, frame range, render engine, total object count), distinguishing it from sibling tools like blender_list_objects and blender_get_object_info.

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 clear context for scene-level queries but does not explicitly mention alternatives or when not to use it. The sibling tool set implies differentiation, but no direct exclusions are 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?

Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds behavioral details such as OpenGL rendering, inline image return, and error-string fallback, which are not in the annotations and are valuable for invocation.

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 well-structured with a short purpose, method, args, returns, and an example. Every sentence contributes useful information without unnecessary verbosity.

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 single-parameter, non-destructive tool, the description covers what it does, how it renders, what it returns, and what happens on failure. The supported annotations and clear sibling context make this sufficiently complete for correct invocation.

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 already documents max_size as the maximum width or height in pixels, so the description adds little beyond repeating the default value (800) and providing an example. It does not compensate significantly for the low schema description coverage at the top level, but the nested schema is informative.

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 captures a screenshot of the current Blender 3D viewport using OpenGL. This distinguishes it from the sibling blender_render_image, which likely renders final images, by emphasizing the live viewport context.

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: 'Great for inspecting the current state of the scene visually.' It does not explicitly name alternatives or exclusions, but the use case is well implied and distinct from a formal render.

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?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context by specifying that the result is a Markdown table or JSON list with name, type, and location, and that filtering is optional. This goes beyond annotations without contradicting them.

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, followed by well-organized Args, Returns, and Example sections. There is no filler; each section adds value.

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 read-only list tool, the description covers input (optional filter/format), output shape (table or JSON with name/type/location), and provides a usage example. The main gap is not explicitly stating when to prefer a sibling tool, but that is partially handled in the usage guideline dimension; overall the description is sufficiently 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 description names both object_type and response_format and provides a concrete example. However, the example calls blender_list_objects(object_type=..., response_format=...) while the schema requires a single `params` object containing these fields, which could mislead an agent about the invocation shape. The schema itself provides useful parameter descriptions, but the example inconsistency prevents a higher score.

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 objects in the current Blender scene with an optional type filter. This distinguishes it from siblings like blender_get_object_info (single object) and blender_get_scene_info (scene-level info).

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: it is used to list objects in the current scene, optionally filtered by type. It does not explicitly name alternatives or when-not-to-use, but the context is sufficient for an agent to infer when this list operation is appropriate.

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?

The description goes beyond the existing destructiveHint annotation by explicitly stating that opening the file replaces the current scene and that unsaved changes will be lost. It also discloses the return value, providing useful behavioral context for the agent.

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

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

The description is concise and well-structured: no fluff, with purpose, warning, args, returns, and example all in appropriate sections. The warning is placed prominently, and every sentence contributes value.

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 tool with a simple output schema, the description is complete. It covers behavior, side effects, return value, and an example. There are no significant gaps for an agent to use it correctly.

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

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

Given the schema description coverage is 0%, the description compensates by explaining the `filepath` parameter as an absolute path to a .blend file. It also provides an example invocation, which clarifies usage. It could add more detail about constraints (e.g., file must exist) but is sufficient for a single simple 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 clearly states the tool opens a .blend file in Blender and replaces the current scene, distinguishing it from sibling tools like blender_save_file and blender_get_scene_info.

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

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

It provides clear context for when to use the tool – to load a saved .blend file into Blender – and includes a warning about unsaved changes being lost, which is an important usage caution. However, it does not explicitly mention alternative tools or when-not-to-use scenarios other than the data loss warning.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds behavioral context by specifying the return format (JSON with status and message) and including an example output, which clarifies what the agent can expect. It does not go deeper into edge cases, but with strong annotation coverage, this is sufficient.

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 with the main purpose. It includes a returns section and a concrete example, which are useful but add a bit of length. Overall, every sentence earns its place, and the structure is clear and scannable.

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 ping/health-check tool with no parameters, the description is complete: it explains what the tool does, when to use it, and what the output looks like. The presence of an output schema and the provided example further support completeness. No gaps are evident for this level of complexity.

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 schema is empty. The description correctly does not invent parameter details. Since there are no parameters to describe, the baseline of 4 applies, and the description appropriately focuses on the return value instead.

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: 'Check whether Blender is running and the bridge addon is reachable.' This distinguishes it from sibling tools like blender_get_scene_info or blender_list_objects, which perform different actions. The purpose is unambiguous and immediately understood.

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?

Explicit guidance is provided: 'Use this as the first step before any other tool to confirm the integration is live.' This tells the agent exactly when to invoke this tool, and no alternative is needed since it is a prerequisite check. This is strong usage guidance.

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

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

The description discloses blocking behavior, return format (metadata JSON plus inline PNG preview), and disk saving when output_path is given. It also explains engine override and sample override side effects. With annotations being false for all hints, the description carries the burden well, though it doesn't mention if the scene's frame is temporarily changed or other subtle state mutations.

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 well-structured with a one-line summary, followed by behavioral notes, parameter summary, return explanation, and two clear examples. No word is wasted; every sentence adds value. It is appropriately sized for a tool of this complexity.

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 moderate complexity (6 parameters), no output schema, and weak annotations, the description covers all essential aspects: what it does, blocking behavior, engine guidance, return format, optional disk saving, and usage examples. The agent has enough context to invoke the tool correctly and interpret results.

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?

Despite the schema coverage being 0% (as signaled), the description lists all parameter categories: frame, output_path, engine override, Cycles sample override, preview size, and timeout. It adds usage depth by noting that CYCLES is slower and to increase timeout_seconds, and provides concrete examples showing how parameters are passed. It doesn't restate types or constraints, but the examples and high-level summaries compensate 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 opens with a specific verb and resource: 'Render a frame using Blender's render engine and return the result inline.' It clearly distinguishes from siblings like blender_get_viewport_screenshot by specifying rendering via Blender's engine. The inline result behavior and full-resolution save option further clarify its scope.

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 engine choice ('For fast previews use EEVEE; for photorealistic output use CYCLES (much slower — increase timeout_seconds)') and notes that the tool blocks until render completion. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient for an agent to select it appropriately.

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?

The description adds useful behavioral context beyond the annotations: it specifies the return format (JSON with the saved path) and the fallback to the currently open file when filepath is omitted. The annotations already declare idempotent and non-destructive, and the description does not contradict this.

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 and well-structured, with the main statement first, followed by Args/Returns sections and two concise examples. Every line serves a purpose and there is no redundant information.

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 save operation, the description covers invocation, parameter behavior, return value, and provides examples. The output schema and annotations complement this, so an agent has all necessary information 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?

The schema already provides a detailed description for the only parameter (filepath), including the fallback behavior. The tool description largely repeats this and adds example invocation, but does not offer significant new meaning beyond what the schema provides.

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 action: 'Save the current Blender scene to a .blend file.' This is a specific verb (save) with a clear resource (current Blender scene) and target format. It effectively distinguishes this tool from the sibling 'blender_open_file'.

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 tool's usage is obvious from the description and examples, showing both filepath-specified and default behavior. However, there is no explicit guidance about when to choose this over alternatives or when not to use it, so it lacks explicit exclusion 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?

Beyond the annotations (readOnly=false, idempotent=true, destructive=false), the description adds meaningful behavioral context: it creates a new camera when no active scene camera exists, uses the active camera if name is omitted, and optionally aims the camera at a target. It also notes the return JSON structure. Some edge cases (e.g., behavior when a named camera does not exist) are not addressed, but the provided details are substantive and consistent with annotations.

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

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

The description is efficiently organized: opening purpose, fallback behavior, Args section, Returns section, and a concise example. Every sentence contributes useful information without redundancy or fluff. The front-loading of the main action ensures the agent immediately understands what the tool does.

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 moderate complexity, the description is complete: it explains the main operation, the fallback/creation behavior, the return format, and provides a concrete example. The output schema is also present, further reducing ambiguity. This description enables confident use even without prior familiarity with the tool or its siblings.

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?

Although schema description coverage is reported at 0% for the top-level params, the description fully compensates by enumerating all parameters (name, location, target, lens, set_active) and explaining their meanings in context. The example call (location=(5,-5,3), target=(0,0,0), lens=50) demonstrates usage syntax and parameter interactions, adding value beyond the nested property descriptions.

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 opening line, 'Configure a camera's position, aim target, and focal length,' uses a specific verb and resource with precise attributes, clearly distinguishing it from sibling tools like blender_transform_object or blender_get_object_info. It further clarifies scope with fallback behavior ('Uses the active scene camera if no name is given') and creation behavior ('Creates a new camera if the scene has none').

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 strongly implies its usage context through the operation it performs and the fallback behaviors, but it does not explicitly name alternatives or state when not to use it. The guidance is clear enough for an agent to select it for camera configuration, yet lacks the explicit 'when-to-use vs. alternative' contrast seen in top-tier descriptions.

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?

The description discloses key behavioral traits beyond annotations: 'Creates or updates a material', 'Assigns it to the first material slot', and 'using Principled BSDF'. This adds valuable context beyond the annotations' idempotentHint and readOnlyHint. No contradiction found.

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 well-structured and concise: a clear opening sentence, followed by organized Args, Returns, and Example sections. No unnecessary verbosity, and the example helps clarify usage.

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 focused material-setting tool, the description covers purpose, inputs, output, and usage example. It does not discuss alternatives or edge cases (e.g., objects without material slots), but these are likely minor. Given the output schema exists and annotations are present, the description is sufficiently 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 input schema contains detailed descriptions for every parameter (color, metallic, roughness, object_name, material_name, emission_color, emission_strength), so the description need not repeat them. The description does summarize the main parameters ('base color, metallic, roughness, and optional emission') but adds little beyond the schema. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states 'Apply a PBR material to an object using Principled BSDF' with specific verb+resource+method. It distinguishes from sibling tools by being the only material-specific operation, and includes details on creation/update and assignment behavior.

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: it is the tool for applying materials. However, no explicit 'when to use vs alternatives' is provided, especially relative to blender_execute_python which could also manipulate materials. There are no exclusions or stated scenarios.

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?

The description adds meaningful behavior beyond the annotations: it explains the `None` semantics for leaving fields unchanged, idempotency in plain language, and the return format (JSON with updated transform values). While the idempotentHint is already in annotations, the description clarifies its practical meaning and introduces the partial-update behavior not present in annotations.

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 well-structured and concise: a clear summary sentence, two key behavioral notes, an Args/Returns section, and a single illustrative example. Every sentence adds value, and the content is front-loaded with the core purpose, avoiding redundancy with the schema.

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 moderately simple tool with an output schema, the description is complete. It explains partial updates, idempotency, and the return value, and includes an example. The only minor omission is handling of non-existent objects, but this is not essential for correct usage and is implied by 'existing object.'

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?

Though the top-level schema reports 0% coverage, the nested schema describes each field ('New (x, y, z) scale factors', 'Omit to leave unchanged', etc.). The description reinforces these semantics and adds an example call showing how to set location and scale together. It also explains the `params` wrapper, making its structure clear, so the description compensates for any coverage gaps.

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 'Set location, rotation, and/or scale of an existing object,' which uses a specific verb and resource, clearly distinguishing this from siblings like create_primitive or delete_object. It also clarifies the scope (existing object) and the exact transform properties involved, leaving no ambiguity about the tool's function.

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

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

The description provides clear context for when to use the tool: to modify an existing object's transform. It also explains partial updates ('Any field left as `None` is left unchanged') and idempotency, which guides usage in repeated or incremental operations. However, it does not explicitly exclude or name alternative tools, which would merit a 5.

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