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

Annotations already declare destructiveHint=true and idempotentHint=true; the description adds genuinely new context beyond them: it is a proposal that needs Blockbench approval, it preserves artist-painted pixels, and it does not touch geometry or animations. That materially narrows the blast radius the agent would otherwise assume from destructiveHint. What is not disclosed is what happens if approval is denied, or how the approval is obtained.

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

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

Three short sentences, front-loaded with the core action and followed by the two most decision-relevant constraints. Nothing is padded, though the 'Requires Blockbench approval' fragment could be tied more tightly to the action.

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?

With an output schema present, the description needn't explain return values. Given a destructive, approval-gated mutation, it covers the essential surprises: it is a proposal, artist pixels survive, geometry/animation are untouched, and request_id retry semantics are handled in the schema. Little an agent needs in order 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 description coverage is 50%, and only request_id carries a description; the nested palette object (primary/secondary/eyes) is structurally well-defined with hex patterns but has no field-level prose. The description only gestures at 'recoloring the atlas' and adds no meaning about what each palette slot controls or how it interacts with preserved artist pixels.

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 (recoloring) and resource (VoxelFlow atlas) plus a scope constraint (preserving artist-painted pixels, no geometry/animation rebuild). It is clear what the tool does, though it never names or contrasts itself with the sibling apply_prop_materials, which appears to be the near-neighbor for props.

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 'Requires Blockbench approval' implies a prerequisite gate, and 'Propose' signals this is not an immediate commit. But there is no explicit when-to-use versus when-not, and no routing to a sibling (e.g. use apply_prop_materials for props instead).

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 idempotentHint=true, so the description adds value by disclosing the approval gate and that other materials, painted pixels and geometry are preserved — softening the practical blast radius of a destructive update. It does not mention retry/idempotency behavior, though the schema's request_id field covers that.

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?

Four short sentences, front-loaded with the action and resource, then precondition, partial-update rule and approval gate. No filler and nothing that could be trimmed without losing information.

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

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

