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

Annotations already mark this as destructive, and the description adds meaningful behavioral detail: full bpy access, a required result-variable contract, and deferred-completion limitations by mode. It does not fully describe persistent state or side effects across calls, but the annotation plus bpy-access statement largely covers the safety profile.

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 four terse, purposeful sentences with the core purpose front-loaded. Every sentence adds a distinct operational detail, and there is 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?

For a code-execution tool with a single parameter and an output schema, the description covers the environment, return convention, and mode-specific caveat. The main missing piece is an explicit pointer to the CLI variant for background use, which prevents it from being 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 only defines code as a string, and the description compensates by clarifying that the code executes in Blender's Python environment, has full bpy access, and should assign a JSON-serialisable dict to result. This adds practical meaning beyond the bare parameter definition, though it does not specify whether result is optional or what happens if it is missing.

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 and resource: executing Python code in the connected Blender instance with access to bpy. However, it does not explicitly differentiate from the sibling tool execute_blender_code_for_cli, so the agent must infer which server mode applies.

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 by explaining where code runs and how to return data. It also notes that deferred completion is only supported by the interactive addon server and rejected in background mode, but it never explicitly says when to prefer this tool over the CLI sibling or what conditions select one mode over the other.

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 `destructiveHint: true` annotation: it states that `blend_file` is opened with `blender --background`, that arbitrary Python `code` is run, and that data must be assigned to `result` to be returned. This gives the agent a clear execution model without contradicting the 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 very short and front-loaded: the core purpose is in the first sentence, followed by the essential invocation and return mechanism. Every sentence earns its place and there is 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?

Given the tool's simple two-parameter shape, the existence of an output schema, and the `destructiveHint` annotation, the description covers the key operational facts: how the file is opened, what code does, and how to return data. The main missing piece is explicit differentiation from the sibling `execute_blender_code`, but this is not critical for invoking the tool correctly.

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

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

With 0% schema description coverage, the description must carry parameter meaning. It does identify both parameters by name and explains that `code` is Python executed in the opened `blend_file`, and that `result` should be a dict. However, it omits details about path formatting, execution environment, or constraints on the returned data, so it only partially compensates for the empty 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 uses a specific verb+resource pair: 'Execute Python code in a background Blender process.' It clearly differentiates from interactive execution by specifying 'background' and the `blender --background` invocation, though it does not explicitly name or contrast the sibling `execute_blender_code`.

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 headless Blender execution but provides no explicit guidance on when to choose this tool over `execute_blender_code` or other siblings. There are no when-not-to-use conditions or alternative routing hints.

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 provide readOnlyHint=true, and the description's 'Return' is consistent. The description adds no extra behavioral context beyond the annotation, such as prerequisites or environment expectations. This is adequate given the annotation covers the safety profile.

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 that directly states the output. No filler or redundant phrases; every word adds value. It is concise and immediately comprehensible.

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 nullary tool with an output schema and read-only annotation, the description is largely complete. However, it does not address the notable sibling variant _for_cli, which leaves the non-CLI vs CLI usage implicit. A brief note on environment would improve completeness.

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 has zero parameters, so the baseline is 4. The description adds no parameter-level details, but none are needed. The tool is a nullary call, so no semantic gaps exist.

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 returns a blend file summary with specific contents (data-block counts, active workspace, render engine). This distinguishes it from sibling summary tools like missing_files, linked_libraries, path_info, and usage_guess. The verb 'Return' and resource are explicit.

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 choose this tool over alternatives. The description does not mention that it targets non-CLI contexts or how it differs from get_blendfile_summary_datablocks_for_cli. With many similar sibling tools, the agent gets no explicit routing help.

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=true, so the read-only nature is known. The description adds the detail 'opening *blend_file* in background Blender', which implies a non-interactive execution context, a useful behavioral trait beyond the annotation. It does not describe any other side effects, but given the annotation coverage, this is acceptable.

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 immediately states the action and context. It is concise, front-loaded with the core purpose, and contains no filler. Every word contributes to understanding the tool's function.

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 simplicity of the tool (one parameter) and the presence of an output schema, the description is mostly adequate. However, it lacks any mention of prerequisites (e.g., Blender installation) or a note distinguishing this from the non-CLI sibling. While the background Blender detail helps, the description could be more complete by clarifying when to use the CLI variant.

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 only parameter, blend_file, is a string, and the description simply says 'opening *blend_file*' without adding any detail about what constitutes a valid path, format, or any constraints. The parameter name is somewhat self-explanatory, but the description adds no semantic information 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 states a specific action: 'Return a data-block summary' and identifies the resource as 'blend_file'. It also notes the context of 'background Blender', which clarifies the headless operation. However, it does not explicitly differentiate from the sibling tool get_blendfile_summary_datablocks (without '_for_cli'), so the purpose is clear but sibling distinction relies on the name.

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 the non-CLI sibling get_blendfile_summary_datablocks. It does not mention that this is the command-line variant or suggest using the non-CLI version in interactive sessions. There is no explicit when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true, covering the safety profile. The description adds useful context by listing the categories of external references checked, but does not go beyond that. It does not describe any side effects, performance implications, or return structure, though these may be covered by the output schema. Given the annotation coverage, a 3 is appropriate.

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

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

