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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the agent knows this mutates state without being destructive. The description adds the useful framing that these helpers are temporary visual aids and not part of production code, which reinforces the non-destructive nature. It does not disclose how helpers persist, when they are cleared, or that calling again stacks new helpers (relevant given idempotentHint=false).

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 debug-visual tag and the core action, then the helper catalogue. It is efficient with no filler, though the type list partially duplicates the schema enum and could be trimmed.

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 9 well-documented optional parameters, full schema coverage, safety annotations, and no output schema expected, the description supplies what is needed to call it correctly. The main missing piece is how created helpers are managed or removed (the remove_helper sibling), but overall the definition is sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters including defaults and the type enum. The description enumerates the helper types (box, axes, skeleton, arrow, grid, camera frustum, light helpers, plane) but this largely restates the enum rather than adding new syntax or format meaning. Baseline 3 is appropriate when the schema carries the parameter burden.

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

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

Specific verb plus resource ("Add a debug helper") and it enumerates the helper kinds, so an agent immediately knows what it creates. The "[DEBUG VISUAL]" prefix and "Nothing to put in code" note cleanly scope it as a dev-only visual tool. It does not name its natural counterpart remove_helper, so sibling differentiation is present but not explicit.

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

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

"[DEBUG VISUAL] Temporary visual aid in the browser. Nothing to put in code." gives implied context that this is for debug inspection only, which is useful guidance. However there is no explicit when-to-use, when-not-to-use, or pointer to remove_helper for cleanup, leaving the practical usage workflow 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is fully covered structurally. The description's 'Read-only' is redundant with that, but it adds useful content scope by naming what it surfaces (actions, clips, weights, playback state). No auth, rate, or pagination context is given.

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 lines with the category tag and safety flag front-loaded, followed by the resource scope. No filler sentences; every clause earns its place.

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

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

For a parameterless, read-only inspection tool with annotations covering the safety profile, the description gives enough: what is read and what fields come back. There is no output schema, but the enumerated fields largely substitute for one.

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?

Zero parameters, so the schema carries no semantics and the baseline is 4. There is nothing for the description to disambiguate or misstate.

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 resource and enumerates its content: AnimationMixers with actions, clips, weights, and playback state. The [INSPECT] tag and 'Read-only' imply the verb. It does not name the mutation sibling (set_animation), so sibling differentiation is only indirect.

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 [INSPECT] prefix and 'Read-only' imply this is the read path for animation state, but there is no explicit when-to-use, when-not, or named alternative. The agent must infer it is the inspection counterpart to set_animation.

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 still earns credit for disclosing what the returned artifact actually contains (an image with [M]/[L]/[G]/[C] markers overlaid at object screen positions), which is real output-content information not present in any structured field. It stops short of stating the return format (image vs. path/URL) or any size limits.

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 lines, front-loaded with the [INSPECT] Read-only tag followed immediately by the tool's distinguishing behavior. Every clause earns its place; the only redundancy is restating read-only, already covered by annotations, which is negligible.

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-required-parameter read-only screenshot tool with full schema coverage and rich annotations, the description supplies the missing piece — what the image contains. Without an output schema it could go one step further and state the return format (inline image vs. file path), which is the only remaining 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 description coverage is 100% with both width and height documented as pixel dimensions defaulting to canvas size, so the schema carries the full burden. The description adds nothing about the two parameters, which is the correct baseline when the schema is complete.

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 (screenshot with object names drawn at screen positions) and goes further by decoding the annotation glyphs ([M]esh, [L]ight, [G]roup, [C]amera), which no sibling schema reveals. That labeling scheme plus the [INSPECT] tag lets an agent distinguish it from take_screenshot and capture_frames without opening either 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?

'Best for understanding layout' implies a use case and a contrast with plain screenshots, but no alternative tool is named and no when-not condition is given. The routing signal is inferable rather than explicit, so this is minimum-viable 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 'Read-only' largely restates structured data. The one genuine addition is the batching behavior ('lists all if no name/uuid'), which discloses a useful side effect of omitting parameters. No return-format or pagination detail, so with annotations covering safety this lands at the midpoint.

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, front-loaded with the [INSPECT] category tag and the read-only marker. No filler or redundancy; every clause contributes.

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

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

No output schema exists, but the description compensates by naming the returned fields (geometry counts, draw ranges, instance visibility). Combined with the optional-filter behavior, an agent has enough to invoke and interpret the tool, though it doesn't explain the return shape's structure.

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 (name, uuid) are self-documented, so the schema already carries the load. The description adds that these act as optional filters whose absence returns everything, marginally deepening the semantics, but nothing about identifier format or precedence between name and uuid.

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 pair (inspect BatchedMesh) and enumerates what the read returns: geometry counts, draw ranges, instance visibility. This clearly distinguishes it from the adjacent instanced_mesh_details and geometry_details siblings. An agent can tell what it does 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?

Implied usage only: 'Lists all if no name/uuid' tells the agent how to broaden the query, but there is no explicit when-to-use guidance and no routing against alternatives such as instanced_mesh_details or geometry_details. Adequate but leaves sibling selection 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?

Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the mutation/non-destructive profile is already covered. The description adds real value with "Temporary visual aid" and "Nothing to put in code," telling the agent the boxes are ephemeral and not source artifacts, but it does not say how they are cleared or how long they persist.

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 bracketed [DEBUG VISUAL] tag and immediately followed by the caveat and the action. Efficient and easy to scan, though the tag-plus-caveat occupies half the text for framing rather than capability.

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 8-parameter, all-optional debug overlay with full schema coverage and no output schema, the description conveys enough to call it correctly: it is temporary, not code, and toggles bounding-box visuals. The only minor gap is not clarifying the clear/enabled interaction, which the schema already handles.

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 eight parameters (name, uuid, clear, color, limit, enabled, recursive, onlyVisible) are already documented in the schema, including defaults. The description contributes no additional parameter meaning, 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?

The description states a specific verb+resource ("Show/hide bounding boxes") and adds a concrete purpose ("debug frustum culling and object bounds"), which separates it from siblings like toggle_wireframe or highlight_object. However, it never names those siblings explicitly, so differentiation relies on the reader inferring scope.

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

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

It gives an implied usage context ("debug frustum culling and object bounds") and frames itself as a debug aid, which hints when to reach for it. There is no explicit when-not, no prerequisites, and no alternative tool named among the many overlay/highlight siblings.

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

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

Annotations declare readOnlyHint=false and idempotentHint=true, consistent with a configuration tool, but the description adds nothing beyond the verb: it does not say what gets changed, whether a connection must already exist, or what the call returns. With zero parameters and no output schema, the behavioral picture stays murky.

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?

It is short, but it reads as two disconnected fragments: a bracketed tag plus a sentence, then a noun phrase with no verb. The purpose statement is not front-loaded coherently, so brevity here reflects under-specification rather than economy.

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 configuration tool with no parameters and no output schema, the description is the only channel for telling the agent what the tool does, what state it affects, and what comes back. It supplies none of that, so an agent cannot confidently invoke it.

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

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

The schema has 0 parameters, so per the rubric the baseline is 4. The description does not need to document parameters, and it does not pretend to.

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 name bridge_status implies a read of connection state, but the description says "Configures the devtools server," which is the opposite verb. The trailing fragment names topics (bridge connection, proxy target, Playwright attach) rather than stating what the tool actually does or returns.

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

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

No when-to-use, prerequisites, or alternatives are given, despite siblings such as set_dev_port and set_dev_url that plausibly overlap with 'configures the devtools server.' The agent is left to guess how this differs from those tools.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description adds real value by naming the returned fields, which matters because no output schema exists.

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

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

Two short lines with the mode tag first and the resource and its fields second; nothing is padded or repeated. Every token 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 zero-param read tool with no output schema, disclosing the returned fields is the key completeness move and it is done. It stops short of noting edge cases such as no active camera or multi-camera scenes, but it is adequate.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The listed field names describe the payload rather than any input, which is appropriate here.

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 clear inspect verb on a specific resource (the active camera) and enumerates the fields surfaced (type, position, FOV, near/far, aspect). The '[INSPECT] Read-only' framing implicitly separates it from the write-side sibling set_camera, but it never names that sibling.

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 '[INSPECT] Read-only' tag implies a passive inspection use case, which is the minimum viable guidance. It never says when to reach for this versus raycast, click_inspect, or set_camera, nor whether it requires an active camera to exist.

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 cover the safety profile (readOnlyHint, destructiveHint=false), so the bar is lower; the description adds real value beyond them by disclosing output location (screenshots/sequence-<time>/), the return value (an ffmpeg command), and the virtualised-time guarantee. It does not address disk-write side effects, which slightly tempers the score.

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 the [INSPECT] Read-only tag, then delivers purpose, behavioral guarantee, output location, and return value in three tight sentences 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?