With a rich schema, an output schema and detailed annotations, the description supplies the remaining operational essentials: prerequisite inspection, preservation guarantees and approval requirement. Minor gaps (what happens when a supplied material name doesn't exist, how to recover via undo/get_operation) are not covered.

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 100%, so the baseline is 3; the description goes beyond it by instructing 'supply only the names/colors to update' (confirming partial-update semantics) and by requiring that names be real material names read from inspect_project, a constraint the schema's pattern does not express.

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: 'propose changing named colors on an existing VoxelFlow prop.' The scope (existing prop, named colors only) is clear, but it never explicitly distinguishes itself from the sibling tool apply_materials, leaving the model-vs-prop split to inference from 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?

Gives a concrete precondition ('First inspect_project to read its actual material names') and workflow context ('Requires Blockbench approval'), which tells the agent how to sequence the call. It stops short of naming when to prefer this over apply_materials or when not to call it at all.

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 this is non-read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context beyond that: cancellation leaves the scene unchanged, and running exports cannot be cancelled through this 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?

Two short sentences, both front-loaded and purposeful. The primary action is stated first, followed immediately by the key exclusion.

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 rich annotations and an output schema, the description covers purpose, safety context, and the main unsupported case. It is nearly complete, though it could explicitly mention that the operation must still be pending.

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 100%, and the schema already explains operation_id plus retry semantics. The description adds no parameter-specific meaning, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and target: cancel a pending approval, and it explicitly excludes running exports from this tool. This makes the core purpose clear, though it does not explicitly contrast with siblings such as get_operation or undo_last_change.

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 a clear usage boundary: use this for pending approvals, but cancel running exports in the native Save dialog instead. It does not mention when to use get_operation first or how this relates to undo_last_change, so it falls short of full alternative routing.

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

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

Beyond the annotations it discloses the key behavioral traits: the asynchronous approval gate (pending_approval), the requirement for human approval in Blockbench, and the follow-up via get_operation. The 'eye color is bright cyan, not an emissive shader' note heads off a likely spec misunderstanding. With destructiveHint=true and idempotentHint=true already declared, the description's only minor gap is not spelling out exactly what state a new project tab mutates.

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 core action and destination are front-loaded, and the workflow (approve, then poll) follows logically. Sentences are dense and purposeful, though the trailing eye-color remark is slightly tangential to the invocation itself.

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 nested, async, approval-gated mutation tool, the description covers the essential flow: what is created, that it needs human approval, and how to follow up. Return values are backed by an output schema, so the mention of pending_approval suffices; only the deeper spec-field semantics remain under-explained.

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 50% and the spec object is large and nested, so the description should compensate more. It touches palette colors and animation clips, but gives no meaning for build, detail, height, template, or namespace fields; request_id's retry semantics are already documented in the schema. Partial, not full, compensation for the coverage gap.

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

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

The description states a specific action (propose an editable humanoid robot with palette, articulated rig, and idle/walk/attack clips) and a concrete destination (a NEW Bedrock project tab). It also scopes the tool with 'only robot/bedrock is implemented,' which implicitly distinguishes it from prop/other-template siblings like create_prop, though it never names that sibling explicitly.

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

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

It gives clear usage context: the call returns pending_approval, the artist must approve in Blockbench, then you poll get_operation. The 'only robot/bedrock is implemented' clause rules out unsupported targets. It stops short of explicitly routing prop creation to create_prop, so the alternative selection is only implied.

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

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

Goes well past the annotations: it discloses that geometry, part groups, PNG atlas and UVs are generated in a NEW Blockbench tab, that the call returns pending_approval and requires human approval followed by get_operation polling, and it warns not to claim emissive materials or gameplay behavior. The 'creates a new tab' framing is consistent with destructiveHint=true and idempotentHint=true.

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-loads what the tool does, then constraints, then the async/human-approval caveat. Dense but nearly every clause carries either a hard constraint or a behavioral warning. The listing of prop categories is somewhat enumerable-but-redundant with 'other objects representable by cubes'.

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 nested, 2-parameter creation tool with an output schema, the description supplies the missing operational picture: the approval/polling lifecycle, the scope exclusions, and the design contract (bounds, axes, materials). Nothing an agent needs to call it correctly is absent.

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 50%, and the description compensates with real design semantics: 1–128 named cube parts, 1–16 hex-color materials, coordinate/pivot bounds of -128..128, from < to, rotations in degrees, and axis convention (Y up, front negative Z). The 'organize related parts with group names; include recognizable silhouette' guidance adds meaning the schema cannot express. Minor gap: request_id semantics live only in the 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?

States a concrete verb+resource ('Create a Minecraft-style prop') and enumerates the supported object families, then draws explicit boundaries against sibling concerns: 'static prop, not a humanoid or a registered game item.' An agent can distinguish this from create_model, generate_rig, and apply_prop_materials without reading the schema.

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

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

Gives clear operating context — design a PropSpec yourself, no category whitelist or keyword parser, and the follow-up flow is spelled out ('wait for the artist to approve in Blockbench, then poll get_operation'). It doesn't name create_model or apply_prop_materials as the alternative for those cases, so routing for adjacent goals is left to inference.

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

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

Goes well beyond the annotations by disclosing the approval gate, the native Save dialog, the poll-until-applied loop, and the distinction between cancelled and success. It does not restate idempotency or the destructive hint, but the added workflow context is what an agent actually needs here.

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?

Terse, front-loaded, and free of filler – the ZIP contents come first, then the workflow constraints. The telegraphic phrasing ('Requires passing gates') is slightly clipped but every clause carries information.

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

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

An output schema exists so return values need no explanation, and the description covers the approval, save-dialog, and polling semantics plus the failure interpretation. The only minor gap is that it doesn't point at validate_asset or get_operation for the polling step.

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?

Only two parameters with 50% description coverage; request_id is fully documented in the schema (including retry guidance), while target is a fixed const. The description adds no parameter-level meaning, so the schema carries the load and the baseline of 3 applies.

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

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

States a specific verb ('Propose') plus the exact resource produced (a Bedrock asset ZIP) and enumerates the packaged contents (geometry, PNG, animations, controllers, entity, manifest, bbmodel, report). This is clearly distinguishable from siblings such as validate_asset or preview_animation.

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?

Explains the operational preconditions (passing gates, editor approval, native Save dialog) and warns that 'cancelled is not success' and no arbitrary output path is accepted, which tells the agent how to interpret outcomes. It stops short of explicitly naming prerequisites like validate_asset as the alternative or prior step.

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 idempotentHint=true; the description earns credit by bounding the destruction ('Replaces only the named preset clips') and clarifying that speed/intensity are non-destructive ('do not rebuild the model'). It does not restate idempotency, but that is covered by the request_id doc in 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?

Two dense sentences, zero filler, with the object and the replacement scope front-loaded. Every clause (validation prerequisite, approval gate, clip scoping, non-rebuild note) carries distinct information.

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

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

Output schema exists so return values need no explanation, and annotations cover safety. The description adds the prerequisite and the destructive scope, leaving only minor gaps such as which sibling produces the 'validated mapped humanoid'.

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 50%: request_id is well documented in the schema, but the nested options (clips/speed/intensity) have no field descriptions. The description partially compensates by naming idle/walk/attack as the clip presets, but adds no semantics for speed or intensity ranges/effects, so it is only baseline.

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 (propose) and resource (native idle/walk/attack keyframes) with the target object (a validated mapped humanoid). It does not name the nearest sibling preview_animation, so the agent must infer that this generates/replaces clips while preview only inspects 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?

'for a validated mapped humanoid' gives an explicit prerequisite, and 'after approval' signals the gating step before this runs. It stops short of naming alternatives like preview_animation or validate_asset, so the when-not guidance is only implied.

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

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

Adds real context beyond the annotations: an approval gate, conservative exact/alias detection, and a stated non-effect ('does not invent joints or move imported geometry'). What it does not address is destruction — destructiveHint is true but the description never says whether an existing rig or prior mapping is replaced, which is the main open risk.

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?

Four short sentences, front-loaded with purpose, then detection behavior, then non-goals, then preconditions. Every sentence carries distinct information with no restatement of the name or 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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. For a destructive, approval-gated tool with a nested 11-key object, the description covers preconditions, detection behavior and side-effect boundaries; only the concrete effect on any pre-existing rig 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 50%, with request_id already documented in-schema, so the burden falls on the mapping object. The description compensates by stating that all 11 bone names should be supplied under ambiguity, effectively explaining the nested object's contract; the retry semantics of request_id are covered by the schema itself.

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: 'Propose a body-part mapping for an existing humanoid hierarchy,' which also clarifies that this proposes rather than authors a rig from scratch. The 'existing humanoid hierarchy' qualifier implicitly separates it from creation tools like create_model, though no sibling is named explicitly.

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

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

'Requires approval and a valid existing hierarchy' gives a clear precondition, and 'provide all 11 mapped bone names when detection is ambiguous' tells the agent when to switch from relying on auto-detection to supplying the full mapping. No explicit when-not or named alternatives, so it stops 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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is free. The description adds genuine context beyond that: the tool reports unavailability as connected:false rather than erroring, and it explicitly promises never to simulate an editor — an important anti-hallucination guarantee for an agent deciding whether downstream calls are safe.

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

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

Two short sentences, front-loaded with what is read, followed by the failure semantics. Every clause carries information an agent needs; nothing is 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 and covers the return shape, so the description is not obliged to enumerate fields. Given the low complexity, the description plus annotations is nearly sufficient; the only soft gap is lack of guidance on how this relates to sibling inspection tools or whether it is cheap to poll.

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 dimension hits the 0-param baseline of 4. There is nothing for the description to disambiguate, and it correctly avoids inventing parameter talk.

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 ('Read') and enumerates the resource set it reports on: connection, project, version and format. This is distinguishable from the inspection/creation siblings, though it never explicitly contrasts itself with inspect_project, which is the nearest neighbour.

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 framing as a live 'status' read implies it is a preflight/health check before other operations, but no explicit when-to-use, when-not, or alternative is named. The 'connected:false' clause conveys the failure branch, which is a partial substitute for usage guidance rather than full 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that by explaining the status vocabulary and the timeout-retry contract, which annotations cannot express.

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

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

Three short sentences, front-loaded with the core action, then status meanings, then retry guidance. Efficient, with only mild redundancy against the schema's own retry note.

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 shape needn't be described; the description supplies the status semantics an agent needs to interpret it and the retry rule for uncertain commands. Complete enough for a single-parameter read 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 coverage is 100% and the schema description already states 'Reuse the SAME ID and parameters when retrying; never regenerate on a timeout', so the description's retry sentence largely duplicates structured data. The 'request_id' vs 'operation_id' naming mismatch slightly detracts rather than adds.

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 ('Read a proposed operation by its request_id'), clearly distinct from siblings like cancel_operation, get_editor_status, and preview_animation. Minor flaw: it calls the key 'request_id' while the schema names it 'operation_id', which could momentarily confuse an agent.

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 concrete usage context by interpreting result states (applied = completed, pending_approval = artist must approve in Blockbench) and prescribes retry behavior with the original ID and parameters. It stops short of naming an alternative tool for cancellation, which the cancel_operation sibling would cover.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered. The description adds one useful behavioral nuance — keyframes come back as 'summaries' rather than raw data — but says nothing about size, cost, or how 'actual' geometry differs from a summarized form.

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 noun names a distinct category of returned data.

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

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

An output schema exists, so return-value structure needn't be explained, and annotations cover the safety profile. The only gap is the absent routing guidance against get_editor_status, which for a zero-parameter inspection tool is a minor omission.

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; the baseline of 4 applies.

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

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

States a specific verb (Read) and enumerates exactly what is returned: geometry, bone mapping, textures, and keyframe summaries of the active Blockbench project. It is clearly distinct from the create_*/generate_* siblings, though it never explicitly contrasts itself with get_editor_status, the closest read-only 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?

There is no statement of when to call this versus get_editor_status or the generators. The only usage signal is the implicit scope, 'active Blockbench project', leaving the agent to infer that this should be run before rigging or animating.

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 non-readonly, non-destructive, non-idempotent, so the agent knows this changes editor state safely. The description adds the key behavioral fact that playback happens in the 'real' timeline and that content is untouched, which is exactly the context annotations can't convey.

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

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

Two short sentences, front-loaded with the action, followed by the disambiguating constraint. 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?

Output schema exists, so return values needn't be explained, and purpose plus non-goals are covered. Minor gaps remain around playback switching behavior and whether the call fails if no project/animation exists, but the definition is sufficient to invoke 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. 'Select' maps to the clip enum and 'play or stop' implies playing=true/false, but it never names the parameters, states the default of playing=true, or says what happens if a clip is requested while another is playing.

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: select and play/stop an existing idle/walk/attack clip in the real Blockbench animation timeline. The explicit negative scope ('Does not create or edit keyframes') clearly separates it from generate_animations and any keyframe-editing 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 exclusion ('Does not create or edit keyframes') tells the agent when not to use it, which is the most likely confusion given siblings like generate_animations. It stops short of naming an alternative or stating prerequisites (e.g., a project must be open), so it is clear context rather than 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?

Annotations declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, and the description adds real context beyond them: the action is a *proposal* requiring editor approval, the mechanism is native Undo, and the tool self-limits to the most recent edit. It does not say what happens to edits after the proposal is approved or rejected, but the approval gate is the crucial behavioral detail an agent needs.

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

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

Three short sentences, each earning its place: what it does, what it excludes, what it requires. The primary action is front-loaded 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 needn't be described, and annotations cover the safety profile. The description still conveys the mechanism and approval gate, but it leaves open what a proposal looks like downstream or how a failed undo is surfaced — minor gaps for a one-parameter tool.

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

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

There is one parameter (request_id) and the schema documents it at 100% coverage, including the retry rule about reusing the same ID. The description adds nothing about it, but the schema already carries the full burden, so the baseline 3 applies.

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

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

States a specific verb and resource: 'Propose undoing the most recent VoxelFlow edit using native Undo.' The scope limit ('most recent', 'native Undo') separates it from anything else in the sibling list, though no sibling alternative is named because none offers undo.

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 both a when ('most recent VoxelFlow edit') and a when-not ('Refuses to undo unrelated artist edits'), plus the prerequisite 'Requires editor approval.' Clear context, but it never names an alternative path for edits outside its scope, so it stops 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is fully covered. The description adds two useful traits beyond that — 'deterministic' (repeatable results) and 'LIVE project' (validates current state, not a file) — but says nothing about failure behavior, whether it blocks export, or how issues are reported.

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 scope of the checks comes first and the disclaimer second. Every clause carries information an agent can act on.

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?

With an output schema present, the description needn't describe return values, and the annotations carry the safety profile; the check list plus the compatibility disclaimer make the tool callable without further reading. The only gap is workflow placement — no statement of when in the create/generate/export sequence this gate belongs.

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

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

The tool takes no parameters, so there is no parameter semantics to explain and nothing for the description to compensate for. 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?

States a specific verb ('run deterministic quality gates') against a specific resource ('the LIVE project') and enumerates the checks covered: geometry, hierarchy, pivots, texture/UVs, native keyframes. It does not name or contrast with any sibling (e.g. inspect_project or export_asset), so the agent must infer the boundary itself.

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

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

Usage is only implied — the checklist reads like a pre-export gate, but nothing says when to call it versus inspect_project or what to do with the result. The one genuine guideline is an exclusion: it explicitly does not certify Minecraft runtime compatibility, which at least bounds the tool's authority.

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