The description is a single, well-structured sentence. It front-loads the core action and resource ('Report external file references that are missing from disk') and adds a parenthetical list of examples. There is no wasted text 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?

For a read-only, zero-parameter tool with an output schema, the description is largely complete. It conveys the purpose and scope. It does not mention any prerequisites, limitations, or edge cases (e.g., whether linked libraries are included), but these are not critical for a simple query tool. The output schema likely covers return details, so nothing essential 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?

There are no parameters (0 params), so the baseline is 4. The description does not need to explain parameters, and it correctly does not. The empty schema is sufficient, and the description adds no conflicting information.

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 ('Report') and a precise resource ('external file references that are missing from disk'), and lists the types of references (images, libraries, fonts, etc.). This clearly distinguishes it from siblings like get_blendfile_summary_datablocks or get_blendfile_summary_of_linked_libraries, which address different aspects of the blend 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 description does not explicitly state when to use this tool versus alternatives. However, the name and family context make it obvious that this is for missing external files, and it does not conflict with any sibling. It lacks any mention of exclusions or specific scenarios (e.g., when to use the _for_cli variant), but the intended use is clear enough.

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=true, so the safety profile is covered. The description adds useful operational context that the tool runs 'in background Blender', but it does not disclose prerequisites, failure modes, or how missing-file detection behaves.

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 no filler and front-loads the main action. It is concise, though the brevity leaves room for more useful guidance without becoming bloated.

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-only tool, the description covers the core operation, and the output schema can explain the return shape. However, it omits the CLI-vs-non-CLI selection context and any notes about Blender availability or execution environment, leaving meaningful gaps.

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

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

Schema description coverage is 0% and the parameter has no property description. The description's use of '*blend_file*' confirms it is a Blender file path, but it does not add details such as path format, required extension, or file accessibility. Compensation for the missing schema text is minimal.

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 and resource: 'Report missing file references by opening *blend_file*'. This clearly distinguishes it from datablock, library, and path summary siblings. It does not explicitly articulate the CLI-vs-GUI distinction, relying partly on the tool name and title.

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 the non-CLI sibling get_blendfile_summary_missing_files or other summary tools. The description mentions 'background Blender' but does not explain why an agent should choose this variant over the others.

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 include readOnlyHint=true, which is consistent with the description's 'Return' statement. The description adds useful context about the output being a tree and covering indirect links. However, it does not disclose other behavioral aspects like potential performance implications or whether the result is cached. Since annotations already cover the read-only safety, 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 a single, well-structured sentence that front-loads the action and scope. Every word adds value; there is no redundancy or filler. It is appropriately concise for a zero-parameter 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?