With no output schema, the description carries the return-value burden and does so by naming the saved images and the ffmpeg command. Combined with destination and timing behavior, an agent has enough to invoke it correctly, though file naming/counting specifics are left implicit.

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 fps, width, height, format, and duration are all documented in the schema, including the png/jpeg distinction. The description adds no parameter-level meaning beyond that, so 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 and resource ("Record a frame sequence for a video") and tags the tool as [INSPECT] Read-only, making its inspection role clear. It distinguishes itself from single-frame siblings like take_screenshot by emphasizing a frame sequence, but never names an alternative 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?

Usage is implied rather than stated: the agent can infer this is for capturing video frames rather than a still, and the note about virtualised time hints at when smooth, deterministic output matters. There is no explicit when-to-use/when-not or named alternative such as take_screenshot.

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, but the description adds non-trivial context the annotations cannot: this tool blocks on real user interaction, changes the cursor to a crosshair, and therefore requires the agent to prompt the user. That is material behavioral knowledge for an agent orchestrating 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?

Two short sentences, front-loaded with the [INSPECT] Read-only tag and the core behavior. Zero filler; every clause carries an instruction or a 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?

With no output schema, the description does state the return ('Returns that object'), the interaction model, and the safety tag, and the timeout semantics live in the schema. It stops short of saying what happens if no click arrives before the timeout, which is the one remaining gap for an interactive, blocking 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?

Single optional 'timeout' parameter with 100% schema description coverage (default 15s, max 60s), so the schema fully carries parameter meaning. The description adds nothing about the timeout or what a timeout yields, which is the correct baseline when the schema does the work.

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 ('Click-to-inspect ... Returns that object') and makes the interactive mechanism explicit via the cursor-to-crosshair detail, which sets it apart from programmatic pickers like raycast. It does not name that sibling directly, so the differentiation is implied rather than spelled out.

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?

'Tell the user to click an object in the 3D view' gives an operational procedure but no when-to-use framing against alternatives such as raycast or object_details, and no conditions under which this is the wrong tool. Usage is implied by the click flow rather than stated as 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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description's 'Read-only' merely restates that, though the scope line (renderer global, per-material, ClippingGroup objects) adds modest context about what categories of clipping data are covered.

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 terse lines with the inspection tag front-loaded and no filler. It is appropriately sized, though extremely minimal rather than richly informative.

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 inspection tool whose annotations already carry the behavioral profile, the description says enough to call it correctly and hints at the returned scope. No output schema exists, so return-shape detail 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?

There are zero parameters, so per the rubric the baseline is 4. The schema is empty and there is nothing for the description to disambiguate.

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 '[INSPECT] Read-only' tag plus 'Clipping planes' names a resource and an implied read action, distinguishing it from the sibling set_clipping. It falls short of a clean verb+resource phrasing, but an agent can tell what it retrieves.

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 [INSPECT]/Read-only framing implies this is for inspecting rather than modifying, which contrasts implicitly with set_clipping. However, no explicit when-to-use, prerequisite, or named alternative is given, so usage must be inferred.

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 that output is recent and level-scoped, but says nothing about buffer bounds, ordering, or the fact that the schema exposes a 'clear' flag that mutates the buffer despite the read-only framing — a notable omission for a tool with a state-changing parameter.

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 fragments, zero filler, with the category tag and read-only marker front-loaded. It is tight, though the extreme brevity comes at the cost of omitting useful behavioral detail rather than being a model of efficient completeness.

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 no output schema, the description carries the return-value burden and does so minimally (recent console messages at log/warn/error). It leaves the buffer-clearing behavior, default limit, and ordering unspecified, which is thin for a tool whose schema contains a mutating flag.

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%: 'clear' and 'limit' are documented in the schema, while 'level' is an enum whose values are self-explanatory. The description adds no format, default, or filtering semantics beyond what the schema already provides, 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?

The description names a specific resource (recent browser console output) and constrains it to log/warn/error levels, so the agent knows exactly what is returned. The '[INSPECT]' tag groups it with sibling inspection tools, though it does not explicitly contrast with web_audit or run_js, which are the nearest functional neighbors.

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 reach for this tool versus alternatives such as web_audit, performance_snapshot, or run_js. The read-only tag implies a safe inspection context, but that is inferred, not 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 the full safety profile (readOnly, idempotent, non-destructive), and the description's 'Read-only' line merely repeats that. It does add genuine value by defining what is inspected — resources tracked but absent from the scene — but says nothing about the shape of the result or comparison basis, which is left uncovered since 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?

Two short lines, tagged [INSPECT] and front-loaded with the read-only nature before the substantive purpose. No filler; every phrase 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 parameterless, read-only inspection tool with no output schema, the description covers what the tool does and its scope adequately. The remaining gap — what the returned leak list looks like — is minor given the absence of an output schema.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. Nothing in the description is needed to disambiguate inputs, and nothing is misleading.

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 function: detecting geometries/textures that are tracked by the renderer but no longer in the scene — a concretely defined leak-detection check, not a tautology of the name. It does not, however, name or distinguish itself from near-neighbor diagnostics like memory_stats or renderer_info, so an agent must infer the boundary.

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

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

The description implies when to reach for it (to find orphaned renderer resources / memory leaks) but gives no explicit when-to-use, when-not-to, or sibling alternative guidance. Against a large diagnostics sibling set, the usage boundary 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds useful output behavior: results are sorted by cost, multi-material objects are flagged, and hidden geometry is surfaced. It does not describe granularity or thresholds, so this is solid but not rich.

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

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

Two compact sentences plus a category tag, front-loaded with the read-only marker and the core metric. Every clause carries information; nothing is padded.

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

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

For a zero-parameter read-only tool with no output schema, the description sufficiently covers what is measured, how results are ordered, and what anomalies are surfaced. Minor gaps remain around scope (whole scene vs selection) and result granularity.

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?

Zero parameters, so there is no parameter semantics burden; baseline 4 applies. The description correctly implies a whole-scene, unfiltered sweep.

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 resource and measurement: per-object draw call and triangle cost, with a clear analytical verb implied by 'breakdown'. It does not name a sibling to differentiate from, so an agent must infer its place against performance_snapshot or geometry_details.

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 '[INSPECT] Read-only' tag implies diagnostic/observation usage and the cost-sorting hints at performance triage, but there is no explicit when-to-use or when-to-prefer-an-alternative guidance versus performance_snapshot or perf_monitor.

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 safety is covered; repeating 'Read-only' adds little. The valuable addition is scoping what data is exposed (scene.environment, scene.background, per-material envMap), though no return shape, cost, or auth context is given.

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?

Extremely short and front-loaded: a bracketed tag, a read-only marker, and a compact list of what is inspected. No filler, though the telegraphic phrasing reads more like a label than a sentence.

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

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

With no output schema and zero parameters, the description carries the burden of saying what comes back, and it does name the three inspection targets. A little more on scope (whole scene vs. selected material) would make it fully self-sufficient.

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

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

The tool takes zero parameters, so there is nothing to document beyond the schema; baseline 4 applies. The description correctly implies a no-argument global inspection rather than suggesting missing filters.

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 clear inspect action on a specific resource: environment maps, naming scene.environment, scene.background and per-material envMap. It does not, however, differentiate itself from overlapping siblings like scene_background or material_details, so an agent cannot fully disambiguate 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?

The '[INSPECT] Read-only' tag implies a read/inspection context, but there is no explicit when-to-use guidance and no mention of how it relates to siblings such as scene_background or material_details. An agent is left to infer the appropriate scenario.

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 non-destructive behavior, so the description's 'Read-only' line is largely redundant. It adds no new behavioral context such as result shaping, pagination/limit behavior, or how filters combine. No contradiction with annotations.

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

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

Two compact lines with the category and safety tag front-loaded before the functional sentence. Slight redundancy between the '[INSPECT]' tag and 'Read-only', but no wasted prose.

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

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

