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

Annotations already declare this as a non-read-only, non-idempotent, non-destructive mutation, so the safety profile is covered. The description adds one genuine domain behavior ('looping animations should end on the pose they start with'), but says nothing about duplicate names, whether the new animation is returned or how it is addressed later, or what happens when length conflicts with later keyframes.

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 purpose and followed by the one non-obvious rule. Nothing is redundant, though the second sentence is somewhat cryptic without context about pose matching.

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 three-parameter mutation with no output schema and no nested structures, the core is present: what it creates, examples, and a looping constraint. Missing pieces are modest but real — how the created animation is referenced afterward and how it relates to add_keyframes.

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 67%: 'loop' and 'length' are documented in the schema, while 'name' is only constrained by a regex pattern. The description adds a small amount of meaning around looping behavior but never explains the name pattern, the loop/once/hold modes, or the length default, so it does not compensate for the 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 uses a specific verb and resource ('Adds an animation') and gives concrete examples ('idle, walk or attack') that make the domain obvious. It does not explicitly distinguish itself from nearby siblings such as add_keyframes or add_bones, so it stops short of a 5.

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

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

There is no statement about when to call this versus add_keyframes or when not to call it, and no prerequisites (e.g. whether an animation must be created before keyframes can be added). The looping-pose sentence is an authoring constraint, not usage 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?

Annotations only mark this as a non-idempotent, non-destructive mutation; the description goes further by disclosing atomicity ("Nothing is created if any entry is bad") and a uniqueness constraint not present in the schema. It does not cover error reporting, partial-failure output, or the 512-bone ceiling, so it stops short of full behavioral disclosure.

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 purpose before the domain rationale and constraints. Every clause carries information; the only mild redundancy is restating the group concept in parentheses.

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 mutation tool with nested object parameters and no output schema, the description covers structure, ordering, naming, and failure semantics well. It omits hierarchy rules (can a parent appear later? can cycles form?), the 512-entry limit, and what identifiers come back, which an agent building a rig would benefit from.

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?

Top-level schema description coverage is 0% for the single `bones` array, so the description must compensate, and it does: it explains that names must be unique and that pivots belong at joints. Nested schema descriptions already cover pivot, parent, and rotation meaning, so the added value is the uniqueness rule plus the joint-placement 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?

States a specific verb and resource ("Adds bones (groups)") and immediately grounds it in the domain: bones are the animate-able containers that GeckoLib cubes belong to. That implicitly separates it from add_cubes and add_animation, though it never names those siblings directly.

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 sequencing guidance for the workflow: start with one root bone, then body, head, legs, placing pivots at joints. It does not explicitly say when to choose this over add_cubes or add_animation, but the ordering and containment rules effectively define the correct usage context.

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 state it mutates (readOnlyHint=false), is non-idempotent and non-destructive, so the safety profile is covered. The description adds a genuinely useful behavioural fact beyond that: creation is atomic — "Nothing is created if any entry is bad" — which tells the agent a single bad cube aborts the whole batch. It does not say what is returned or whether bones must pre-exist.

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, each carrying a distinct rule, with the mandatory geometry-choice guidance front-loaded ahead of the model-specific UV advice. There is no filler; the only weakness is that the terse phrasing assumes familiarity with GeckoLib/Java model formats.

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 mutation tool with no output schema and a 12-field nested cube object, the description covers the geometry and UV rules and the failure mode, but leaves gaps an agent would want: what the call returns, whether the cube lands in the current tab/project, and whether the referenced bone must already exist. Adequate but not 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?

Top-level schema description coverage is effectively 0% (the single "cubes" property is undocumented), so the description must carry the load and largely does: it explains the mutually exclusive corner/size pairs, the per-model requirement for bone and faces, and the box-UV sizing constraint for uv_offset. It stops short of explaining names, pivot, rotation, mirror or inflate, which only the nested schema covers.

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 ("Adds cubes") and immediately distinguishes two geometry conventions — blockbench from/to or origin/size — as well as GeckoLib box-UV versus Java per-face-UV models. It is clearly separable from the sibling add_bones, though it never names that sibling or any other 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?