Given the presence of an output schema, the description does not need to explain return values. However, the tool is part of a large sibling set, and the description fails to differentiate itself from the CLI variant or to clarify what constitutes a 'linked library file' in the Blender context. This is a minor completeness gap, making it adequate but not comprehensive.

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 (0 params, 0 required, 100% schema coverage). The baseline for parameter semantics is 4 when no params exist, as the description need not add anything. It correctly does not attempt to document parameters.

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 (Return) and the specific resource (a tree of directly and indirectly linked library files). It distinguishes from siblings like get_blendfile_summary_missing_files and get_blendfile_summary_datablocks by focusing on linked libraries and the tree structure. The inclusion of 'directly and indirectly' adds precision.

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 when to prefer this over the CLI variant (get_blendfile_summary_of_linked_libraries_for_cli) or other summary tools. No exclusions or contextual cues 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?

Annotations already declare readOnlyHint=true, so the description does not need to state read-only behavior. It adds a useful behavioral detail by mentioning 'opening *blend_file* in background Blender', indicating a headless/CLI execution context. However, it does not disclose potential side effects, performance implications, or limitations (e.g., file size constraints, required Blender installation). With annotations covering the safety profile, a 3 is appropriate.

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

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

The description is a single concise sentence that front-loads the primary action and parameter. Every word serves a purpose, and it avoids redundancy with the tool name. The structure is efficient and easy to scan.

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

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

While an output schema exists (not shown), the description does not explain what kind of linked-library information is returned (e.g., paths, versions, dependencies). It also fails to clarify the distinction from the non-CLI sibling or any prerequisites (e.g., Blender must be installed). Given the tool's moderate complexity and the presence of an output schema, the description is minimally adequate but leaves gaps in usage 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 coverage is 0%, so the description must clarify the parameter. It does by referencing '*blend_file*' and stating it is the file to open. This adds meaning beyond the bare schema title 'Blend File'. However, it does not specify expected format (e.g., absolute path), file extension, or validation rules. The description partially compensates for the low coverage but leaves some ambiguity.

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

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

The description states a clear action ('Return linked-library info') and specifies the resource (blend_file). The name adds the 'for_cli' qualifier, which helps differentiate from the non-CLI sibling, though the description itself does not explicitly mention CLI context. It distinguishes the specific aspect (linked libraries) from other summary tools like datablocks or missing_files.

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 its siblings. It does not mention that the '_for_cli' variants are for headless/background operation, nor does it suggest when to prefer this over the non-CLI version or other summary tools. The agent is left to infer usage from the name alone.

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

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

The readOnlyHint annotation already covers the safety profile. The description adds useful context about what data is returned (path, save status, age, backups) and characterizes the call as simple/fast, but it does not disclose deeper behavior such as how backups are determined or whether data is read from disk. This is acceptable given the annotations and output schema.

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

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

The description is a single sentence with no wasted words. It front-loads the key characteristics ('Simple/fast access') and quickly lists the covered data categories.

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, read-only information tool with an output schema, the description is nearly complete. It could explicitly mention that this is the non-CLI variant or clarify that it refers to the current blend file, but these are minor omissions.

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 100% schema coverage is effectively trivial, so the description is not required to explain parameter semantics. A baseline of 4 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 clearly states the tool provides access to the blend file's path, save status, age, and backups. This specific field list distinguishes it from sibling summary tools like datablocks, missing_files, or linked_libraries, so an agent can identify what this tool covers.

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 explicit guidance on when to prefer this tool over alternatives. It only says 'simple/fast access', which weakly implies lightweight use, but it does not mention exclusions or the existence of the _for_cli sibling variant.

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 declare readOnlyHint=true, and the description adds the behavior of opening a file in background Blender. This is useful extra context beyond the annotation. However, it does not disclose potential side effects like temporary file creation, performance impact, or whether the background Blender instance is persistent.

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 no filler. It is front-loaded with the action and clearly states the method (opening in background Blender). Every word contributes to understanding the tool's 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?