For a 9-parameter, all-optional filter tool with no output schema, the description is adequate on capabilities but silent on how multiple filters compose (AND/OR), result ordering, and what a match looks like. An agent can call it, but edge behavior is left to guesswork.

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 all 9 parameters documented, so the schema carries the burden and baseline is 3. The description names a subset of the filter dimensions but adds no syntax, defaults, or combination semantics beyond what the schema already states.

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 (Search) and resource (objects) plus the filter facets it supports (type, material, visibility, name pattern, custom property). This distinguishes it from singular inspection siblings like object_details, though it never names an alternative 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 '[INSPECT] Read-only' tag implies a discovery/read context, and the filter list implies when the tool is useful, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., scene_tree, object_details). Usage is inferable rather than 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 readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description's 'Read-only' merely restates the annotation; its added value is limited to naming the fog fields returned, which is modest behavioral context.

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

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

Two compact sentences, front-loaded with the INSPECT tag and read-only status before the payload description. No wasted words.

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 return-value burden and does so by enumerating the fog fields. With zero parameters and annotations covering safety, this is nearly complete; only a routing hint to set_fog is missing.

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

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

The tool takes zero parameters, so the baseline is 4. The description instead characterizes the returned fog model (Fog vs FogExp2, and near/far for linear vs density for exponential), which is useful but not strictly 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?

States a specific verb ('Read') and resource ('Scene fog') and enumerates the returned fields (type, color, near/far or density), so an agent knows exactly what it gets. It doesn't explicitly name set_fog as the write counterpart, but the INSPECT/read-only framing plus the naming convention makes the read/write split clear.

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 '[INSPECT] Read-only' tag implies this is a query tool to use when inspecting current fog state, but there is no explicit when-to-use statement or pointer to set_fog as the mutation alternative. Usage 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the description's 'Read-only' line is pure repetition that earns no credit. The description adds no behavioral detail beyond annotations — e.g. whether morph attributes are only returned when present, or how the payload scales with mesh complexity.

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, front-loaded sentences with no padding; the '[INSPECT]' tag immediately signals the tool category. The 'Read-only' clause is redundant against the annotations and is the only wasted text.

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 no output schema, the description usefully enumerates the returned geometry fields, which is exactly the burden it should carry. It stops short of explaining mesh resolution when both optional identifiers are omitted, but for a simple read-only inspector the gap is 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% and both parameters (name, uuid) are already documented, so the baseline is 3. The description implies the tool targets a specific mesh but adds nothing about how name vs uuid selection works or what happens when neither optional parameter is supplied.

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 clear read operation on a specific resource ('Geometry of a mesh') and enumerates the payload it covers (vertices, attributes, index, bounding box, morph attributes). This content listing helps distinguish it from generic siblings like object_details, though it never explicitly names the alternatives it differs from.

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 '[INSPECT]' prefix and 'Read-only' hint at a diagnostic context but give no explicit when-to-use guidance. Nothing tells the agent when to pick geometry_details over object_details, bounding_boxes, morph_targets, or instanced_mesh_details, nor are prerequisites 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 the safe read profile (readOnlyHint, idempotentHint, non-destructive), so the bar is lower. The description adds genuinely useful context beyond them: the output is generated source code destined for project files, not runtime scene state, which tells the agent the result is consumed differently from sibling inspect tools.

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

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

Two short sentences with the crucial output-destination constraint front-loaded before the core purpose. No padding, and the gltfjsx reference compresses an entire behavior into two words.

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

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

For a code-generation tool with no output schema, the description covers what is produced and where it goes, which is what an agent needs to route the result correctly. It could say slightly more about the shape of the emitted component (props, exports), but nothing critical 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 100%, with descriptions and defaults for filePath, preload, and typescript already in the schema. The description adds no parameter detail beyond that, 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 ('Convert') and resource ('GLB/glTF file into a React Three Fiber component'), and reinforces it with the recognizable analogue '(like gltfjsx)'. This clearly distinguishes it from every sibling, which are all scene inspection/mutation tools rather than code generators.

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 '[FOR CODE]' tag and the note that output is meant to be written into project source files imply the context in which this tool belongs. However, it never states when to reach for it versus an alternative (e.g. scene_export) or any prerequisite; 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 declare this is a non-destructive, non-idempotent write; the description adds meaningful context beyond them by stating the effect is a 'temporary visual aid' that leaves 'nothing to put in code'. Toggling visibility is consistent with idempotentHint=false, so nothing is contradicted. It stops short of saying whether the highlight persists across frames or must be cleared.

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, front-loaded sentences with a bracketed category tag first and the core action second. No filler and 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 4-optional-parameter, no-output-schema tool, the description plus annotations and a fully documented schema give an agent enough to invoke it correctly. Only minor gaps remain, such as how name and uuid interact and what, if anything, is returned.

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 mode, name, uuid and enabled are already documented in the schema. The description's mention of the wireframe/visibility modes restates the mode enum but adds no format, precedence, or name-vs-uuid guidance, 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 (highlight/toggle) and resource (object) plus the two visual modes it supports, so an agent knows it is a browser-visual pointing tool. It doesn't explicitly name the overlapping siblings (toggle_wireframe, overlay_selected, bounding_boxes), so differentiation is only partial.

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 '[DEBUG VISUAL]' tag and 'Nothing to put in code' imply this is for temporary, non-persistent pointing rather than scene mutation, which is useful context. However, it never says when to prefer this over toggle_wireframe or overlay_selected, nor any prerequisites.

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, destructiveHint=false and openWorldHint=false, so safety is covered; the description adds value by disclosing the returned payload, which matters because there is no output schema. It does not restate annotation content beyond the redundant 'Read-only' label, but it also omits that transforms are sampled rather than exhaustive.

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 terse lines: the category/safety tag is front-loaded and the resource plus returned fields follow with zero filler. Every token 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 4-parameter, zero-required inspection tool with no output schema, the description adequately conveys what is returned and that it is non-mutating. The main gap is not clarifying name-vs-uuid resolution or that the transform list is a bounded sample (default 5, max 20).

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, uuid, startIndex and sampleCount (with default 5, max 20) are fully documented in the schema. The description adds no parameter-level semantics beyond the schema, so 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 resource (InstancedMesh) and enumerates exactly what is read back (count, capacity, sample transforms, instance colors, custom attributes), with the [INSPECT] Read-only tag marking it as a read operation. It does not, however, differentiate itself from closely related siblings like object_details or batched_mesh_details, which also inspect mesh-like resources.

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 by the [INSPECT] Read-only category tag; there is no explicit when-to-use statement, no conditions or prerequisites, and no named alternative (e.g. set_instanced_mesh for mutation, batched_mesh_details for batched meshes). The agent must infer routing from the tag 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so 'Read-only' in the description is largely redundant. What it does add is the shape of the result (camera layer mask plus non-default-layer objects), which is genuine value given there is no output schema, but it says nothing about scope, scene coverage, or limits.

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

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

Two short sentences with the safety tag front-loaded and no filler. It is appropriately sized for a zero-argument inspection tool, though the fragment-style second sentence is terse enough to feel like a note rather than a specification.

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 no output schema and no parameters, the description carries the full burden of explaining what comes back, and it only sketches that. It does not clarify whether the camera mask is reported per-layer, whether objects are grouped or listed flat, or what 'non-default' is measured against, which an agent would want before relying on the output.

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 for a no-parameter tool 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?

The description states a concrete verb+resource pairing: it reads the camera's layer mask and any objects assigned to non-default layers. That is specific enough to distinguish it from pure scene listings, though it never names the adjacent tools (camera_details, set_layers) that an agent might 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?

There is no statement of when to reach for this tool versus camera_details, scene_tree, or set_layers, and no mention of prerequisites. The '[INSPECT]' tag implies a read-only diagnostic context, but the choice between this and its siblings is left entirely 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so 'Read-only' is largely redundant. The description does add useful scope by listing exactly which material facets are returned, but omits any lookup-failure behavior (e.g., what happens if neither name nor uuid matches) or return-shape context.

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

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

Two short sentences, front-loaded with the category tag and safety note followed by the property inventory. Slightly redundant restating read-only alongside the annotation, but no wasted prose.

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 inspection tool with full annotation coverage and full schema coverage, the description supplies the one thing structured fields lack: the breadth of returned material data. Only the no-match/error path is unaddressed, which is a minor gap.

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

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