It gives concrete selection rules: use from+to or origin+size, give each cube its own uv_offset for GeckoLib so UV islands do not overlap, and use faces only for Java models, which also need no bone. What is missing is when NOT to call it, or whether a target model/tab must already be open — no exclusions or prerequisites are stated.

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

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

Annotations already declare a non-read-only, non-idempotent, non-destructive mutation, so the safety profile is covered. The description adds channel-level unit semantics but says nothing about the operation's key behavioral risk: whether adding tracks merges with or overwrites existing bone/channel tracks, and whether duplicate keyframe times are rejected or overwritten. With annotations doing the safety work, a 3 is appropriate, though the merge/replace ambiguity is a real gap for a non-idempotent 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?

A single front-loaded sentence with high information density and no filler; the parenthetical unit notes earn their place by disambiguating channel values. It is arguably too terse for a mutation tool, but there is no wasted wording to cut.

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 three-parameter nested mutation with no output schema, the description covers purpose and value units adequately. What is missing is pipeline context (the target animation must exist, likely created via add_animation) and the append-versus-overwrite behavior, both of which an agent needs before invoking a non-idempotent write.

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 only 33%, so the description must carry weight — and it does give genuinely useful semantics that the schema omits: rotation in degrees, position in units, scale as factors. However, it leaves the `tracks` array structure, the `animation` reference parameter, and the three-level interpolation precedence (keyframe vs track vs top-level default) entirely to the schema, which only partially documents them.

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 ("Adds keyframe tracks to an animation") and immediately scopes the payload to per-bone and per-channel data. The per-channel unit notes (degrees, units, factors) further pin down what is being added. It stops short of differentiating itself from siblings like add_animation or add_bones, leaving the agent to infer the pipeline order.

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 "to an animation" implies the animation must already exist, but there is no explicit prerequisite statement, no pointer to add_animation for creating the target, and no guidance on when to use this versus other mutation tools. There are also no exclusions — e.g., whether tracks are appended or replace existing tracks for the same bone/channel.

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 real value by identifying precisely what is destroyed (only duplicate copies, never the first) and the safety predicate that prevents data loss (unmodified, matching copies). It does not say whether anything is returned (list of closed tabs) or what happens when nothing matches, which keeps it below 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?

Two sentences, front-loaded with the action and outcome, then the safeguard. Nothing is redundant and no sentence could be removed 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?

For a two-parameter tool with full schema coverage and no output schema, the description covers action, retention rule, and safety condition adequately. The remaining gaps are the return value and the parameter-interaction rule, which are minor given the tool's simplicity.

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 both parameters are documented in the schema, so the baseline is 3. The description's 'keeping the first' hints at selection order, but it adds no meaning about how `name` and `duplicates` combine or what an omitted `name` does.

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 ('Closes extra copies of a tab') plus the exact retention rule ('keeping the first'). No sibling tool deals with tabs, but the description still makes the operation and its outcome unambiguous without opening 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?

The description defines the guard condition under which a copy is closed (matching name, format, element and texture count, and no edits), which implicitly scopes usage. However, it never states when an agent should reach for this tool, when it should not, or how the two parameters interact (e.g., name plus duplicates=true).

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 and the description is not required to restate it. The description does add two useful behavioral facts: it reads from the currently open Java model (a state dependency) and that a bulk read returns only slots that are actually set. It says nothing about the shape of the returned transform data, which matters given there is no 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?

A single sentence with the resource front-loaded and the all-or-one behavior stated last; no filler or redundant restatement of the title. It is arguably too terse for the amount of implicit context, but nothing written 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?

