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

With no annotations, the description carries the full burden and does well: it discloses the recording semantics of the transaction, that rollback reverts all recorded calls, and the specific failure mode TRANSACTION_ACTIVE when one is already open. Missing details such as permission requirements or nesting behavior keep it from a 5.

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

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

Front-loaded with the core action, then the parameter note, then the error condition, each in its own compact block. Every sentence earns its place; no filler or repetition.

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

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

An output schema exists, so return values need not be described. For a single-optional-parameter transaction opener, the definition covers semantics, parameter meaning, and the key failure mode, leaving nothing an agent needs before calling it.

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

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

Schema coverage is 0%, so the description must compensate, and it does: the label parameter is explained as an optional name marking the starting point, with a concrete example ("layout") and its use case (later rollbacks by name). This adds real meaning beyond the bare string type in 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?

States a specific verb and resource ("Open a transaction") and explicitly names the sibling that undoes it (blender.rollback_transaction), so the agent can separate it from the rollback path. It does not contrast with the other transaction siblings (commit_transaction, checkpoint), so the differentiation is partial rather than complete.

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?

"Every mutating call until commit or rollback is recorded" communicates the intended position in the workflow (open before mutating, close via commit/rollback), and the named rollback_transaction alternative gives context. There is no explicit when-not or comparison to checkpoint, so it falls short of full routing 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?

With no annotations, the description carries the burden and does well: it explains the effect ('a later rollback can stop there instead of unwinding everything') and the consequence for partial work ('discards only the details'). It does not state what happens if no transaction is open or if the label already exists, so minor gaps remain.

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

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

Front-loaded with purpose, followed by a compact worked example and a one-line parameter note. Every sentence earns its place, though the build-stage example is slightly more verbose than strictly necessary.

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

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

An output schema exists, so return values need not be explained, and the description covers purpose, workflow, and the one parameter's constraint. It omits edge-case behavior (no open transaction, duplicate label), which would round it out fully.

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

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

Schema coverage is 0%, so the description must compensate; it adds the key constraint that 'label' is required and 'unique within the transaction', which the bare string schema does not convey. However, it gives no format or syntax guidance, leaving the compensation partial.

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

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

The description states a specific verb and resource ('Record a named point inside the open transaction') and immediately clarifies its role relative to rollback. An agent can distinguish it from begin_transaction, commit_transaction, and rollback_transaction without opening any schema.

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

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

It gives an explicit usage pattern ('begin -> build the shell -> checkpoint "shell" -> add the details -> commit') that makes the when-to-use condition concrete. It does not name when-not-to-use or explicitly contrast with sibling tools, so it falls just short of a 5.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses that undo steps remain on Blender's undo stack (so the commit is not an irreversible destruction of history) and names a specific failure mode. It does not cover permissions, rate/scope limits, or whether other sessions see the change.

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 no filler: the primary effect is front-loaded, followed by the reversibility note and the error condition. Every sentence adds information an agent needs.

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

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

An output schema exists, so return values need no explanation, and with zero parameters the only real gaps were behavior and failure modes, both of which are addressed. What remains unstated is how this interacts with the sibling transaction tools (e.g. an implicit open begin_transaction), a minor omission for a simple commit primitive.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No param documentation 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 verb and resource ('Close the open transaction and keep the changes'), and the phrase 'keep the changes' implicitly contrasts with rollback_transaction's discard semantics. It stops short of naming the sibling, so an agent must infer the pairing from the sibling list rather than the description.

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 'keep the changes' framing gives clear context for when to call this versus discarding work, and the stated TRANSACTION_NOT_ACTIVE precondition tells the agent an open transaction must exist first. There is no explicit routing to begin_transaction or rollback_transaction for the when-not case, which keeps it below a 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses that duplicate names fail with OBJECT_ALREADY_EXISTS rather than being silently renamed, that coordinates are in Blender units (meters), and that rotation is in degrees applied in XYZ Euler order. It stops short of covering mutation side effects on the scene, undo/transaction interaction, or permissions.

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

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

One summary sentence followed by a parameter glossary and a compact JSON example; every line adds information and the most important scoping fact leads. No padding or repetition of 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 6-parameter creation tool with an output schema present (so return values need not be described) and no annotations to lean on, the description covers nearly everything an agent needs, including error behavior. The only real hole is the undocumented 'collection' parameter.

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 only 33%, so the description must compensate, and it largely does: units and [x, y, z] vector format for location/scale, degrees and Euler order for rotation, enum values and case tolerance for type, and uniqueness semantics for name. The 'collection' parameter, however, receives no mention anywhere, leaving one of six parameters undocumented.

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

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