Schema description coverage is 100% for both parameters, so the schema already documents name and uuid. The description adds no lookup syntax, precedence, or mutual-exclusivity guidance between the two selectors, leaving the baseline 3 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 names a specific verb tag ([INSPECT]) and resource (material properties), and enumerates the concrete payload (colors, PBR params, maps, uniforms, defines, NodeMaterial slots). This clearly separates it from material_list and set_material_property, though it doesn't name those siblings 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 '[INSPECT] Read-only' tag implies a read context but there is no explicit when-to-use, no condition for choosing this over material_list or texture_details, and no prerequisites. The agent must infer routing from the sibling names 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the description's '[INSPECT] Read-only' largely restates structured data. It does add return-field information (type, color, transparency), which is useful since no output schema exists, but provides no behavioral detail like pagination, scene-size limits, or instance scoping.

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 lines with zero waste and the scope statement front-loaded. Nothing redundant or padded.

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

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

With no parameters, no output schema, and safety fully covered by annotations, the description supplies the essential returned fields so an agent knows what it gets back. It stops short of describing list ordering or whether instanced/derived materials are included, but is otherwise complete for a simple enumeration 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?

The tool takes zero parameters, so per the baseline this is a 4. Nothing in the schema needs semantic elaboration, and the description appropriately does not invent parameter guidance.

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 ('All materials in the scene') and clarifies scope with the returned attributes. It implicitly separates itself from material_details (single-material lookup), but never names that sibling or draw the contrast 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 '[INSPECT] Read-only' tag implies a safe inspection context, but there is no explicit guidance on when to call this versus material_details, shader_list, or texture_list. Usage is left to inference from the name.

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 and the description's 'Read-only' adds nothing new. What it does add is the content scope: which memory categories are reported. It stops short of saying whether figures are live or sampled, or what the top-texture ranking is based on, so it is adequate rather than rich.

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

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

Two short fragments, heavily front-loaded with the classification tag and scope of output. The enumeration is terse and functional. Minor waste in the '[INSPECT] Read-only' prefix, which restates what the annotations already declare.

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 inspection tool with no output schema, the description does the necessary work by telling the agent exactly which memory categories come back. The only missing element is how these stats relate to the other perf/geometry tools, which the description does not address.

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 no parameter semantics to convey and the baseline of 4 applies. The schema is an empty object with full coverage, and nothing in the description misleads about inputs.

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 concrete resource — GPU memory — and enumerates its breakdown (geometry buffers, texture VRAM, instance data, top textures by size). That separates it from siblings like geometry_details or texture_details, which drill into a single asset. It is clear, though the sentence is a noun-phrase enumeration rather than an explicit verb+object statement, so it falls just short of the top score.

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 reach for memory_stats versus performance_snapshot, draw_call_breakdown, or perf_monitor, all of which live in the same performance-adjacent cluster. The '[INSPECT]' tag implies a read-only inspection class but nothing states the condition that selects this tool over its neighbours.

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, so the safety profile is fully covered by structured data. The description adds useful context about the payload (target names and current influences) but nothing about pagination, empty-result behavior, or scenes with no morph targets.

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 lines, front-loaded with the inspection tag and the read-only constraint, followed by the resource and payload. Every fragment carries information; 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?

No output schema exists, so the description must convey the return value, and it does so at a high level ('target names and current influences'). For a zero-parameter, read-only inspection tool this is nearly sufficient, though it doesn't describe how the list is scoped or ordered across multiple meshes.

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 (empty schema), so there is nothing for the description to disambiguate. Baseline 4 applies; it correctly does not invent parameter detail where none exists.

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/list) and resource (meshes with morph targets) plus the returned data (target names and current influences). This cleanly distinguishes it from the write-oriented sibling set_morph_target, which is not named explicitly but is clearly implied by the read-only framing.

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 '[INSPECT] Read-only' tag signals the general usage context and implicitly contrasts with the mutation sibling set_morph_target, but it never states when to use this over alternatives or any prerequisite. Usage is implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description merely restates 'Read-only' rather than adding context. It says nothing about what happens if multiple identifiers are supplied, whether a missing object errors or returns empty, or any auth/rate constraints — no value beyond the structured fields.

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 lines with the category tag first and the purpose second — front-loaded and free of padding. The '[INSPECT]' bracket is slightly cryptic on its own but functions as an efficient grouping cue.

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 3-param detail tool with full schema coverage and safety annotations, the essentials are present, but with no output schema the description gives no hint of what detail is returned, and the multi-identifier ambiguity is left unresolved.

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 each of name, path, and uuid is already documented, and the description's 'by name, uuid, or dot path' simply restates them. Baseline 3 applies; the description does not clarify precedence or mutual exclusivity among the three identifiers.

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 resource (one object) and the three ways it can be addressed (name, uuid, dot path), which is enough to distinguish it from the bulk lookup sibling find_objects. It never names an alternative, so the differentiation is implied rather than 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?

The '[INSPECT] Read-only' tag signals the category of use and 'one object' implies single-target lookup, but there is no statement of when to prefer this over find_objects, scene_tree, or geometry_details, and no preconditions are given. Usage must be inferred from the tag.

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, destructiveHint=false and openWorldHint=false, so 'Read-only.' repeats structured data rather than adding to it. The description does add scope value by listing the categories of data returned, but it says nothing about behavior when no object is selected or what happens with multi-selection.

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 [INSPECT]/read-only marker and immediately followed by the scope of returned data. The leading 'Read-only.' is mildly redundant with annotations, but everything else 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?

With zero parameters and rich annotations, the main remaining uncertainty is what is returned and how a missing selection is handled; the description covers the former well and the latter not at all. An output schema is absent, so the inline field enumeration does real work.

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; baseline 4 applies. The field list does helpfully signal what the empty-argument call will return.

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 the resource precisely: the object currently selected in the overlay, and enumerates the data returned (materials, geometry, transforms, textures, uniforms, shadows). The verb is implicit rather than explicit, and it never distinguishes itself from siblings like object_details, click_inspect, or raycast, which read similar object data.

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 by the phrase 'the object the user selected in the overlay' and the [INSPECT] tag; there is no explicit when-to-use, when-not-to-use, or pointer to object_details for the non-overlay case. An agent must infer that this is the selection-scoped variant of object inspection.

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 read-only, idempotent, non-destructive behavior, so the bar is lower. The description still adds real context: the scope of what is tracked ('everything changed with live-preview tools since the last clear') and the fact that clear=true forgets the listed changes, which is a state effect the annotations do not surface.

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 '[FOR CODE]' tag and the output contract before the usage instruction. Every clause (output contents, both code flavours, target locations, clear semantics) carries information; nothing is padded.

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

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

There is no output schema, so the description carries that burden and does it well, enumerating the return payload (per-property diffs, paste-ready code, target pointers). Combined with a two-parameter schema and full annotation coverage, an agent has everything needed to call this 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 100%, so both parameters are already documented. The description reinforces 'clear=true' as a follow-up action after writing code and mentions both code flavours, but adds no format or default detail beyond what the schema enumerates. 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?

The description states a specific resource (the accumulated live-preview changes) and precisely what the output contains: before→after per property, ready-to-paste code in vanilla Three.js and/or R3F, and target locations. The bracketed '[FOR CODE]' tag signals intent well. It does not, however, differentiate itself against the sibling scene_diff, which an agent could reasonably confuse with this.

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 when-to-use ('Use it to persist a preview into source') and a lifecycle instruction ('call again with clear=true once the code is updated'). It stops short of naming alternatives, but the persist-then-clear workflow is stated explicitly rather than 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety and idempotency profile. The description repeats 'Read-only' (redundant) and adds what data is captured, but it does not disclose behavioral traits such as potential performance impact of recording or whether it blocks execution.

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

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

The description is two sentences, front-loaded with a tag and read-only note, then the core action and output metrics. Every phrase earns its place with no redundancy or filler.

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

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

For a simple read-only tool with two optional parameters and no output schema, the description sufficiently explains what is recorded and what summary metrics are returned. It lacks usage context relative to siblings, but the core information an agent needs to invoke it correctly is present.

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 both parameters (duration, includeFrameTimes) are fully documented in the schema with defaults and max. The description mentions 'for N seconds' and 'frame times' but adds no syntax or format details beyond what the schema already provides, so 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?

The description states a specific verb ('Record') and resource ('FPS and frame times') and lists the metrics captured (avg/min/max, percentiles, spikes, jank). It does not, however, distinguish this tool from siblings like performance_snapshot or draw_call_breakdown, leaving the agent to infer the difference.

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

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

The description gives no explicit when-to-use guidance or alternatives. The '[INSPECT] Read-only' tag implies it is a read operation, but there is no direction on when to choose this over performance_snapshot or other monitoring tools, nor any prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the "Read-only" label largely restates structured data. The added value is modest: it names the captured metrics, but says nothing about sampling behavior, cost, or whether the snapshot is instantaneous vs averaged.

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 lines, correctly front-loaded with the read-only marker before the payload description. No filler sentences.

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

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