For a read-only getter this is a moderate fit: the operation and its scope are covered, but with no output schema the description is the only place an agent could learn the structure of the returned display transforms, and it does not provide that. The requirement that a Java model be open is also only hinted at ('the open Java model').

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 explain the single 'slot' parameter, and it does so only at the level of 'every set slot, or one slot'. The enum itself already lists the eight valid slot names, but nothing explains what a display slot or a transform is, nor that omitting the parameter returns all set slots (this last point is the description's main contribution).

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

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

The description names a specific resource (display transforms) and constrains it to 'the open Java model', which pairs naturally with the title 'Read display transforms'. It is clear what is being read, though it never names the sibling display_set as the counterpart, so differentiation is inferred from the get/set naming rather than stated.

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 set slot, or one slot' is the only usage guidance: it tells the agent that omitting the parameter widens the read to all slots. There is no explicit statement of when to prefer this over display_set or display_screenshot, and no prerequisite such as needing a model already open, so usage 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?

Annotations flag this as non-read-only and destructive, and the description justifies that by disclosing the file side effect: PNGs are written to the output folder in addition to being returned. It stops short of tying that to the 'overwrite' behavior (default false) or saying what existing files are replaced.

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

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

Two tight sentences with the render/return behavior front-loaded and the two most surprising defaults (uncropped first person, gui square) immediately after. The parenthetical about the output folder 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?

For a 7-parameter, all-optional tool with no output schema, the description covers the return type (images) and file side effect, which is the minimum an agent needs. It leaves gaps on path-vs-slots interaction and overwrite semantics that the sparse schema descriptions do not fill.

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 71% and the undocumented 'crop' param is explained by 'First person is uncropped by default', which conveys the default cropping behavior. The slot enum's meaning is partly clarified ('gui is the inventory square'), though the relationship between 'path' and 'slots' stays 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?

States a specific verb+resource: renders display slots as the Blockbench display editor shows them and returns PNG images. It is distinguishable from the plain 'screenshot' sibling only by implication (the display-slot framing), not by an explicit contrast.

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?

Implies usage for inspecting item display slots and explains two defaults (first person uncropped, gui is the inventory square), but never says when to prefer this over 'screenshot', 'display_get', or 'export', and gives 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?

Beyond the annotations it discloses two traits the agent cannot see otherwise: the mutation is undoable, and partial updates merge so unmentioned fields survive unless replace is true. This meaningfully softens and explains the destructiveHint=true/idempotentHint=true profile, though it does not say what is destroyed on replace or whether a preset load clobbers existing slots.

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, zero filler: the action and its undoability are front-loaded, then the three input modes, then the merge rule. Every clause carries information the agent needs before calling.

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 7-parameter, zero-required, nested-object tool with no output schema, the description covers the actionable points: which parameters go together and how omission behaves. Missing is the conflict rule when multiple modes are combined and any mention of display_get for verification, which matters for a destructive mutation.

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 71% and already documents scale/translation/rotation ranges, so the baseline is high; the description goes further by explaining the interaction between omitted fields and the replace flag, which the schema does not state. It omits any guidance on whether slot and display are mutually exclusive or what preset resolves against beyond the schema's folder note.

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 ("Sets display transforms") and then enumerates the three mutually exclusive targeting modes: a "display" map for several slots, "slot" plus rotation/translation/scale, or a "preset" file. An agent can tell it is a write/set operation on item model display, though it never names the sibling display_get as the read counterpart.

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?

Clear guidance on how to invoke it: choose one of three input shapes, and omitted fields merge rather than overwrite. It does not say when to prefer this over display_get or display_screenshot, nor what happens if arguments from two modes are supplied together, so it stops short of full 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 flag destructiveHint=true and idempotentHint=true, so the description's key contribution is the nuance that existing files are kept unless overwrite is true — that materially clarifies how destructive it actually is in practice. It also discloses the per-format scope (animation file contains all animations, model only for Java). It does not cover partial-failure behavior or whether parent directories are created, which is why it isn't 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?

Two sentences, zero filler, and the artifact list is front-loaded before the overwrite caveat. Every clause carries distinct information about what gets written or what happens on collision.

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 five-optional-parameter write tool with no output schema, the description covers what is produced and the overwrite policy, which is most of what an agent needs. The notable gap is return behavior — whether it reports the written paths or a partial-success status — which matters given multiple optional artifacts can each fail independently.

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, but the description earns more by binding parameters to meaning the schema lacks: the model parameter is implicitly Java-only, and each path parameter is tied to a specific output artifact and extension. The overwrite flag's consequence (keep vs replace) is also restated behaviorally rather than just as a default value.

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 concrete verb ('Writes') and names the resource precisely: the open project's geo, animation, model and texture files. It even annotates the format of each artifact (.geo.json, .animation.json, .png), so an agent knows exactly what will be produced. It stops short of explicitly contrasting with sibling tools, though the write-to-disk framing is distinct enough on its own.

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

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

Usage is implied rather than stated: the agent must infer that a project should be open first, and there is no explicit 'use this instead of X' routing. The one real conditional it does give is valuable — the model export is 'Java projects only' — but the absence of any when-not or prerequisite statement keeps this at minimum-viable.

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=false and destructiveHint=false, so the agent knows this creates state without destroying anything. The description corroborates this by saying it opens a new tab with an empty model, and adds that preset files are read from the output or assets folder — useful side-effect context. It does not say what happens if the name already exists, whether a duplicate tab is created, or whether the new tab becomes active.

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 no filler. The clause 'Cubes need no bones' is terse to the point of being cryptic in isolation, but it earns its place as a real modeling constraint.

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 a nested display object and no output schema, the description covers the conceptual model and the preset/display relationship but omits the required 'name' parameter's role, the namespace/texture-linkage behavior, and any error or collision behavior on creation. Adequate to call it, incomplete for predicting its effects.

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 67%, and the description adds genuine meaning for the most complex parameter: display transforms can be supplied directly or copied from a preset file, clarifying that 'preset' and 'display' are two routes to the same data, which the schema does not state. It says nothing about 'name' (required), 'namespace', or texture dimensions, leaving those to the schema's own 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 gives a concrete verb and resource: it opens a new tab containing an empty Java block/item model, with a weapon as an example. It is clear this is a creation/scaffolding tool, but it never distinguishes itself from the sibling tool 'open_java_model', which an agent could reasonably confuse it with.

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: it is for starting a new item model from scratch rather than opening an existing one. 'Cubes need no bones' hints at a workflow constraint (item models skip the bone stage that other model types require), but there is no explicit when-to-use/when-not-to-use statement or a named alternative for loading existing models.

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=false and destructiveHint=false, so the description's job is to add side-effect detail, which it does: a new tab is opened, the fallback to a Bedrock entity model occurs when the GeckoLib plugin is absent, and the reply carries a warning. It stops short of saying what happens on a duplicate name or whether an opened tab can be closed via close_tab.

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 tightly packed sentences: the deliverable comes first, then fallback behavior, then coordinate conventions. Only the parenthetical clause slightly interrupts reading flow; nothing is redundant.

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 creation tool with no output schema, the description covers the produced artifact, the degenerate fallback path, and the geometry conventions an agent needs before adding bones or cubes. Remaining gaps are collision handling and the fact that the new tab must later be closed, both minor.

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%, so name, modid, texture_width, and texture_height are already documented including defaults. The description adds no parameter-level meaning (the unit/orientation notes are about the model, not the inputs), which is the expected baseline when the schema carries the load.

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?

Names a specific verb and resource: opening a new tab containing an empty GeckoLib animated entity model. The GeckoLib-vs-Bedrock distinction and the 'empty/new' framing separate it from open_model and open_java_model in the sibling list without the agent needing to open a 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 implies creation of a fresh model and notes the plugin-missing fallback, which tells the agent what will actually be produced. However, it never says explicitly when to choose this over open_model, open_java_model, or new_java_item, leaving the create-vs-open routing 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses non-obvious behavior: blank rendering when the texture cannot be resolved, no parent-model traversal, and tab reuse for already-open files. It does not say what happens on malformed or element-less input, which is the main remaining 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?

Four short sentences, front-loaded with what is opened and how textures resolve. The nested quoting around "elements" and "texture" is slightly awkward to parse, but no sentence 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?

For a five-parameter tab-opening tool with no output schema and adequate annotations, the description covers texture resolution, parent-model limits, and tab behavior. Missing only error handling for files without "elements", which the description itself flags as a requirement but does not explain the failure mode for.

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

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

The description gives real added meaning for the texture parameter by spelling out the resolution order (explicit "texture", same-named PNG, then assets/textures/...), and the tab-switching sentence implies the intent behind reopen/reload. But reload and reopen are never described, and with 100% schema description coverage the schema already carries most 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 names a specific verb and resource: opening a Java block/item model .json (one containing "elements") into a new tab. The 'Java block/item' qualifier implicitly separates it from the sibling open_model, but it never names that sibling or states the distinction explicitly, so differentiation is left partly to 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?

There is an implicit precondition (the file must contain "elements") and a stated limit (parent models are not followed), plus a note that an already-open file switches to its existing tab. However, there is no explicit 'use this instead of open_model when...' guidance and no statement of when not to use it.

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

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

Annotations only declare non-read-only, non-destructive, non-idempotent, closed-world; the description adds real behavior: a new tab is created, format conversion happens when the GeckoLib plugin is installed, and an already-open file switches to its tab instead of duplicating. It does not cover failure modes for missing/invalid files, which is the main remaining 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, front-loaded with the verb and resource, then the optional sidecars, then the dedup behavior. No redundant restatement of the title 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?

For a simple open-file tool with full schema coverage and no output schema, the description covers format handling, sidecar attachments, conversion, and tab reuse. Only edge-case behavior (missing file, invalid JSON) is unstated, a minor gap at this complexity.

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

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

Schema description coverage is 100%, so all five parameters (paths, reload, reopen) are already documented in structured form. The description adds only loose correspondence ('optionally with its .animation.json and texture PNG') and no new semantics for reload/reopen or path prefixes, so 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 ('Opens') and a precise resource (an existing Bedrock/GeckoLib .geo.json), plus the result (a new tab). The qualifier 'Bedrock/GeckoLib .geo.json' implicitly separates it from the sibling open_java_model, so an agent can pick correctly without opening schemas.

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?

Clear context for use: open an existing model file, optionally attaching its .animation.json and texture PNG, with tab-dedup behavior described. It stops short of explicitly excluding alternatives (e.g., open_java_model for Java-format models, new_project for fresh projects), leaving that routing to inference from the file format.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the three failure conditions it validates and the return payload (plugin version), 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?

Two short sentences, front-loaded with the purpose and immediately followed by the concrete checks and return value. 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 zero-parameter, read-only diagnostic tool with annotations covering safety, the description supplies everything an agent needs: what is verified, the failure modes implied, and what comes back. No output schema exists, and the return value is described in prose 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?

There are zero parameters, so the baseline is 4; the description correctly implies a no-argument call. It adds no parameter meaning because none is 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 names a specific verb+resource (checks the bridge) and enumerates the exact three preconditions it validates: Blockbench is open, the Stonecut Bridge plugin is listening, and the token is correct. It also states the return value (plugin version), which distinguishes it clearly from siblings like status or screenshot.

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

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

Usage is implied by the name and the checklist of preconditions, but the description never says explicitly when to call this versus the sibling 'status' tool, which is the obvious alternative for checking connection state. No when-not guidance is 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?

Adds real behavior beyond the annotations: images are returned as well as written to disk, the camera frames the model and is restored afterwards, and animation + time yields a posed frame. The destructiveHint=true implication of overwriting existing files is only covered by the schema's overwrite parameter, not called out in prose.

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 is rendered and returned, then tacks on the camera-restoration and orientation facts in short sentences. 'Screenshot often and check every side' is slightly advisory filler but does earn a place as workflow 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 an 11-parameter tool with no output schema, the description covers the core loop: render from views or angles, get images back plus files on disk, optionally pose via animation/time. Minor gaps remain, such as how path behaves with multiple views and the file-overwrite risk, but nothing essential to calling 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 coverage is 91%, so the schema already documents nearly every parameter, giving a baseline of 3. The description does add orientation semantics ('right' is the model's right side when facing north) and the yaw/pitch fallback relationship, but leaves width/height/distance/overwrite entirely to the schema, so the added value is modest.

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: renders the 3D preview from named views or yaw/pitch and returns images, writing PNGs to the output folder. That is clearly distinct from model-editing siblings, though it never explicitly contrasts itself with display_screenshot, which an agent could easily confuse it with.

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?

Offers implied usage guidance ('Screenshot often and check every side') and a conditional hint (give animation + time to see a pose). It never says when not to use it, which view to prefer, or how it relates to display_screenshot, so the routing guidance is only implicit.

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, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description's contribution beyond that is the inventory of returned state, which tells the agent this is a pure inspection call with no side effects implied. It adds no further behavioral context such as freshness of the reported state or cost of the call.

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 dense enumeration sentence plus a three-word directive, with no filler. The main structural weakness is that the most important instruction, 'Call this first', is buried at the end rather than front-loaded where it would drive tool selection immediately.

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?

There is no output schema, so the description carries the burden of explaining return values, and it does so item by item across plugin state, folders, project contents and open tabs. For a zero-param inspection tool this is close to complete, missing only detail about how the tab edit counts or folder lists are formatted.

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. The schema is an empty object with full coverage, consistent with the description's no-argument framing.

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 enumerates exactly what the tool surfaces: GeckoLib plugin presence, allowed output/asset folders, the open project's format, bones, cubes, textures and animations (plus display transforms for Java models), and every open tab with its edit count. That is specific enough to distinguish it from siblings like ping or open_model. It lacks an explicit verb up front ('reports'/'returns'), so the purpose is inferred from the content list rather than stated.

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?

'Call this first' gives a clear, actionable ordering directive that an agent can follow without inference. It does not name alternatives or say when not to call it, but for a zero-parameter state-inspection tool there is little ambiguity about alternatives.

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 flag destructiveHint=true and idempotentHint=true, but the description adds real behavioral context beyond them: resizing anchors old pixels at the top-left, and UV size is a side effect unless set_uv_size is false. It stops short of explaining overwrite semantics for an existing texture name, which is what makes the destructive hint material.

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 front-loaded sentences with no filler; the create/resize duality comes first and the UV side effect second, with the pixel-anchoring detail earning its clause.

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 six-optional-parameter mutation tool with no output schema, the description covers the main modes and side effects but leaves open whether an existing texture with the same name is replaced, what a caller gets back, and which parameters are required to create versus resize.

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%, so the schema already documents fill, name, width/height, keep_pixels and set_uv_size. The description only restates the set_uv_size toggle and the top-left anchoring, adding little parameter-level meaning 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?

States a specific verb and resource ('Creates the project texture, or resizes it') and includes the secondary effect on project UV size. This clearly separates it from texture_import (bring in external image) and texture_set_pixels/fill_rect (modify existing pixels), 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?

The two modes (create vs resize) are described, implying when each applies, but there is no explicit guidance on when to prefer this over texture_import or over setting pixels directly, and no mention of prerequisites such as whether the texture must already exist for the resize path.

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, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description usefully adds the unmapped-character skip rule and the scale semantics, but it never says what the destructive write overwrites (existing pixels? a target texture?) or where the drawing is anchored.

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 concept followed by a concrete example, then two dense rules. No filler; 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?

For a destructive drawing tool with five parameters, nested palette object, and no output schema, the description omits the coordinate parameters, the drawing target, and any overwrite behavior. An agent still cannot reliably construct a call from this text plus the bare 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 carry the parameter burden. It illustrates rows and palette by example and clarifies scale indirectly, but x and y are never mentioned at all — no origin, defaults, or coordinate meaning — leaving two of five parameters undocumented in both schema and prose.

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 (draws) and resource (a small picture from rows of characters) with a worked example, so the mechanism is unmistakable. It doesn't name or contrast with the obvious siblings (texture_set_pixels, texture_fill_rect), so an agent must infer which texture tool to pick from the name alone.

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

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

There is no when-to-use guidance: nothing says when to prefer this over texture_set_pixels or texture_fill_rect, and nothing says what must exist first (an open project/model or a selected texture target). The reader is left to guess the preconditions entirely.

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 declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered without the description. The description adds little beyond that — it does not say that existing pixels in the region are overwritten, what happens at bounds, or how the 'clear' path differs from color=null, which the schema already documents.

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 short sentence with the operation front-loaded and no filler. The parenthetical clarification about clearing is useful and compact; the definition is terse rather than bloated, with its deficiency being under-specification scored elsewhere.

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

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

This is a five-parameter destructive write with no output schema and no annotations beyond hints, and the description omits the facts an agent needs: that the fill overwrites existing pixel data, how out-of-range rectangles are handled, and whether the rectangle is clipped to the texture. For a mutating tool at this complexity, that is a substantial 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?

Schema coverage is only 20% — only color carries a description — so the description must compensate for x, y, w and h. It says only that a "rectangle" is filled, leaving coordinate origin, units, whether w/h are inclusive or exclusive, and clipping behavior at the 0–4096 bounds entirely unexplained.

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 ("fills a rectangle of the texture") and adds the variant behavior of clearing. It is clearly distinguishable from texture_set_pixels and texture_draw by its rectangular region scope, though it never names those siblings to make the distinction 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 choose this over texture_set_pixels or texture_draw, nor any prerequisites or exclusions. The agent must infer that this is the bulk-fill option from the phrase "rectangle" 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?

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=true, but the description never mentions that loading a texture replaces the project's existing texture or what happens on failure. The only added information, the source folders, is already covered by the path parameter's schema. For a flagged-destructive tool this leaves the key consequence undisclosed.

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

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

A single well-formed sentence with no filler, and the key resource is front-loaded. It is efficiently written, though its brevity is part of the transparency problem rather than a virtue in 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?

With only two parameters and full schema coverage, the structural side is fine, but the description omits the destructive consequence flagged in the annotations, does not state whether the previous texture is discarded or restored, and gives no indication of what the call returns or how it errors on a missing or non-PNG file.

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%, with path format and set_uv_size semantics fully documented in the schema, so the baseline is 3. The description only loosely restates the folder aspect of path and says nothing about set_uv_size (e.g. whether direct-pixel tools then operate at the new UV size).

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: it loads a PNG and makes it the project texture, and it names the two permitted source folders (output or assets). That is clear enough to know what the tool does, but it does not distinguish it from siblings such as texture_create or texture_set_pixels, which also produce texture content.

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 use this tool versus texture_create, texture_set_pixels, texture_draw or texture_fill_rect, nor any preconditions beyond the implicit source-folder constraint. The agent must infer the selection criteria purely from the sibling names.

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, idempotentHint=true, readOnlyHint=false, and openWorldHint=false, so safety framing is covered structurally. The description adds nothing beyond them: it does not say whether writes replace or blend existing pixel values, what coordinate origin applies, or whether the operation is atomic across the batch.

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 short sentence, front-loaded with the verb and resource, with the parameter hint attached. Nothing is redundant, though the terseness leaves room that could have been spent on the coordinate and colour 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?

This is a destructive mutation with no output schema and no annotation-independent explanation of effects, yet the description says nothing about what is overwritten, what the coordinate space is, or whether invalid coordinates error or clip. For a pixel-write tool operating on a bounded texture, those omissions matter.

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 carry weight — and labeling the tuple as [x, y, colour] genuinely helps, since the array items are unnamed and positional in the schema. However it omits the 0–4095 coordinate bounds, the 65536-pixel batch limit, and the partial transparency semantics implied by the colour field.

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

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

The description names a specific verb and resource ("Sets single pixels") and describes the payload shape, which implicitly distinguishes it from rectangle/drawing siblings like texture_fill_rect or texture_draw. It stops short of naming an alternative explicitly, so an agent must infer the boundary from the word "single".

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

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

There is no when-to-use or when-not-to-use guidance. Faced with texture_draw, texture_fill_rect, and texture_create in the sibling list, an agent gets no signal about which to pick for a per-pixel write versus a bulk fill or a draw primitive.

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