States a specific verb+resource ('Create a mesh object') plus a scope constraint ('in the active scene'), which an agent can immediately distinguish from siblings like update_object, delete_object, and get_object. The primitive-type listing further pins down what is created.

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 never says when to reach for this tool versus alternatives such as clone/instance creation or execute_python, nor does it state exclusions. Usage is only implied by the tool name and the create semantics.

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

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

With no annotations, the description carries the full burden, and it does disclose a pre-flight existence check and the OBJECT_NOT_FOUND failure mode. However, it omits whether the deletion is reversible, whether it can be committed/rolled back within a transaction, and what permissions or scene state are required.

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, operation stated first, failure mode second. No filler and nothing buried.

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

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

An output schema exists, so return values need not be described. But for a destructive mutation with zero annotation coverage embedded in a scene with explicit transaction siblings, the description should address reversibility or transaction interaction to be 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?

One parameter, "name", at 0% schema description coverage. The description clarifies that the name must refer to an existing object in the active scene, which adds a real constraint beyond the bare schema, but does not specify lookup semantics (exact match, path, case sensitivity).

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

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

Specific verb ("Delete") plus resource ("an object from the active scene"), with scope made explicit. The verb alone cleanly separates it from create_object, update_object, and get_object among the siblings.

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

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

The action implies its own usage, but nothing states when to reach for this over alternatives like update_object, nor whether the deletion participates in the transaction tools (begin_transaction/commit/rollback) that sit alongside it. Usage is inferred rather than guided.

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

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

With no annotations, the description carries the full behavioral burden and does so richly: it names the two failure modes and their error codes (VALIDATION_ERROR, PYTHON_EXECUTION_DISABLED), the ALLOW_PYTHON_EXECUTION server flag, the exact rejected constructs, and the explicit 'policy screen, not a sandbox' caveat about Blender's own API power.

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

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

Front-loaded with the purpose and the return convention, then restrictions, then error/failure conditions in a logical order. The example earns its place for a code-execution tool, though the repeated 'Otherwise' connective and the trailing policy paragraph add some length.

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

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

Despite no annotations and a minimal schema, the description covers purpose, parameter conventions, failure modes, and return behavior (even though an output schema exists). An agent has everything needed to call it correctly or decide against it.

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% for the single `code` parameter, so the description must compensate, and it does: available imports, banned operations, the `result` assignment convention for structured output, and a worked example together give far more meaning than the bare 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?

States a specific verb and resource — execute Python inside the running Blender — and clarifies the return convention (`result` variable). It is unmistakably distinct from the structured siblings like get_objects, create_object, or render.

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 signals the intended audience ('a trusted, local AI client') and warns that enabling the tool is a deliberate choice, which implies caution, but it never says when to prefer this over the structured siblings or when it is inappropriate. Usage is implied rather than routed.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses ordering ('newest first'), the significance of statuses 'refused' and 'replaced,' and that the tool answers even when no Blender is connected. These are exactly the runtime traits an agent needs to interpret results correctly.

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

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

Three tightly written sentences with no filler. The core purpose is front-loaded, and each subsequent sentence adds distinct behavioral or usage context.

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

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

Given that the tool has no parameters and an output schema exists, the description is complete enough for correct selection and invocation. It explains purpose, usage context, ordering, status semantics, and fallback behavior without needing to restate return fields.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly avoids implying any parameters, and the empty schema is fully covered.

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

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

States a specific verb and resource: 'List the Blender instances that have connected to this server, newest first.' It also distinguishes this tool from all siblings by explaining that the active instance is what every other tool acts on, so an agent can tell this is the connection-history tool rather than an object/scene tool.

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

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

Provides clear context for when to call it: 'useful first call after a connection error,' and explains that the active instance is the target of every other tool. It does not explicitly state when not to use it or name an alternative, but no sibling appears to serve the same purpose.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose one concrete failure mode (OBJECT_NOT_FOUND for a missing name), which is genuinely useful. It is silent on the read-only/safety profile, permissions, and whether the name is scoped to the active scene, so it is helpful but incomplete.

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: the payload contents are front-loaded and the error condition is appended without padding. Every clause 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?

Returned fields are covered by the output schema (and restated), and the failure mode is documented, so an agent has what it needs to call and interpret a read. It could be slightly more complete by routing to get_objects for plural lookups.

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

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

Schema description coverage is 0%, but there is only one self-evident parameter ('name'). The description adds that a nonexistent name is an error case, clarifying that name must identify an existing object; it still omits format details such as exact-match or case sensitivity.

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

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

States a specific verb and resource ('Return the full detail of a single object') and immediately contrasts with the plural sibling get_objects by scoping to 'a single object'. It even enumerates the returned detail, so an agent knows exactly what it gets without opening the output schema.

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

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

The phrase 'single object' implies this is the singular counterpart to blender.get_objects, giving implied usage guidance. However, it never explicitly says when to prefer this over get_objects, get_scene, or get_instances, and lists no 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?