For a zero-param inspect tool the description covers what data comes back, which is important since there is no output schema. However, in a dense sibling cluster it omits the differentiation and the granularity/cost of the snapshot, leaving a meaningful 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?

The tool takes zero parameters and schema coverage is 100%, so no parameter explanation is needed. Baseline 4 applies for a correctly no-arg 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 resource (performance snapshot) and enumerates exactly what it reports: draw calls, triangles, instanced meshes, object counts by type. An agent understands the output, but the description never distinguishes it from close siblings like perf_monitor, draw_call_breakdown, or memory_stats.

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 and no reference to alternatives. With siblings perf_monitor, draw_call_breakdown, and memory_stats occupying adjacent territory, the agent is left to guess which performance tool to call.

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 'Read-only' text is largely redundant. The description does add the scope of what is returned (passes, shader passes, effects), which is genuinely beyond the annotations, but says nothing about ordering, return shape, or depth of detail.

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?

Extremely tight at two short lines, with the [INSPECT] tag front-loaded so the agent can classify the tool immediately. The 'Read-only' phrase slightly duplicates the annotation, but it costs almost nothing.

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-param, read-only list tool with no output schema, the description gives enough — what the list contains and that it is safe to call. It does not describe the return structure, but with no output schema and a trivial interface this is a small 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No param-level explanation is needed or missing.

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

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

Names the resource (EffectComposer) and enumerates what it contains — render passes, shader passes, effects such as bloom and SSAO — so the agent knows exactly what is being listed. The [INSPECT] tag and 'Read-only' prefix distinguish it from set_postprocessing, though the sibling is not 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 '[INSPECT] Read-only' marker implies this is for inspection of the post-processing stack, which is useful routing context. However, it does not state when to prefer this over sibling inspectors (e.g. shader_list, material_list) or mention set_postprocessing as the mutation counterpart.

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 '[INSPECT] Read-only' prefix largely restates structured data. The description does add that the ray originates from the camera and that hit objects are returned, but says nothing about hit ordering, depth of returned data, or how maxHits truncates results.

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

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

Two compact lines with the category tag and the core action front-loaded; no filler sentences to trim.

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

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

No output schema exists, so the description carries the burden of explaining the return value. 'Return hit objects' is directionally useful but leaves out what a hit contains (object reference, distance, intersection point, normal), which is central to using a raycast result. Adequate but with a real 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 100%, so x, y, and maxHits are fully documented in the schema itself. The description's 'screen coordinates' phrasing actually diverges slightly from the schema's 'normalized device X/Y (-1 to 1)', adding no clarifying detail. Baseline 3 is appropriate when the schema does the work.

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 mechanism: 'Cast a ray from the camera through screen coordinates and return hit objects.' An agent can tell this is a spatial picking/inspection operation. It does not, however, distinguish itself from siblings like click_inspect, find_objects, or bounding_boxes, which could plausibly be confused with it.

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 alternatives such as click_inspect (which presumably also resolves what is under a point) or object_details. The '[INSPECT]' tag hints at a category but gives no selection criteria or exclusions.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false. The description adds genuinely useful context: this targets a temporary browser-only debug visual that never touches code, which explains why removal is non-destructive. It does not, however, address the non-idempotent behavior (what happens if the helper is already gone) or any error conditions.

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 lines with the operation stated directly and no filler. The bracketed tag and first sentence are slightly redundant framing, but they are brief and front-loaded rather than padded.

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

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

For a single-parameter removal tool with full schema coverage, no output schema, and annotations carrying the safety profile, the description supplies enough to call it correctly and explains the ephemeral nature of the target. The only missing nuance is behavior on repeat invocation, which is minor here.

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 itself documents helperId as "ID returned by add_helper". The description reinforces the add_helper provenance but adds no format or syntax detail beyond the schema, 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?

The second sentence gives a specific verb+resource ("Remove a helper") and ties it to the sibling that creates it (add_helper), so an agent can distinguish it from add_helper. The leading "[DEBUG VISUAL] Temporary visual aid in the browser. Nothing to put in code." describes the artifact class rather than the operation, which slightly muddies an otherwise clear purpose.

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 pairing with add_helper implies the tool is used to undo a previously added debug helper, and "Nothing to put in code" hints these are ephemeral. However, no explicit when/when-not guidance is given and no alternative (e.g. revert_changes) is mentioned, 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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so 'Read-only' is largely a restatement of structured data. The description does add value by naming the returned contents (draw calls, triangles, memory, capabilities) and the backend distinction, but says nothing about cost, rate limits, or snapshot timing beyond 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?

Two compact lines with the key content front-loaded and zero filler sentences. Minor redundancy in restating 'Read-only' where annotations already cover it, which keeps it just short of a 5.

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 no output schema, the description carries the return-value burden and does so adequately by enumerating the data categories and the backend variants. The safety profile is fully covered by annotations, so nothing an agent needs to select or call this tool is missing.

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

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

The tool takes no parameters, so per the rubric this is the baseline. There is nothing for the description to disambiguate, and it correctly avoids inventing 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?

States a specific resource ('Renderer stats and backend') and enumerates what it returns (draw calls, triangles, memory, capabilities), plus the WebGL/WebGPU backend dimension. It is distinguishable from write-oriented siblings like set_renderer, but it does not explicitly differentiate itself from overlapping read tools such as draw_call_breakdown, memory_stats, or performance_snapshot.

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 '[INSPECT] Read-only' tag implies inspection use but gives no explicit when-to-use guidance, no conditions, and no pointer to the many overlapping sibling tools (draw_call_breakdown, memory_stats, performance_snapshot). The agent must infer the selection criteria itself.

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, destructiveHint=false and closed-world behavior, so '[INSPECT] Read-only' is essentially a restatement. What the description does add is the enumeration of the configuration fields exposed, but it says nothing about return shape or freshness beyond 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?

Two compact fragments, with the mode tag front-loaded and the covered fields immediately after. No filler sentences.

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

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

With no parameters, no output schema, and annotations covering the safety profile, the description's field enumeration carries most of the needed information. The only real gap is that an agent cannot tell from the description alone why it would call this instead of renderer_info.

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 to document; the baseline of 4 applies. The field list in the description compensates by describing what the (empty) call yields.

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 resource (renderer configuration) and enumerates the concrete properties covered (toneMapping, exposure, colorSpace, shadowMap, pixelRatio), so an agent knows exactly what it returns. However, it does not differentiate itself from the sibling renderer_info, which appears to cover overlapping ground, leaving ambiguity about which to pick.

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

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

The '[INSPECT] Read-only' tag implies this is for inspection rather than mutation, which implicitly separates it from set_renderer, but the description never states when to use this over renderer_info or names any alternative. Usage is only weakly 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 already declare non-destructive, idempotent, non-readOnly behavior, and the description adds real context: changes are browser-only, not written to source, lost on reload, and tracked in pending_changes. It could go further on what happens to the pending_changes entries after a revert.

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 [LIVE PREVIEW] tag is well front-loaded, but the two sentences overlap: undoability via revert_changes is announced in sentence one and restated as the tool's action in sentence two. Tightening would remove the redundancy 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 no output schema and annotations covering the safety profile, the description supplies the key behavioral facts an agent needs: scope of the undo, id source, default, and ordering. Error behavior for stale or invalid ids is the only notable 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?

Schema coverage is 100% and documents the ids array with a default, so the schema already carries the load. The description still adds value by naming where the ids originate (pending_changes) and confirming the all-or-selected semantics plus newest-first ordering.

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: 'Undo live-preview changes in the browser,' which is distinguishable from siblings like pending_changes (lists changes) and scene_export. The lead sentence about live-preview semantics is slightly circuitous, but the operative purpose is unambiguous.

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

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