The tool is simple with one parameter and read-only annotation, and an output schema exists. The description covers the core operation. However, it does not mention any caveats, prerequisites, or how it differs from the non-CLI sibling, which is relevant context for an agent selecting among similar 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 schema has no description for blend_file (coverage 0%), so the description must clarify the parameter. It does so by indicating that *blend_file* is the file to open, which adds meaning beyond the title 'Blend File'. However, it provides no additional details such as expected file extension, path requirements, or format 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 clearly states the tool returns path info by opening a blend file in background Blender. The verb 'Return' and resource 'path info' are specific. However, it does not explicitly differentiate from the sibling tool get_blendfile_summary_path_info (without _for_cli), relying on the name suffix for distinction.

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 versus the non-CLI sibling or other summary tools. The description explains what it does but not the context or conditions that would make it the preferred choice.

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 declare readOnlyHint: true, covering the read-only nature. The description adds that it returns a certainty score, which is useful context. However, it does not mention potential limitations (e.g., if the file has no recognizable use-cases) or any error conditions. Given the annotation covers safety, a 3 is appropriate.

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

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

A single sentence that is front-loaded with the action and resource, with the output format appended. No wasted words 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?

For a read-only, no-parameter tool with an output schema, the description is nearly complete. It tells the agent what to expect (a scored guess) and implicitly that it operates on the current blend file. Minor omissions like prerequisites (e.g., an open file) are unlikely given the domain and siblings, so this is adequate.

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 zero parameters, so the schema trivially covers everything. The description adds the output format (score) which indirectly clarifies what the tool does. Baseline 4 applies for no-parameter tools; no further compensation 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 a specific verb ('guess'), a clear resource ('primary use-cases of the current blend file'), and the output format ('scored 0-100 with certainty'). It differentiates from sibling summary tools (datablocks, missing files, path info) by focusing on usage 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?

No guidance is provided on when to use this tool versus alternatives. The description only states what it does, without mentioning exclusions, prerequisites, or naming more appropriate tools for other scenarios. This is a clear gap.

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

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

The readOnlyHint annotation already establishes that this is a non-mutating read operation. The description adds useful context that it opens the file in background Blender, which suggests headless execution. It does not describe output behavior, failure modes, or assumptions about the Blender installation, but no contradiction exists.

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 with no filler. It front-loads the action and immediately explains the mechanism, making it easy for an agent to parse quickly.

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: one required parameter, a readOnly annotation, and an output schema that can document return values. The description covers the core operation and adds the background Blender detail. It is slightly incomplete in not explicitly routing the agent to the non-CLI sibling, but overall it is adequate for a low-complexity, read-only 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%, so the description must carry the parameter meaning. The description does indicate that *blend_file* is the file to be opened by Blender, but it does not clarify whether it should be a local path, a relative path, or a CLI-style argument. It adds some semantics beyond the schema, but not enough to fully compensate for the missing schema 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 description uses a clear verb ('Guess') and a specific resource ('*blend_file*'), and adds an operational detail that it runs in background Blender. However, it does not explicitly distinguish itself from the sibling get_blendfile_summary_usage_guess, so the differentiation relies on the '_for_cli' name and 'background Blender' phrase.

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 'in background Blender' implies this is the command-line/headless variant, which gives some usage context. But it never states when to prefer this tool over get_blendfile_summary_usage_guess or another sibling, so the guidance remains 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.

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

readOnlyHint=true already signals a safe read; the description adds that the result is a structured summary and enumerates the included categories. It does not describe error behavior for a missing name, but for a read-only single-object lookup this is a minor gap.

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

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

Two sentences, the first stating the action and the second listing return contents. 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?

The low parameter count, read-only annotation, and available output schema mean the description covers the essential call contract. It could add an explicit pointer to sibling tools for overview summaries, but nothing needed to invoke the 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 schema only lists 'name' as a required string with no property description. The description adds that this name identifies the object and hints at scope by mentioning data-block name, giving the agent just enough to supply the correct input.

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 exact operation ('Return a structured summary') and the target ('the object identified by name'), and its field list makes clear this is a per-object detail tool rather than a scene-wide summary like get_objects_summary.

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 context is implied: call it when you need a detailed summary of one named object. It does not explicitly mention alternatives such as get_objects_summary or state when not to use it, so the routing guidance is weaker than it could be.

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 readOnlyHint annotation already establishes the operation is non-mutating, and the description does not contradict it. The description adds scope (scene collection hierarchy, nested child collections) but does not add further behavioral detail such as whether hidden collections are included or whether selection state filters 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?