No annotations are supplied, so the description carries the full burden, and it does disclose the read-only listing nature, the page window semantics, and what "total"/"truncated" mean for deciding whether to page. It omits permission/authorization expectations and does not state reversibility (moot for a read), which keeps it just under a 5.

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

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

Front-loaded purpose sentence, then a tight per-parameter block, then the return/paging note. Every line earns its place and nothing is repeated or padded.

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 filtered, paginated list tool with five optional parameters the description covers purpose, sibling routing, all parameters, and pagination behavior; the output schema already handles the return shape, so nothing an agent needs to call it 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%, so the description must compensate fully, and it does: every one of the five parameters is explained with examples (""MESH", "CAMERA", "LIGHT""), semantics (case-insensitive substring, only objects linked to the collection), and constraints (limit 1-500, offset skip count). This adds real meaning beyond the bare property names and defaults.

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

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

States a specific verb and resource ("List objects") with the distinguishing scope ("with filters and a page window") and explicitly contrasts itself with the sibling blender.get_scene for large scenes. An agent can tell it apart from get_scene/get_object without opening any schema.

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

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

Gives a clear usage condition: use this when the scene is too large for blender.get_scene to be useful, and the paging fields tell the agent when to request the next page. It does not mention other plausible alternatives (e.g. blender.get_object for a single object, blender.get_instances), so it falls short of naming explicit when-not cases.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose the key behavioral traits: results are truncated at object_limit (200 by default), an objects_truncated flag signals overflow, and no mesh data is returned. It stops short of stating read-only/safety or any permission requirements, which for a read-style tool is a minor omission.

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

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

Front-loaded with the return summary, then usage routing, then the truncation caveat and the mesh-data exclusion. Four tight sentences, each carrying distinct information, with no filler.

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

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

An output schema exists, so return values need not be re-explained, yet the description still covers the practical invocation facts (default limit, truncation flag, paging escape hatch, absence of mesh data). Nothing an agent needs to call this 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 coverage is 0% and the single parameter is bare, but the description compensates by explaining that at most `object_limit` objects are inlined and that 200 is the default, plus the related objects_truncated output signal. That gives real meaning beyond the schema, though the parameter's exact interaction with paging is only implied.

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

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

States a specific verb+resource ('Return a compact, LLM-sized summary of the active scene') and enumerates exactly what is returned: object names/types/transforms/visibility, collections, cameras, lights, active object, render engine, current frame. This is clearly distinguishable from sibling readers like blender.get_object (single object) and blender.get_objects (paged listing).

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?

'Use this first to see what exists' gives an explicit ordering/entry-point instruction, and it names the alternative ('use blender.get_objects to page through the rest') together with the triggering condition ('when objects_truncated is true'). When-to-use and the alternative are both spelled out.

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 zero annotations, the description carries the full burden and does reasonably well: it discloses the return values, warns that "Render time grows quickly with resolution and samples," and clarifies that omitted args preserve current scene settings (implying overrides may mutate scene state). It stops short of stating whether the call blocks or what permissions/preconditions apply.

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

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

Front-loaded purpose sentence followed by tightly formatted per-parameter notes and a closing perf tip; every line earns its place. Slightly verbose but no padding.

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 5-param, all-optional render tool with an output schema and no annotations, the definition covers parameters, defaults, side-effect-preserving omissions, and cost trade-offs. The main gap is routing guidance versus blender.render_preview and confirmation of blocking/async behavior, but the return values are covered by the output schema.

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

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

Schema description coverage is 0%, so the description must compensate and it does: each of the 5 params gets real semantics — engine ids with an example and a pointer to blender.get_scene, resolution units in pixels, samples behavior (ignored by non-sampling engines), and output_path path conventions. This is meaningful context well beyond the schema's bare anyOf/null 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?

States a specific verb+resource ("Render the active scene with the current camera") and even names the return payload (output path and wall-clock render time). It is clear on its own, but it never mentions the sibling blender.render_preview, so an agent must infer which of the two rendering tools to pick.

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 perf note ("prefer 512-1024 px while iterating") and the per-parameter "Omit to keep..." defaults imply a usage posture, and the engine note routes to blender.get_scene for valid ids. However there is no explicit when-to-use or when-not-to-use guidance and no comparison against blender.render_preview, which is the obvious alternative.

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

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

With no annotations, the description carries the burden and does well: it discloses the return format (image vs. file path via include_image), that size and samples are capped, and the context cost of larger max_edge. It does not state whether supplying engine/samples mutates scene state, which matters for a tool that can alter the active render configuration.

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

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

Front-loaded with purpose, then a compact per-parameter block, then the sibling routing rule last. Every line carries information; nothing is redundant with the schema titles.

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?