It implies the usage context by tying ids to 'pending_changes' and specifying all-vs-selected, and 'newest first' hints at iteration order. However it never states when NOT to use it or an explicit alternative path (e.g., when to promote changes to code instead of reverting).

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 openWorldHint=true, so the safety profile is partly covered. The description adds two things annotations cannot: the injected scope (scene, renderer, camera, gl) and the crucial fact that changes are NOT recorded in pending_changes, meaning revert_changes won't undo them. It stops short of stating permission/sandbox limits or that arbitrary scene mutation is possible.

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 two substantive sentences are dense and front-loaded with the alternative-tool guidance. However, the leading '[DEBUG VISUAL] ... Nothing to put in code.' fragment is unexplained, contradicts the required `code` parameter, and does not earn its place in a short description.

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 no output schema, the description correctly explains how results come back (via `return`), names the injected globals, and flags the non-persistent, un-revertable nature of edits — all the essentials for calling it safely. What's missing is any note on execution constraints or failure behavior for arbitrary code.

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 single parameter's description already lists the injected variables, so the baseline would be 3. The description earns above baseline by documenting the return contract ('return' a value to get it back), which is behavioral meaning the schema does not convey.

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 core sentence states a specific verb+resource: run JavaScript in the page, with the four injected variables, returning a value. It distinguishes itself from the set_* family by scope, but the stray leading fragment '[DEBUG VISUAL] Temporary visual aid in the browser. Nothing to put in code.' directly conflicts with a tool whose only required parameter is `code` and muddies an otherwise clear purpose.

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 one explicit routing rule: prefer the set_* tools for anything the user may want to keep, because run_js edits are not captured in pending_changes. That is a concrete when-to-use/when-not-to-use signal, though it doesn't contrast with read-only siblings like scene_tree or renderer_info that an agent might reach for 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds scope by listing the background, environment map, blurriness/intensity, and color-management aspects, but it does not describe return format or other behavioral details beyond 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?

The description is two short lines with no wasted text. The read-only constraint is front-loaded via the '[INSPECT] Read-only' tag, followed immediately by the covered inspection domains.

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 parameterless, read-only inspection tool, the description lists the relevant scene background and color-management areas an agent would need. With no output schema, it could say more about the return shape, but it is sufficient for an inspector of this scope.

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 are no parameter semantics for the description to explain. The baseline for a parameterless tool is 4, and nothing in the description misleads about inputs.

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 the inspected resource and its covered aspects: scene background, environment map (IBL), backgroundBlurriness/Intensity, and color management. It is clearly a read-only inspector, but it does not explicitly distinguish itself from nearby siblings such as env_map_details or renderer_info.

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

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

The '[INSPECT] Read-only' tag implies this is a read operation, but the description gives no explicit guidance on when to use this tool versus env_map_details, renderer_info, or other inspection tools. It also states no exclusions or prerequisites.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered; the description usefully adds the stateful two-call workflow and what the diff reports. It omits snapshot lifecycle details (persistence, reset/overwrite, what happens if diff is called with no prior snapshot), and the order-dependent behavior sits in mild tension with idempotentHint=true, though the saved snapshot does not mutate the scene itself.

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 lines: the read-only classification is front-loaded and the mechanism follows immediately. Every clause earns its place, 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?

For a one-optional-enum inspection tool with no output schema and full annotation coverage, the description supplies the essential mechanism and output content. Only edge cases (no prior snapshot, snapshot lifetime, detection granularity) are unstated, which is 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 coverage is 100% with a fully documented action enum, so the baseline is 3. The description adds meaning the schema lacks: the cross-call ordering contract (first call snapshots, subsequent call diffs) and the content of the diff output (added/removed/modified objects), which is genuinely additive.

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 specific verb (compare/diff) and resource (scene state over time) and explains the snapshot-then-diff mechanism, which is unmistakable among the siblings. It does not explicitly distinguish itself from look-alikes such as scene_tree or pending_changes, 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?

"first call saves a snapshot, next call lists added/removed/modified objects" gives clear context for how the tool is driven across calls, but it never states when to prefer this over alternatives (scene_tree, pending_changes, object_details) or when it is inappropriate. Usage is implied rather than prescribed.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds real behavioral context beyond them: the output location (screenshots/), the dependency (GLTFExporter must exist in the app), and the fact that failure surfaces an explanatory error. This is meaningful operational context for a tool whose side effect is a written file.

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 classification and read-only marker, followed by the destination and the setup caveat. Nothing is padded and 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 an export tool with annotations covering safety and a fully documented 3-parameter schema, the description covers purpose, destination, and the key prerequisite. It omits what a successful call returns (file path/handle), which matters slightly since there is no output schema, but otherwise it is complete enough 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 100%, so name/uuid/binary are already documented. The description reinforces 'scene or one object' (name/uuid) and 'GLB/glTF' (binary) but adds no syntax or format detail beyond the schema, so 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 and resource ('Export the scene or one object as GLB/glTF') plus the destination folder (screenshots/), which is enough to distinguish it from siblings like take_screenshot or gltf_to_r3f. It doesn't explicitly name an alternative, so it stops short of the top score.

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 format and destination, and the note about needing GLTFExporter acts as a prerequisite. However, there is no explicit when-to-use vs when-not guidance or routing to a sibling tool, so it remains 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 already declare read-only, idempotent, non-destructive behavior, and the description's 'Read-only' restates that with no added value. It does add genuine behavioral context beyond annotations: approximate payload size (~2KB) for the default output and what compact=false returns. It omits truncation behavior for large scenes, which maxChildren hints at.

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 category tag and output mode. The 'Read-only' phrase duplicates the annotations and is the one line that doesn't earn 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?

With no output schema, the description correctly describes the return shape (text tree vs JSON with geometry). It stops short of covering large-scene truncation or routing to sibling inspection tools, which would make it fully self-sufficient for a 4-parameter listing tool.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: compact=false yields full JSON with positions and geometry, not just 'full JSON'. It does not clarify depth or types semantics beyond the schema.

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

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

The description names a specific resource ('Scene hierarchy') and its output form, so an agent knows it lists the scene graph rather than a single object. It does not distinguish itself from close siblings like object_details, find_objects, or scene_diff, so an agent must infer which inspection tool to pick.

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

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

Usage is only implied: the ~2KB compact default and the compact=false escape hatch give a cost/detail tradeoff an agent can act on. There is no explicit when-to-use guidance and no mention of when to prefer find_objects or object_details 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 cover safety (readOnly=false, destructive=false, idempotent=true), and the description adds the critical lifecycle facts annotations cannot convey: changes are live-only, lost on reload, tracked in pending_changes, and undoable via revert_changes. That is exactly the extra behavioral context a mutation tool 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?

Two sentences, zero filler, and the most consequential fact (live preview, not saved) is front-loaded before the parameter summary. 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 9-parameter tool with no output schema, it covers the ephemeral-preview model, the persistence path, and the undo path, which is the essential missing context. Minor gaps remain: no guidance on whether play/stop/pause combine, and mixerIndex/actionTimeScale semantics are left to the schema.

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

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

Schema coverage is only 56%, so the description compensates by splitting the parameters into two semantic groups — mixer-level (timeScale/time) and action-level (play/stop/pause/weight by clip name) — which clarifies intent beyond the raw schema. It still leaves mixerIndex and actionTimeScale unexplained, keeping it below a 5.

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+resource: it controls animation playback via the mixer and actions, with the '[LIVE PREVIEW]' tag scoping it to the running scene. It never names sibling animation_details as the read-only counterpart, so the boundary is implied rather than explicit, but the purpose itself is unambiguous.

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

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

It gives strong context for when the effect applies: browser-only, not persisted to source, recorded in pending_changes and reversible with revert_changes. It stops short of explicitly stating when to reach for this versus animation_details or pending_changes, so it's clear context without named 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 only supply the generic safety profile (not read-only, not destructive, idempotent). The description adds material behavioral context the annotations lack: changes are browser-only, not persisted to source, lost on reload, tracked in pending_changes for later code edits, and reversible via revert_changes.

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 waste, and the highest-stakes fact — [LIVE PREVIEW]/lost on reload — is front-loaded before the field enumeration. Every clause 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?

For an 11-parameter, no-required, no-output-schema mutation tool, the description covers the critical operational semantics (ephemeral preview, pending_changes linkage, undo). It is nearly complete, though it could note defaults or the effect of omitting parameters since none are required.

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 73%, so most parameters are already documented in the schema (which even tags fov/aspect as PerspectiveCamera and left/right/top/bottom as OrthographicCamera). The description adds only a vague 'ortho bounds' grouping and no syntax or unit details beyond the schema, so it lands at the 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 (Change) and resource (the active camera) and enumerates the affected properties: position, rotation, FOV, near/far, zoom, ortho bounds. This cleanly separates it from read-oriented siblings like camera_details and from the generic set_object_transform.

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 contextualizes usage by flagging that changes are live-preview only, uncommitted to source, and undoable via revert_changes / visible in pending_changes. However it does not explicitly state when to choose this over alternatives, nor any preconditions, so guidance is implied rather than spelled out.

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

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