Two short sentences with the main action front-loaded ('Return the scene's collection hierarchy and their objects') and a compact elaboration of what each collection lists. No filler 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?

For a read-only, zero-parameter tool with an output schema, the description is sufficient: it states the resource scope and the kind of data included. The output schema can carry the detailed return structure, so nothing essential 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 takes no parameters, so the schema leaves nothing undocumented. The description adds helpful context about what the response summarizes, but no parameter semantics are needed; baseline 4 applies for a zero-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 clearly states the tool returns the scene's collection hierarchy and its objects, naming specific attributes such as name, type, parent, data name, selection, and visibility. This is a specific verb+resource description. However, it does not explicitly differentiate itself from the similar sibling get_object_detail_summary, so it stops short of full distinction.

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 the tool is appropriate whenever an agent needs the full collection hierarchy and a per-object summary of the current scene. It provides no explicit when-to-use guidance and does not mention when to prefer alternatives such as get_object_detail_summary or execute_blender_code.

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 far beyond the readOnlyHint annotation by detailing the six response kinds (exact, namespace, definition, partial, suggestions, missing), the truncation rule for files over 32 KB, and the structure of each response. This is comprehensive behavioral disclosure that fully prepares the agent for what to expect.

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?

Although long, the description is tightly organized with bullet points, code formatting, and a logical flow from purpose to response kinds. Every sentence contributes essential information, and the front-loaded summary of purpose and patterns is immediately actionable. 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?

For a tool with multiple response kinds, edge cases, and a large-file truncation rule, the description covers every aspect an agent needs to invoke it correctly and interpret results. The presence of an output schema does not detract; the description adds the necessary semantic context beyond the 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?

With schema description coverage at 0%, the description carries the full burden of explaining the parameter. It thoroughly describes the identifier format, the meaning of trailing-* patterns, and provides examples (bpy.app, bpy.types.Scene.frame_current). This is exemplary compensation for the missing schema documentation.

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 function: 'Return the Blender Python API docs for *identifier*, or list modules matching a trailing-* discovery pattern.' This is a specific verb and resource, and the distinction from sibling search_api_docs is evident—this tool targets exact identifiers and discovery patterns, not free-text search.

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 detailed guidance on how to format the identifier (fully-qualified Python name, trailing-* patterns) and explains the behavior of each pattern. However, it does not explicitly state when to prefer this tool over alternatives like search_api_docs, leaving the when-not-to-use guidance implicit. The context is clear 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?

The readOnlyHint annotation already covers safety, and the description adds useful behavior details: the result is a PNG image, size_limit caps bytes, and zero uses the MCP message size limit. No contradiction with annotations.

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

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

The description is brief, front-loads the action, and uses compact bullets. Every sentence earns its place with no redundant or filler 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 read-only screenshot tool with two parameters and no output schema, the description states the return type, parameter semantics, and default behavior. Nothing essential to invoking the tool correctly 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?

Schema description coverage is 0%, but the description compensates well for both parameters: area_ui_type maps to the area's ui_type, and size_limit_in_bytes has its cap/default behavior explained. This is exactly the semantic guidance an agent needs beyond the schema enum and integer type.

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?

Opens with a clear verb and resource: 'Take a screenshot of a single Blender area' and specifies the PNG return format. The 'single Blender area' scope distinguishes it from sibling window-screenshot tools such as get_screenshot_of_window_as_image.

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 it (when a screenshot of one Blender area is needed) but does not explicitly state when not to use it or point to an alternative. It could profitably mention that window-level screenshots are served by the sibling window screenshot tools.

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 readOnlyHint annotation already signals a safe read operation. The description adds value by disclosing the output format (PNG), the size-limiting mechanism, and the default fallback to the MCP message size limit. It does not describe edge cases like error handling when the limit is exceeded, but the core behavior is transparent 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?

Two sentences, no filler. The primary purpose is front-loaded in the first sentence; the second sentence addresses the only parameter. Every word earns its place, and the structure is easy to scan.

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

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

For a tool with one optional parameter and no required inputs, the description covers the action, return type, and parameter semantics. It does not mention potential errors, resolution, or multi-window scenarios, but these are minor given the simplicity of the operation and the presence of readOnlyHint. The absence of an output schema is mitigated by stating 'return it as a PNG image'.

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 carries the full burden for parameter clarity. It clearly explains 'size_limit_in_bytes' — what it caps, the default (0), and what zero means (use MCP message size limit). This is exactly the semantic addition needed beyond the raw integer 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: 'Take a screenshot of the entire Blender window' and explicitly states the return type (PNG image). This clearly differentiates it from sibling tools like 'get_screenshot_of_area_as_image' (area vs window) and 'get_screenshot_of_window_as_json' (JSON vs PNG). No ambiguity remains about what this 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?

The description explains the size_limit parameter and its default behavior, which helps with invocation. However, it does not explicitly state when to use this tool instead of alternatives such as 'get_screenshot_of_area_as_image' or 'get_screenshot_of_window_as_json'. Usage context is implied by the name and wording, but no direct guidance or exclusions are provided.

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

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

The readOnlyHint annotation already signals that this is a safe read operation, and the description adds useful context about the specific data returned (layout, areas, active object, selection). However, it does not disclose any further behavioral details, such as whether it reflects only the current state or how window layout is represented.

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, focused sentence with no filler or redundant wording. It front-loads the action and immediately specifies the resource and scope, making it easy for an agent to parse quickly.

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-parameter, read-only tool with an output schema present, the description covers the essential information: what the tool returns and the scope of that return. It could be slightly more explicit about how this differs from the image screenshot variants, but the available structured context compensates for most gaps.

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

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

The tool has zero parameters and the schema is empty, so the baseline for this dimension is 4. The description does not need to explain parameters, and no documentation gap exists for parameter semantics.

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 ('Return') and clearly identifies the resource and scope: a JSON description of the Blender window layout, areas, active object, and selection. The mention of 'JSON description' helps distinguish it from the image-returning siblings like get_screenshot_of_window_as_image, though it does not name 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 guidance on when to use this tool versus alternatives such as get_screenshot_of_window_as_image or get_object_detail_summary. The JSON output implies a non-image result, but the description does not explicitly state when to prefer this tool or what it should not be used for.

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 annotations already mark this as destructiveHint=true, and the description clarifies exactly what changes: the active workspace tab. It does not describe side effects or consequences, but for a simple tab-switch action the core mutation target is stated.

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. It is appropriately concise for a one-parameter action, though it could have added more structure by explicitly naming the parameter and its semantics.

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 low complexity, one required parameter, and presence of an output schema, the description is nearly sufficient for invocation. It lacks usage context and side-effect detail, but an agent can likely infer the intended call from the tool name and description.

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 clarify the 'name' parameter. It does indicate that name is the destination tab, but it leaves out exact-match behavior, case sensitivity, or how the name maps to tabs. 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 clear action ('switch the active workspace tab') and identifies the target parameter ('name'). Its by-name phrasing implicitly distinguishes it from jump_to_tab_by_space_type, though that differentiation is not explicit.

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 versus alternatives. The sibling jump_to_tab_by_space_type implies the choice is name-based vs. space-type-based, but the description itself offers no selection criteria, prerequisites, 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?

Annotations already declare destructiveHint=True, and the description adds meaningful behavioral context by explaining that a new workspace is created via duplication of the current workspace when allow_edits is True and no match exists. This goes beyond the annotation without contradicting it, though it does not explain the specific destructive consequences.

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 focused sentences with no filler. The primary behavior is front-loaded, and the conditional creation rule is presented efficiently in the second 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?

The description covers the main switching and creation behaviors, and an output schema exists so return details are not needed. However, it leaves an important gap: what happens when no workspace matches and allow_edits is False, which is a likely call path given the default value. It also does not clarify the practical implications of destructiveHint in this 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 carries the burden of explaining parameters. It does this well: space_type is tied to the workspace's main area, and allow_edits is tied to the creation behavior. Both parameters gain semantic meaning beyond their raw types.

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—switching to a workspace whose main area matches a given space_type—and distinguishes it from sibling tools like jump_to_tab_by_name by focusing on space type rather than name. The verb and resource are precise and immediately understandable.

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

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

The description gives clear context for when creation occurs (allow_edits=True and no matching workspace), but it does not explicitly contrast this tool with the closely related sibling jump_to_tab_by_name or state when to prefer one over the other. Usage is implied rather than explicitly guided with alternatives 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?

The description goes beyond the destructiveHint annotation by revealing exactly what may change when allow_edits is true: the object may be un-hidden and its collections enabled. This is honest, concrete behavioral disclosure. It does not contradict 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?

Two tight sentences with no filler. The primary action is front-loaded in the first sentence, and the optional side-effect is separated into the second. 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 and the optional mutation is explained. An output schema exists, so return-value documentation is not the description's burden. It does not mention failure behavior when the object is hidden and allow_edits is false, but for a focused navigation tool this is a minor gap.

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

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

With schema description coverage at 0%, the description must carry parameter meaning. It does this effectively for allow_edits ('the object may be un-hidden and its collections enabled') and clarifies that name refers to the object's name. It could add format or uniqueness details for name, but it sufficiently compensates for the missing schema 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 description opens with a specific verb and resource: 'Move the 3D viewport to focus on an object by *name*.' This clearly distinguishes it from sibling tools like jump_to_view3d_object_data_by_name and jump_to_tab_by_name by emphasizing viewport-level navigation rather than data or tab focus.

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: when you need the 3D viewport to focus on a named object. However, it does not explicitly contrast with siblings such as jump_to_view3d_object_data_by_name, nor does it state when allow_edits should be enabled versus left false.

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 destructiveHint=true, the description adds useful behavioral context by explicitly saying that allow_edits=True may un-hide the object and enable its collections. It does not contradict the annotation, though it could further clarify what 'destructive' means in this 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?

Two sentences with no filler: the first states the core operation, the second handles the only conditional behavior. The important scoping is front-loaded.

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 navigation tool with an output schema and annotations, the description covers purpose and conditional side effects. It is slightly incomplete because it does not distinguish itself from the near-identical sibling or state what happens when no object matches, but it is sufficient for basic 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?

Schema description coverage is 0%, but the description compensates by defining name as a matching data block and explaining allow_edits' side effects. It gives more meaning than the schema's bare field names, though it could define 'data block' more explicitly (e.g., exact vs. partial matching).

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 ('Move the 3D viewport') and target ('object whose data block matches name'), which is clear. It does not explicitly contrast with the similarly named sibling jump_to_view3d_object_by_name, though 'data block' hints at the distinction.

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 choose this tool over jump_to_view3d_object_by_name or other sibling tools. The allow_edits note is a parameter behavior, not tool-selection guidance, so an agent has to infer when this variant 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?

Annotations already declare destructiveHint=true, and the description adds that it temporarily overrides settings, which is useful context. However, it does not elaborate on the nature of the destruction (e.g., file overwrite) or any other side effects beyond the temporary override. The description does not contradict 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 a single sentence with no fluff. It front-loads the primary action and target, and the parenthetical about overriding settings is efficient. Every word 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?

The tool is simple but the description leaves significant gaps: no usage guidance, no parameter semantics, and no mention of what happens to existing files at the output path. The existence of an output schema is noted but the description does not help an agent understand the tool's role among the many rendering and screenshot 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?

Schema description coverage is 0%, and the description does not compensate. It only repeats 'output_path' without clarifying expected format, file extension, whether the path must exist, or overwrite behavior. With a single required parameter, some elaboration is expected but absent.

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 (render) on a specific resource (a small, low-quality thumbnail) and the target (output_path). It is clear and distinct from sibling tools like render_viewport_to_path, though it does not explicitly name the alternative.

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

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 such as render_viewport_to_path or get_screenshot_of_area_as_image. It only mentions a temporary override of settings, which hints at context but does not offer explicit selection criteria 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?

The readOnlyHint annotation lowers the bar, and the description does add that the operation targets an output path using current render settings. However, it does not disclose that rendering likely writes or overwrites a file on disk or that rendering can be slow—behavioral traits beyond the annotation, though not directly contradicting it.

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 no filler. Every phrase ('current scene', 'output_path', 'current render settings') carries operational 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?

For a one-parameter tool with an output schema and readOnlyHint, the description covers the core operation, but it omits practical details an agent needs: which path or file extensions are valid, whether the file is overwritten, and when to use the sibling render_thumbnail_to_path instead.

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 places 'output_path' in context as the render destination, but it adds no details about file format, absolute vs relative path, directory existence, or overwrite behavior. The parameter name is self-descriptive enough to avoid a lower 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 states a specific action ('Render'), the object ('the current scene'), the destination ('*output_path*'), and the mode ('using current render settings'). This clearly distinguishes it from render_thumbnail_to_path and the screenshot tools, despite the slight viewport/scene wording variance.

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 about when to prefer this over render_thumbnail_to_path, screenshots, or the execute_blender_code variants. The only contextual hint is 'using current render settings', which implies a full render rather than a thumbnail, but no exclusion or alternative is explicitly named.

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 readOnlyHint annotation, the description states 'Read-only; consults bundled RST files only' and discloses detailed matching semantics: whitespace tokenization, case-insensitivity, token placement requirements, stop-word removal, and rejection of regex. It also explains the meaning of index and context, giving the agent a clear model of how the tool behaves.

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 dense but every sentence serves a purpose: result structure, query semantics, parameter usage, and read-only status. It is well-organized with bulleted fields and clear separations between matching behavior and parameter 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?

For a search tool with four parameters and an output schema, the description covers return field semantics, query syntax, stop words, regex unsupported, context behavior, index behavior, and read-only access. Nothing needed for safe and correct invocation 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?

Schema description coverage is 0%, so the description must, and does, carry the full burden. It explains query tokenization and matching, defines context as symmetric surrounding paragraphs with default 0, and clarifies index as a way to retrieve a previous hit alone with widened text. Only max_results is left to its self-explanatory name, but it has a clear default.

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: 'Full-text search over the bundled Blender Python API reference.' It clearly distinguishes itself from siblings like search_manual_docs and get_python_api_docs by naming the API reference as its target rather than the manual or a doc retrieval operation.

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 on when to use the tool: any full-text search over the bundled Python API reference. It explains natural query phrasings, stop-word dropping, and the lack of regex support, but it does not explicitly say 'use search_manual_docs instead when searching the manual' or otherwise state 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?

Annotations only declare readOnlyHint=true. The description goes well beyond that by explaining query matching semantics, case-insensitivity, stop-word dropping, lack of regex support, the symmetric context widening, the index re-query behavior, and explicitly stating 'Read-only; consults bundled RST files only.' No contradiction with annotations exists.

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-organized: front-loaded purpose, bulleted return fields, then crisp parameter and matching semantics. Every sentence adds information, and there is 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?

Given the tool's moderate complexity, the description covers the purpose, matching behavior, result fields, and the two non-obvious parameters (context and index). The output schema exists, so return-value details are already structurally available. The only minor omission, explicit max_results behavior, is inconsequential.

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 carries the parameter-documentation burden. It clearly explains query tokenization, the context parameter's symmetric widening, and the index parameter's role in retrieving a previous hit alone. max_results is not explicitly described, but its meaning is self-evident from the name.

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: 'Full-text search over the bundled Blender user manual.' This clearly distinguishes it from the sibling search_api_docs, which targets API documentation. The bulleted return fields further clarify exactly what the tool produces.

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 detailed behavior context, such as tokenization, stop-word removal, and the use of context/index. However, it never explicitly tells the agent when to choose this tool over search_api_docs or other siblings, and it names no alternatives or exclusion conditions. Usage is implied by the resource name rather than stated.

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