No output schema exists, yet the description explains what comes back (image or path) and the tradeoff governing it, so an agent can call it correctly. The only unaddressed gap is whether render settings persist in the scene after the call.

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 fully compensates: max_edge gets a range (64-2048), a default (512), and cost rationale; engine and samples are marked optional with 'omit to keep current/cheap default'; include_image's false behavior is spelled out.

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

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

States a specific verb and resource ('Render a small preview and return the image') plus the agent-facing rationale, and implicitly contrasts with the sibling blender.render by calling it a 'preview'.

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 'Prefer this over blender.render while iterating' and names the alternative for the opposite case ('Use blender.render for a final image the user will keep'), so the selection condition is unambiguous.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the restoration scope, the critical limitation that blender.execute_python edits are untracked (so a mixed transaction only rolls back its tool calls), and the specific error raised when no transaction is open. This is exactly the behavioral context an agent needs for a mutation tool.

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

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

Front-loaded with the core action, then parameter semantics, then restoration scope and caveats, closing with the error case. Every sentence carries distinct information with no repetition of the tool name or title.

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

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

An output schema exists so return values need not be explained; the description instead covers the operation's scope, the untracked execute_python edge case, and the failure mode. For a one-parameter transaction mutation tool, nothing an agent needs in order to call it 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% for the single `to` parameter, so the description must compensate and does: it defines `to` as an optional checkpoint label, explains the omit-vs-name semantics, and pairs it with the rewind target behavior. Nothing about the parameter is left ambiguous.

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

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

States a precise verb ('put back') and the exact resource scope (everything the transaction changed), then enumerates what gets restored: transforms, names, visibility, materials and collection membership. An agent can distinguish this from commit_transaction and begin_transaction without opening any schema.

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

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

Clearly specifies the two usage modes of the tool via the `to` parameter (omit to rewind to transaction start, name a checkpoint to rewind to it) and the failure condition TRANSACTION_NOT_ACTIVE. It does not explicitly state when to prefer rollback over commit_transaction or confirm the transaction closes afterwards, so guidance is clear but not exhaustive.

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

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

With no annotations, the description carries the full burden and delivers: explicit unit conventions (meters, degrees), the OBJECT_ALREADY_EXISTS failure for name collisions instead of silent 'Name.001' renaming, the side effect that a missing material is created, and the 'material_created' response flag. These are non-obvious behaviors an agent could not infer from the 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?

Front-loaded with the partial-update rule, then a scannable field-by-field list where every line contributes new information (units, error behavior, or side effects). No filler sentences.

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 9-parameter mutation tool with no annotations and no schema descriptions, the definition covers semantics, units, error cases, and side effects thoroughly, and an output schema exists to cover return values (which the description still references via 'material_created'). Nothing essential to 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 compensate, and it does: it defines units and axis order for location/scale/rotation/dimensions, notes dimensions replaces scale, and explains that material_color is only used when creating a material and sets both viewport colour and shader. Only the obvious 'name' identifier is left implicit.

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

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

The description opens with a specific verb+resource ('Change an existing object') and immediately scopes it as a partial update ('Only the fields you pass are touched'). This clearly distinguishes it from sibling create_object/delete_object, which operate on different lifecycles.

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 gives strong operational context — omitted fields retain their current value, and material is created on demand — which tells the agent how to call it safely. However, it never names an alternative (e.g. create_object for new objects, or the transaction siblings) or states when not to use this tool.

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

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

With no annotations, the description carries the full burden and does well: it discloses early-return-on-change semantics, the 0-60s timeout window, and clarifies that changed=false is a valid answer rather than a failure. It does not state whether the call blocks/side effects or permissions, but for a passive wait this is minor.

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

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

Front-loaded with the core behavior, then parameters, then return shape — a logical order with no filler sentences. Slightly long for three parameters, with some prose that could be tightened, but nothing is wasted.

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

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

No output schema exists, and the description supplies the exact return keys (changed, changes, waited, changed_objects) plus their interpretation. Combined with usage guidance and parameter semantics, an agent has everything needed to call and interpret this tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate fully and does: it gives timeout's range and default, explains objects as an optional narrowing filter with explicit omit behavior, and explains include_image's purpose. Every one of the 3 parameters gains meaning beyond the bare schema 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?

States a specific verb and resource ('wait until the scene changes, or until timeout seconds pass') and immediately differentiates itself from the read-everything siblings ('instead of reading the whole scene again'). An agent can distinguish it from blender.get_scene or blender.render without opening any schema.

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

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

Explicitly names the situation to use it ('after a change you are unsure about') and the alternative it replaces ('instead of reading the whole scene again'). It also specifies the include_image condition to avoid a second render call, which is concrete routing guidance.

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