Annotations already declare non-readOnly, non-destructive, idempotent, but the description adds the crucial behavioral traits they cannot express: changes are preview-only, not persisted to source, lost on reload, tracked in pending_changes, and reversible via revert_changes. This is exactly the kind of non-structured context 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?

Two tight sentences with the critical persistence warning front-loaded via the [LIVE PREVIEW] tag. No filler; each clause 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?

For an 8-param mutation with no output schema and 88% schema coverage, the description covers the essential behavioral context (ephemeral preview, undo path). Return-value explanation is unnecessary without an output schema, so the only minor gap is that it doesn't hint at what pending_changes records.

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 88%, so the schema already documents the 8 parameters thoroughly. The description only maps 'renderer (global) or a material' to the target enum, adding marginal meaning beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 second sentence states a specific verb+resource — 'Change clipping planes on the renderer (global) or a material' — and identifies both target modes. It is clear what the tool does, though it does not explicitly differentiate itself from the read-only sibling clipping_details.

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 [LIVE PREVIEW] framing and the note that changes are browser-only, lost on reload, recorded in pending_changes, and undoable with revert_changes give clear workflow context for when this tool is appropriate. It stops short of explicitly naming clipping_details as the read counterpart, so it's strong context rather than 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 declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, so the safety profile is known. The description adds the context that this reconfigures the proxy, but says nothing about whether the connection drops, whether HMR resets, or what the proxy switch does to running sessions - useful but not rich.

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

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

Two short, front-loaded sentences with a clear [CONNECTION] category tag. Every word earns its place, though the second sentence largely restates the first.

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

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

For a single-parameter connection tool whose annotations cover safety and idempotency and with no output schema, the description is close to sufficient. It falls short of fully explaining the behavioral effect on the existing connection or how it interacts with set_dev_url.

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 single 'port' parameter is already documented with examples (3000, 5173, 8080). The description adds only 'another local dev server port', which restates the schema rather than adding syntax or constraint detail. 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: 'Configures the devtools server' and 'Point the proxy at another local dev server port.' This tells an agent it manipulates the dev-server connection target. It distinguishes reasonably from sibling set_dev_url (port vs. URL) by implication, but never confirms the distinction 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?

Usage is implied by 'Point the proxy at another local dev server port' - the agent can infer it is for redirecting the proxy when the dev server port changes. However, no explicit when-to-use, prerequisites, or alternative (e.g., set_dev_url) is named.

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

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

Annotations already declare openWorldHint=true, idempotentHint=true and readOnlyHint=false, so the agent knows this reconfigures an external connection safely and repeatably. The description adds one genuinely useful behavioral fact not in the annotations: that remote mode forbids source code changes. It still omits what happens to the previous target and whether the connection re-establishes.

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, tag first, purpose second, constraint third, with no filler. Slightly more efficient framing (tagging plus restating 'devtools server') would be tighter, but nothing is wasted.

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

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

For a one-parameter configuration tool with clear annotations and no output schema, the description covers enough to invoke it correctly. It is thin on the connection lifecycle, though, and never cross-references set_dev_port, the sibling an agent would most plausibly confuse it with.

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 single url parameter is documented in the schema with an example, so the description need not restate it. "By URL" adds nothing beyond the schema's "Full URL, e.g. https://my-app.vercel.app", which is the expected baseline when the schema does the heavy lifting.

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 pairs a clear action with a resource: it configures the devtools server connection so a remote Three.js app can be inspected by URL. An agent can tell it is the targeting/setup tool rather than an inspection tool. It does not, however, distinguish itself from the very close sibling set_dev_port, which the agent must infer is a different configuration axis.

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?

"Inspect a remote Three.js app by URL" implies the use case (switching the bridge to a remote target), and the remote-mode caveat hints at a limit. But there is no explicit when-to-use versus set_dev_port or bridge_status, and no statement of prerequisites such as the bridge needing to be running.

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 safety semantics (readOnlyHint=false, idempotent, non-destructive); the description adds the crucial behavioral facts: the change is browser-only, never persisted to source, lost on reload, tracked in pending_changes, and reversible via revert_changes. That is well beyond what the annotations disclose.

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

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

Two sentences with zero filler, and the highest-risk constraint ([LIVE PREVIEW], not saved) is front-loaded before the functional description. Every clause carries non-redundant information.

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

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

For a non-destructive preview mutation with full annotation coverage and a complete parameter schema, the description supplies everything the agent needs: persistence semantics, undo mechanism, and which scene properties are affected. No output schema exists, so no return-value description is required.

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 baseline is 3. The description groups the parameters ('color, near/far or density' and background color), reinforcing the schema but adding no new syntax, constraints, or defaults beyond what is already documented per-property.

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 (Change) plus resource and scope: scene fog (color, near/far or density) and the background color. This distinguishes it from read-only siblings such as fog_details and scene_background, so an agent can route correctly 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?

Explicitly frames when this applies — live preview only, not written to source, lost on reload — and names the follow-up path (pending_changes → code edits) plus the undo path (revert_changes). It gives clear operating context but no explicit 'use X instead when you want persistence' alternative tool.

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

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

With annotations only covering idempotent/readOnly/destructive hints, the description carries the important behavioral context and does so well: changes are LIVE PREVIEW only, NOT saved to source code, lost on reload, recorded in pending_changes (which routes to code edits), and undoable via revert_changes. That persistence and recovery profile is exactly what an agent needs and is nowhere in the annotations or 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 sentences and a bracketed tag, with the highest-stakes fact ([LIVE PREVIEW] — not saved, lost on reload) front-loaded ahead of the mechanical field list. No filler or repetition of schema content.

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

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

No output schema exists, and annotations already cover the safety/idempotency profile, so the description does the heavy lifting on preview persistence and undo, which it covers fully. The remaining gap is identification semantics (name vs uuid, both optional) and return behavior on success/failure.

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 60%, so the schema already documents name, uuid, and count. The description restates three of the five fields (count, visibility, frustumCulled) but adds no syntax, units, or constraint detail, and does not clarify the name-vs-uuid identification ambiguity (0 required params). Baseline 3 for adequate-but-not-additive parameter coverage.

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

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

The second sentence gives a specific verb (Change) and resource (InstancedMesh) plus the exact mutable fields: count, visibility, frustumCulled. This clearly distinguishes it from sibling setters like set_object_transform and from the read-only instanced_mesh_details. It stops short of explicitly naming a sibling it is not, so 4 rather than 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?

The description establishes the operating context (live/browser-only preview, not persisted) and points to reconcile paths: pending_changes and revert_changes. However, it never says when to prefer this over alternatives such as set_object_transform, nor does it state preconditions (e.g. when a live-preview edit is appropriate vs a source edit). Usage is implied rather than specified.

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: it discloses that changes are browser-only, not saved to source, lost on reload, recorded in pending_changes (which becomes code edits), and reversible via revert_changes. That is exactly the persistence, side-effect and undo context an agent needs for a mutation.

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 waste, with the critical live-preview caveat front-loaded in a bracketed tag before the actual operation is stated.

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-param optional-only mutation with no output schema, the description covers the essential behavioral context (persistence, undo, scope). It does not clarify how mask relates to layer+enabled, but the schema descriptions carry that burden.

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 each parameter (mask, name, uuid, layer, target, enabled) is already documented. The description only echoes the 'object or camera' target scope and adds no syntax or interaction detail, 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 and resource ('Set layers on an object or the camera'), which is clearly distinct from the read-only sibling layer_details. It does not explicitly name or route to a sibling, so it stops just 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?

Usage is implied by the [LIVE PREVIEW] framing and the pointer to pending_changes/revert_changes, which tells the agent this is a transient in-browser mutation. However, no explicit when-to-use/when-not guidance or alternative is offered (e.g., when to prefer editing source vs. this preview tool).

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

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

The annotations already declare that this is a non-read-only, idempotent, non-destructive mutation. The description adds crucial context beyond them: changes are browser-only, are not persisted to source code, are lost on reload, appear in pending_changes, and can be undone with revert_changes.

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 first sentence front-loads the critical live-preview and persistence warning, and the second sentence compactly enumerates the adjustable properties. Every sentence earns its place with no redundant restatement.

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, the description covers the essential behavioral traits an agent needs: browser-only scope, persistence loss, pending-change recording, and undoability. The remaining parameter identification is adequately handled by the schema.

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

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

Schema description coverage is 71%, leaving intensity and castShadow without schema descriptions. The description compensates by naming those fields, and it adds useful semantics for groundColor by noting it applies to HemisphereLight.

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 precise verb and resource: it changes a light and lists the specific light properties that can be modified. This distinguishes it from siblings such as set_object_transform, set_material_property, or set_shadow, which target different scene entities.

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

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

It clearly frames the tool as a live-preview-only operation whose effects are not saved and are lost on reload, which implies when to use it. However, it does not explicitly compare this tool with alternatives or state when not to use it.

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

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

Annotations only declare readOnly=false, idempotent=true, destructive=false. The description goes well beyond them by disclosing that the change lives in the browser only, is lost on reload, feeds pending_changes for eventual code edits, and is reversible via revert_changes. That is exactly the behavioral context an agent needs for a mutation tool.

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

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

Two compact sentences. The most consequential information (preview-only, lost on reload, recorded and undoable) is front-loaded before the plain purpose statement, and nothing is padded.

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

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

For a 4-parameter mutation tool with full schema coverage, annotations and no output schema, the description supplies the missing persistence/undo semantics and the name-resolution note. An agent has everything needed to call it correctly and predict its side 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 description coverage is 100% and the value/property semantics (hex strings for colors, booleans for flags, full property enumeration) are already in the schema. The description only restates that name can be a material name or a mesh using it, which the schema also says, so it adds no new parameter meaning.

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 ('Set a material property') and adds scope ('scene in the browser only, not saved to source code'). This distinguishes it well from lookups like material_details and from related writers like set_texture or set_uniform, 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 LIVE PREVIEW framing tells the agent exactly what class of change this is: preview-only, recorded in pending_changes, undoable with revert_changes — effectively routing the agent to those siblings. It does not, however, say when to prefer this over material_details or set_texture/set_uniform directly.

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 the mutation/idempotency profile; the description adds the critical behavioral facts that the change is ephemeral, is not persisted to source, is logged in pending_changes, and has a defined undo path via revert_changes. That is precisely the context an agent needs before calling a live-preview mutation.

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, and the constraint banner is compact. The only structural weakness is that the actual purpose statement trails the banner, so the first thing the agent reads is a caveat rather than what the tool does.

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

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

For a 5-parameter tool with fully described schema and no output schema, the description covers the important non-obvious behavior (ephemerality, undo, pending_changes). It leaves minor gaps such as behavior when the named mesh or morph target cannot be resolved.

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 every parameter (name, uuid, index, influence, targetName) is already documented in the schema. The description adds nothing about parameter interaction (e.g., how the mesh is identified or influence range beyond the schema's "0-1"), so 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?

"Set a morph target influence" is a specific verb+resource that separates it from the read-only sibling morph_targets. However, the purpose sentence is placed after the preview banner, and the description never explicitly names morph_targets as the read counterpart, so sibling differentiation is implicit 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?

The description gives clear operating context: browser-only change, not written to source, lost on reload, recorded in pending_changes, and undoable via revert_changes. It stops short of an explicit when-not rule or a named alternative for permanent edits, but the workflow it belongs to is unambiguous.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=true, and the description adds substantial context beyond them: changes are browser-only, not persisted to source, lost on reload, recorded in pending_changes, and reversible via revert_changes. That is exactly the kind of lifecycle/undo information an agent needs for a mutation tool.

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

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

Two sentences, no filler, with the critical '[LIVE PREVIEW]' warning front-loaded. Each sentence earns its place and the whole definition scans in one pass.

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-param mutation tool with no output schema, the description covers persistence, undo, and pending-change tracking, so the agent can call it correctly. The minor omission is that it never states the object is identified by name or uuid, though that detail lives in the schema.

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

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

Schema description coverage is 100%, so the schema already documents name, uuid, position, rotation (in radians), scale, and visible. The description restates the affected fields but adds no units, format, or identification rules beyond what the schema provides, 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?

The second sentence names a specific verb (Set) and the exact transform properties affected (position, rotation, scale, visibility) on an object, which clearly separates it from sibling setters like set_material_property or set_light. It stops short of naming the sibling tools or their boundary conditions, but the scope is unambiguous.

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

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

The [LIVE PREVIEW] framing plus 'NOT saved to source code, lost on reload' and the pointer to pending_changes (→ code edits) and revert_changes gives the agent clear context on when and how this applies. It does not explicitly contrast itself with an alternative tool, but the workflow and persistence conditions are spelled out.

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

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

Excellent disclosure beyond annotations: browser-only mutation, NOT persisted to source, lost on reload, recorded in pending_changes as pending code edits, and reversible via revert_changes. This tells the agent exactly what side effects and reversibility to expect, complementing the idempotent/non-destructive hints.

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 critical caveat ('changes the browser only — NOT saved, lost on reload') is front-loaded before the functional sentence, which is good information hierarchy. It is tight overall, losing only a small amount of clarity to the ambiguous 'without a pass, lists passes' 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-parameter nested-object mutation with annotations and no output schema, the description covers behavior, persistence and undo well. It hints that a passless call lists passes, partially covering return behavior, but does not fully describe the response of a listing call.

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

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

Schema description coverage is 83%, so the schema already documents passName, passIndex, effectIndex, uniforms and effectParams with examples. The description only restates these categories ('disable passes, set pass uniforms or effect parameters') without adding format or constraint detail, 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+resource: enable/disable passes and set pass uniforms or effect parameters. The scope is clear and distinguishable from generic setters. However it doesn't name the postprocessing_list sibling, and the phrase 'without a pass, lists passes' blurs the line with that sibling's listing role.

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 live-preview framing and the note that changes are undoable via revert_changes, which gives the agent workflow context. But there is no explicit when-to-use/when-not or named alternative (e.g., postprocessing_list for listing, set_uniform for other uniforms).

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 it is a non-read-only, idempotent, non-destructive mutation, and the description adds genuinely new behavior: changes live only in the browser, are lost on reload, do not edit source, are recorded in pending_changes (which feeds code edits), and can be reverted. This is rich disclosure beyond the structured fields.

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, tightly front-loaded: the critical persistence caveat and recovery path come first, followed by a compact list of adjustable settings. 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?

For a mutation tool whose safety profile is covered by annotations and which has no output schema, the description supplies the key non-obvious facts (non-persistence, pending_changes, revertability). The remaining gap is documentation of the less obvious parameters like sortObjects and localClippingEnabled.

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 38% (only toneMapping, shadowMapType, outputColorSpace are documented). The description names the setting categories (tone mapping, exposure, color space, pixel ratio, shadows), which recovers some of the five undocumented parameters, but adds no value mappings or formats beyond 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?

States a specific verb ('Change') and resource ('renderer settings') and enumerates the covered sub-fields (tone mapping, exposure, color space, pixel ratio, shadows). It is distinguishable from the read-only sibling renderer_info, though it does not explicitly contrast with renderer_settings or set_shadow, which also touch these domains.

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 operational context: this is a live-preview-only change, not persisted, recorded in pending_changes and undoable with revert_changes. It does not state explicit when-not conditions versus alternatives like set_shadow or renderer_settings, so it falls 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?

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) by disclosing that edits are browser-only, never written to source, lost on reload, tracked in pending_changes, and undoable via revert_changes. That non-persistence/undo contract is exactly the context the annotations cannot 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 dense sentences, with the critical '[LIVE PREVIEW]' caveat front-loaded before the capability statement. No filler, though the pending_changes/revert_changes parenthetical makes the first sentence slightly packed.

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?

Covers ephemerality, undo path, and which parameter families target objects vs lights for a 15-parameter mutation tool with no output schema. It leaves a gap on target identification (0 required params, name/uuid precedence) but is otherwise complete for correct invocation.

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

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

Schema coverage is 73%, and the description adds meaningful grouping the schema lacks: castShadow/receiveShadow apply to 'any object', while bias/mapSize/shadow camera apply to lights. This clarifies several parameters (e.g., cameraNear/cameraFar have no schema descriptions) but omits how name vs uuid selection works.

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: change shadow casting/receiving on objects and bias/mapSize/shadow-camera on lights. An agent can tell it apart from most siblings, though it never explicitly contrasts itself with set_light, which overlaps on light properties.

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

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

It gives strong context about the live-preview workflow and names pending_changes and revert_changes, but these are companions rather than alternatives — it never says when to reach for set_shadow versus set_light or set_object_transform. Usage is implied, not prescribed.

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 readOnly=false, idempotent=true, destructive=false, but the description adds substantial non-obvious behavior: changes are browser-only, NOT saved to source, lost on reload, recorded in pending_changes (→ code edits), and undoable via revert_changes. That is exactly the kind of ephemerality and side-effect context an agent needs and cannot get from annotations alone.

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